f e l i x k r i c k l . x y z

Seit Anfang meines Studiums nutze ich hauptsächlich Linux Mint. Die Blog Einträge hier beziehen sich, wenn nicht anders gekennzeichnet, auf dieses Betriebssystem.


2022-01-20 – Notiz zur Installation von texlive und texstudio

Dieser Blog-Eintrag richtet sich vor allem an solche, die texlive zum ersten Mal installieren. Er kann jedoch auch für fortgeschrittene Benutzer interessant sein.

Vorgestellt wird in diesem Blog-Eintrag ein Zusammenhang in Bezug auf:

  • GNU/Linux Mint "Una" bzw. GNU/Linux Mint Debian Edition 4 "Debbie"
  • texlive 2021 (Das Latex-Grundsystem)
  • texstudio 2.12.22+debian-1build1 von http://ftp.halifax.rwth-aachen.de/ubuntu focal/universe amd64 Packages (Ein beliebiger Latex-Editor)

Nachdem man das aktuelle .tar.gz-file von tug.org heruntergeladen hat und die install-tl-Datei im Terminal durch

sudo ./install-tl
im entsprechenden Verzeichnis aufgerufen hat, wird dem Benutzer eine Reihe von künftigen Standard-Verzeichnissen für die Installation des texlive-Systems vorgeschlagen. Diese beschränken sich im wesentlichen auf das Verzeichnis /usr/local/texlive/JAHR. Diese können zunächst mal in den default-Einstellungen bestätigt werden, oder aber auch im Installationsskript nach Belieben geändert werden. Für das Funktionieren von texlive an sich spielt es keine Rolle, wo dieses installiert wird. Es gibt aber zwei Punkte die hier wichtig sind:
  • Texstudio schaut m.W.n per default in /usr/share/texlive/JAHR nach den zur Kompilierung notwendigen binaries
  • Das Kompilieren läuft schneller, wenn das texlive-Verzeichnis auf einer SSD gespeichert ist.
Der erst Punkt ist insofern irrelevant, als dass man in Texstudio unter "Optionen" -> "TexStudio konfigurieren" -> "Befehle" Die Pfade für die jeweiligen Binaries angeben kann. Es kann aber sein, dass der default-Pfad von texlive und Texstudio zunächst nicht übereinstimmen. Das führt dann in Texstudio beim Kompilierversuch zu einer Fehlermeldung, die ausdrückt, dass das erste in der Präambel gefragte Paket nicht gefunden werden kann. Man kann also nicht Kompilieren, wenn man nicht dafür sorgt, dass die Pfade übereinstimmen.

Der zweite Punkt ist in Zusammenhang mit der Frage relevant, ob man ein System hat, bei dem die root-Partition und die /home-Partition auf verschiedenen Laufwerken liegen. Ist das der Fall und sollte eines der beiden Laufwerke eine SSD sein, sollte auf der SSD installiert werden. Um die binaries des texlive-Grundsystems braucht man sich keine Sorgen zu machen. Sie bei einer Backup-Routine zu integrieren ist unnötig, da sie jederzeit von den offiziellen Quellen neu bezogen werden können.

Allerdings sollte man sich bei eigens zugefügten Paketen oder Klassen um die Integration in die Backup-Routine sorgen machen. Denn diese bekommt man sonst nicht wieder. Eine Art, dies bei einem System zu realisieren, bei welchem man immer nur /home sichert, ist entweder die komplette Installation von texlive im /home (nicht zu empfehlen), oder die Installation im root mit einer Auslagerung des Unterverzeichnisses PFAD/texlive/texmf-local in das /home-Verzeichnis durch einen symbolischen Link. Denn im texmf-local Baum sollen ja eigene Pakete und Klassen untergebracht werden. So zum Beispiel bei mir geschehen durch:

mkdir ~/texlive
cd /usr/local/texlive
sudo mv texmf-local ~/texlive
sudo ln -s ~/texlive/texmf-local texmf-local
Bei diesem Aufbau werden die in ~/texlive/texmf-local liegenden Pakete auch von Texstudio gefunden.

Grundsätzlich würde ich von einer Installation des gesamten texlive-Systems im /home-Verzeichnis abraten, weil es unkonventionell und auch nicht nötig ist. Dazu kommt, dass man für die binaries noch die PATH Variable ändern muss, damit diese überhaupt ausgeführt werden dürfen. Das ist zwar durchaus möglich, aber für Anfänger nicht trivial.


2021-11-20 – Von Bruker Messgeräten generierte NMR-Ordner nach dem Messtitel umbenennen

An der HHU-D werden NMR-Spektren mit Bruker Geräten gemessen. Dabei erhält man über das Serversystem die Spektren in einem Ordner, welcher nach der Experimentnummer (meist 3 oder 4-stellig) benannt ist. Hierdurch wird aber der NMR-Titel, den man auf den Messzettel geschrieben hat nicht ersichtlich. Dieser ist im entsprechenden Ordner unter pdata/1/title versteckt.

Um hier mehr Übersicht zu haben, habe ich ein kurzes bash-Skript geschrieben, welches die NMR-Ordner umbenennt, sodass nach der Experiment-Nummer noch der eigentlich Titel der Messung angezeigt wird. Dieses kann wie bei meinem blog-Eintrag von 2021-10-07 über das Kontextmenü angewendet werden. Hier der Inhalt des Skriptes:

#!/bin/bash
                    for NMR_FOLDER in $@;
                    do
                    DELIMITER="_";
                    EXP_TITLE=$(cat $NMR_FOLDER/pdata/1/title | sed 's/\ /_/g');
                    mv $NMR_FOLDER $NMR_FOLDER$DELIMITER$EXP_TITLE
                done

Angewendet wird das Skript mit Rechtsklick auf einen oder mehrere ausgewählte Experiment-Ordner im Dateimanager.


2021-11-07 – Modifikation des "Compress PDF"-Scriptes von Ricardo Ferreira

Auf dem Forum LinuxMintUsers.de fand ich einen Hinweis auf ein einfaches bash-Script zur Komprimierung von pdf-Dateien. Dieses wurde von Ricardo Ferreira erstellt und ist bei launchpad verfügbar. Es lässt sich über das Kontextmenü im Nemo-Dateimanager anwenden, wenn es in ~/.local/share/nemo/scripts abgelegt wird und ausführbar gemacht wird. Man kann es auf einzelne oder eine Auswahl von pdf-Dateien gleichzeitig ausführen. Dabei wird ein Fenster geöffnet, in welchem man zwischen fünf Komprimierungs-Optionen wählen kann. Hat man eine ausgewählt, wird noch über ein zweites Fenster abgefragt, unter welchem Dateinamen das komprimierte pdf abgespeichert werden soll.

Durch Ausprobieren habe ich gefunden, dass die Option "niedrige Qualität (150 dpi)" bisher für alle getesteten pdfs den besten Kompromiss aus Qualität und Dateigröße bietet. Auch finde ich es nicht sinnvoll, jedesmal einen neuen Dateinamen eingeben zu müssen. Ich habe daher einige Komponenten des Skriptes auskommentiert und mit wenigen Zeilen ersetzt, die dafür sorgen, dass die beiden Auswahlfenster übersprungen werden und stattdessen die Option "niedrige Qualität (150 dpi)" immer durchgeführt wird. Auch der Dateiname für das komprimierte pdf kann nun nicht mehr ausgewählt werden, sondern entspricht stets dem Dateinamen der Eingabedatei zuzüglich des Suffix "_opt". Auf diese Weise spart man sich einige Tipperei und Klickerei und hat dennoch weiterhin die Option, die Komprimierung "rückgängig" zu machen, falls es nicht den Wünschen des Anwenders entspricht, indem man einfach die komprimierte Datei löscht und gegebenenfalls die Eingabedatei auf andere Art noch mal bearbeitet.

Eine Möglichkeit, das Beste aus beiden Welten zu behalten, wäre zum Beispiel, sich das originale Skript von Ricardo Ferreira in /usr/bin zu legen und bei Bedarf über die Befehlszeile auszuführen und meine Modifikation in .local/share/nemo/scripts abzulegen, um über das Kontextmenü darauf zugreifen zu können.

Hier also mein modifiziertes Skript zum Download:

compress-pdf (15,3 kB)

Das Skript unterliegt dem Urheberrecht von Ricardo Ferreira und wird unter der Gnu Public License v3.0 verteilt.


2021-10-27 – Gescannte Dokumente "lesbar" machen

Mit dem ocrmypdf Paket können gescannte Dokumente so bearbeitet werden, dass der Text markiert und an anderer Stelle eingefügt wird. Um diese Option im Kontextmenü nutzen zu können, muss eine Datei "ocr" im Verzeichnis ~/.local/share/nemo/scripts/ mit folgendem Inhalt erzeugt und ausführbar gemacht werden:

INPUT=$@
DATEINAME=$(echo $INPUT | sed 's/\./\t/' |awk '{print $1}')
ENDUNG="_ocr.pdf"
OUTPUT="$DATEINAME$ENDUNG"

ocrmypdf $INPUT $OUTPUT
Vergleiche mit dem letzten Blogpost.


2021-10-07 – LaTeX Dokumente kompilieren mit Rechtsklick auf die Datei

Ein Terminal zu öffnen, nur um den Pfad zu einer .tex-Datei einzugeben und dann "pdflatex DATEI" einzugeben, ist mehr Aufwand, als sein muss. Einfacher ist es, eine script-Datei mit dem schlichten Inhalt:

~/texlive/2021/bin/x86_64-linux/pdflatex $@
im Verzeichnis ~/.local/share/nemo/scripts/ abzulegen, z.B. mit dem Dateinamen "pdflatex". Zum Schluss muss man nur noch den Modus der script-Datei auf 757 setzen:
chmod 757 ~/.local/share/nemo/scripts/pdflatex
und sollte nun den Befehl über das Kontextmenü im Dateimanager auf beliebige .tex-Dateien anwenden können.

Beachte: Der erste Befehl gilt nur für Systeme, bei denen texlive im /home-Verzeichnis installiert wurde. Wenn die binary "pdflatex" in einem anderen Verzeichnis liegt, muss das natürlich entsprechend angepasst werden. Wo die Datei "pdflatex" im eigenen System liegt kann überprüft werden, indem man

type pdflatex
im Terminal eingibt.


2021-10-07 – Zugriff auf das VPN der HHU Ein viel einfacherer Weg, als vom ZIM empfohlen, auf das VPN der HHU unter Linux Systemen zuzugreifen, ist der Weg über das Terminal. Man muss so oder so zunächst openvpn installieren. Die .ovpn-Datei der HHU muss im entsprechenden Ordner abgelegt werden und ein einfaches alias, eingetragen in die ~/.bash_aliases genügt:
sudo apt-get install openvpn
alias hhuvpn='sudo openvpn ~/.openvpn/HHU-VPN.ovpn'
Wo genau die .ovpn-Datei liegt spielt im Grunde keine Rolle. Sie in den Konfigurationsordner ~./openvpn zu legen ergibt Sinn, aber solange man im alias den richtigen Pfad angibt, kann die Datei an beliebiger Stelle des Dateisystems platziert werden.

2021-10-06 – Mein "schreibmit"-alias

Das Ziel: Die Inhalte des Terminals "live" in eine Datei schreiben, um später einen Anhaltspunkt dafür zu haben, was am System geändert worden ist.

Die Lösung: Die linux-utillity "script" aus BSD 3. Diese wird mit einer Pfadangabe in ein alias inkorporiert:

alias schreibmit='script -a ~/terminal-logs/via-script/$(date +%Y-%m-%d_%H:%M)'
und in die ~/.bash_aliases eingefügt. Um das "mitschreiben" sauber zu beenden, muss
exit
eingegeben werden. Das Terminal schließt sich dann nicht, es wird nur "script" beendet.

Zur Bedienung von "script" befragt man "man":

man script


2021-10-05 – VirtualBox Machines im root Verzeichnis speichern

Nachdem bei meinem Setup

  • root-Verzeichnis auf sda1, einer SSD
  • /home-Partition auf sdb1, einer HDD
entsprechend dem default meine virtuellen Maschinen auf einer HDD lagen (nämlich in ~/'VirtualBox VMs') und diese hörbar beanspruchten, hatte ich überlegt wie ich die Maschinen auf die SSD verschieben könnte. Es war zu klären, ob das Rechte-System dies erlauben würde.

Wie sich gezeigt hat, war ein einfacher symlink hierfür ausreichend. Es wurde der Ordner /vboxVMs erstellt:

sudo mkdir /vboxVMs
Die virtuellen Maschinen wurden in dieses Verzeichnis verschoben, und rekursiv mit dem Modus 757 versehen:
sudo mv ~/'VirtualBox VMs'/* /vboxVMs/
sudo chmod -R 757 /vboxVMs
Das default Verzeichnis für die virtuellen Maschinen wurde dann gelöscht und der symlink "an selber Stelle gesetzt":
rm -r ~/'VirtualBox VMs'
ln -s /vboxVMs ~/'VirtualBox VMs'
Nach diesen fünf Kommandos waren die virtuellen Maschinen erfolgreich auf die SSD verbracht worden und konnten ohne Änderungen in den Konfigurationsdateien weiterhin ganz normal gestartet / betrieben werden. Sollte man den Speicherort ohne symlink ändern wollen, so könnte man das allerdings auch tun, indem man eben in der Konfigurationsdatei VirtualBox.xml den Pfad ändert. Diese Konfigurationsdatei war bei mir im Ordner ~/.config/VirtualBox zu finden. Der Speicherpfad für die virtuellen Maschinen ist in der .xml bei "defaultMachineFolder" eingetragen.