HOME

Wiki: Linux Befehle: bash(shell)

Um jeden Befehl nur noch EINMAL in der HISTORY zu belassen: in ~/.bash.rc hinzufügen:
export HISTCONTROL=ignorespace:ignoredups
history löschen:
history -cw

Medien via bash wiedergeben

Das ffmpeg beiliegende ffplay spielt viele Formate ab.
Die alleinige Eingabe von ffplay gefolgt von dem Dateinamen spielt zwar die Datei ab, läuft aber(am Ende tonlos) weiter und muss manuell geschlossen werden.

Der Zusatz "-autoexit" beendet ffplay am Ende der Datei:
ffplay -autoexit "liebe.mp3"

Der Zusatz -nodisp lässt das Analysefenster verschwinden,
-loglevel quiet unterdrückt die Anzeige der Metadaten.

Ausgabe von ps ux mit grep filtern:

ps ux zeigt alle USER-Prozesse an, die gerade laufen. Das können recht viele sein.
Man kann die Ausgabe von ps an grep weiterreichen und nach einem Muster filtern(hier alle SCREEN Sessions):
Die Nutzung des Suchmusters "SCREEN" ist etwas dämlich falls noch andere SCREEN Sessions laufen würden(hier: minecraft):
ps ux | grep "SCREEN"
mc-server 3540 0.0 0.0 4530 3880 ? Ss Jul25 0:00 SCREEN -AmdS minecraft java -Xms4096M -Xmx4096M -jar /home/minecraft/spigot-1.16.1.jar
7d2d-server 4800 0.0 0.0 9092 2480 ? Ss Jul25 0:00 SCREEN -AmdS 7d2dsrv ./7DaysToDieServer.x86_64 -logfile /home/7d2d-server/7d2d/7DaysToDieServer_Data/output_log__2020-07-25__22-46-04.txt -quit -batchmode -nographics -dedicated -configfile=dhlfsconfig.xml
7d2d-server 7195 0.0 0.0 6436 888 pts/2 S+ 10:31 0:00 grep SCREEN

Praktischerweise kennt grep auch Suchmuster in der Form SUCHTEXT.*WEITERERTEXTINDERZEILE(.*):
ps ux | grep "SCREEN.*7DaysToDieServer" lässt den Eintrag für minecraft verschwinden aber grep selbst taucht immer noch auf:
7d2d-server 4800 0.0 0.0 9092 2480 ? Ss Jul25 0:00 SCREEN -AmdS 7d2dsrv ./7DaysToDieServer.x86_64 -logfile /home/7d2d-server/7d2d/7DaysToDieServer_Data/output_log__2020-07-25__22-46-04.txt -quit -batchmode -nographics -dedicated -configfile=dhlfsconfig.xml
7d2d-server 7195 0.0 0.0 6436 888 pts/2 S+ 10:31 0:00 grep SCREEN

Perfekt wirds mit dem einschränkenden Suchmuster und Begrenzung auf das erste Vorkommen(-m 1):
ps ux | grep -m 1 "SCREEN.*7DaysToDieServer"
7d2d-server 4800 0.0 0.0 9092 2480 ? Ss Jul25 0:00 SCREEN -AmdS 7d2dsrv ./7DaysToDieServer.x86_64 -logfile /home/7d2d-server/7d2d/7DaysToDieServer_Data/output_log__2020-07-25__22-46-04.txt -quit -batchmode -nographics -dedicated -configfile=dhlfsconfig.xml

Nun kann man die Ausgabe weiter bearbeiten, die PROC_ID rausreissen, oder das Startdatum..

Einen eleganteren Weg, nur die PROC_ID zu finden ist pgrep (process-grep? ^^).
Wenn wie im obigen Beispiel mehrere SCREEN-Sessions laufen, gibt pgrep alle passenden PROC_IDs untereinander aus:
pgrep -f "SCREEN"
3540
4800

Ein Versuch mit dem Suchmuster aus grep(s.o.) grenzt auch hier die Ausgabe nur auf die eine SCREEN-Session von 7DaysToDieServer ein:
pgrep -f "SCREEN.*7DaysToDieServer"
4800

Einen dezimalen Wert für AOB Suche umwandeln..

Ein Skript wird mit Zusatzparametern aufgerufen:
./test 1000 2000 3000 4000
Die dem Skriptaufruf folgenden Eingaben können innerhalb des Skripts über ${1},${2},${3} und ${4} weiterverarbeitet werden.
In diesem Beispiel wird der Variablen ammo1 der erste Wert(1000) dezimal übergeben. Die folgende Zeile wandelt nach hexadezimal um:
ammo1=$(printf '%08x\n' ${1})
Das reicht aber noch nicht, denn der Wert der Variablen ammo1 ist nun 000003e8 (an sich korrekt, aber Intel/Amds.. legen die Zahlen nicht HI-LO sondern LO-HI ab) -.-
Also noch die hexadezimale Zahl wandeln:
ammo1_aob="${ammo1:6:2} ${ammo1:4:2} ${ammo1:2:2} ${ammo1:0:2}"
Und schon ist aus 000003e8 ein für AOB-Scans verwertbares e8 03 00 00 geworden :)
Die "wirren" Zahlen wie :6:2 bedeuten das aus der Variablen ammo1 ab der Stelle 6 zwei Zeichen "kopiert" werden.
Die erste Zahl bestimmt also die Position(muss sich wohl um eine String-Variable handeln), die zweite Zahl die Anzahl..

USB-Sticks/SD(HC) Karten einrichten,..


Nur bei wenigen Distributionen werden eingesteckte "Medien" automatisch unter /media/(USERNAME!)/ eingehängt.
Meist muss man das manuell anstubsen..

Für beliebige Projekte mit Kleinstrechnern(Raspberry Pi/Odroid/etc.) werden SDHC-Karten genutzt um das Betriebssystem einmalig zu "flashen".
Die Karten dienen dann als Betriebssystemdatenträger.
Vorgeschlagen wird immer ein Hilfsprogramm namens "balenaEtcher", ich persönlich finde das mehr als suspekt:
* warum soll ich einen Windowsrechner nutzen um damit dieses ominöse "balenaEtcher" zu nutzen?
Geht das nicht auch mit Linux-Bordmitteln?

Jein.
Ubuntu als Wunschlos-Sorglos-Komplett-Paket hat tatsächlich etwas Ähnliches eingebaut.
Ebenso unterstützt "Mint" die einfache "Bootbar-Machung" von SD Karten/USB-Sticks.
Debian steht mal wieder außen vor -.-

Am Beispiel des Home Assistant (ein OPENSOURCE-Projet für Heimautomatisierung auf Basis eines Raspberry Pi3/4):
* ein Raspberry PI 3 oder 4 wird empfohlen um dort ein angepasstes Betriebssystem zu installieren
* der Datenträger sollte eine SDHC Karte mit mindestens 32GB Speicher sein und dazu mindestens Class2 entsprechen

Verwirrend die Qual der Wahl der Installationsart:
Empfohlen wird für unerfahrene Menschen dem Raspberry Pi guide zu folgen für die Installation des Home Assistan Operation System.
Die anderen Möglichkeiten spare ich mir mal..

Dieser belanaEtcher kann auch unter Debian installiert werden.. aber wie gesagt warum sollte ich das tun?
Es *mag* ein tolles UI sein(nicht getestet)..

Die vorgegebene Downloadadresse(zum Zeitpunkt des Schreibens) lautete: https://github.com/home-assistant/operating-system/releases/download/9.5/haos_rpi4-64-9.5.img.xz
Dabei beachten ob man nun einen Raspberry Pi 3 ODER 4 nutzt..
Öffnet man den Link im Browser.. wird die Datei heruntergeladen.
Eine Überraschung für mich: klickt man die gerade heruntergeladene Datei im Downloadordner an um diese zu "öffnen"..
..erscheint ein Fenster mit dem Titel: Laufwerksabbild wiederherstellen.
Darunter ist die Auswahl möglicher ZIEL-Laufwerke.


UNBEDINGT sicherstellen das das Ziellaufwerk auch die gewünschte Speicherkarte enthält..
Es gibt zwar eine Sicherheitsnachfrage, aber wer falsch gewählt hat.. löscht eines der verbauten Laufwerke und dessen Daten!

Bei Fehlermeldungen(Laufwerk wird verwendet) greift noch ein anderes Programm auf die Speicherkarte zu(Discoverer oder gar mc).
So weit im Directory "heraus" wandern bis man sich nicht mehr im /media/ Ordner befindet. Dann erneut versuchen.
Ein Adapterstick für SDHC Karten(im USB-C Hub) wurde mit 15MB/sek beschrieben.

Die Aufteilung der Karte ist sehr.. merkwürdig:
* sde1 0034 MB FAT(boot?)
* sde2 0025 MB squashfs 4.0
* sde3 0256 MB squashfs 4.0
* sde4 0025 MB unbekannt
* sde5 0268 MB unbekannt
* sde6 0008 MB unbekannt
* sde7 0089 MB Ext4(hassos-overlay)
* sde8 1300 MB Ext4(hassos-data)
* ----62000 MB frei

Diese seltsame Belegung der Speicherkarte scheint richtig zu sein, denn das System startet..
..kann aber nicht genutzt werden, keine Verbindung weder mit http://homeassistant.local:8123/ noch mit der IP-Adresse(+:8123).

Nach STUNDEN die Lösung:
1.) Homeassistant erwartet eine DHCP Aushandlung der IP-Adresse.. gibt es hier nicht(alle Adressen sind manuell statisch vergeben).
2.) Ohne funktionsfähiges Internet.. keine Zeiteinstellung(Raspis behalten nach Spannungsunterbrechung die Zeit nicht ohne RTC-Addon..).
3.) Ohne korrektes Datum stimmen die ZERTIFIKATE nicht!! (Was alle Browser verheimlichen, bis auf Konqueror..)
* Tastatur und HDMI Monitor an den Raspi anschließen und Raspi DANN erst starten.
* im der Console login eingeben und bestätigen.
* date -s "2023-02-29 16:23:00" eingeben(Datum: YYYY-MM-DD gefolgt von der Zeit).
* Dann exit eingeben um zum vorherigen "Bild" zurück zu kehren.

Der Versuch via net update eth0 --ipv4-address 192.168.1.17/24 nutzte nichts.
Auch die weiteren Parameter Gateway/DNS-Server halfen nicht weiter.

Der Hinweis im Forum ist STARK veraltet, half aber enorm:
Erneut login eingegeben um zur Systemconsole zu wechseln..
via nmcli connection show die aktuelle Verbindung anzeigen lassen.
Bei mir hieß das Ding Supervisor eth0.
Nicht den Namen HassOS default(wie in dem Text verwenden, der existiert(nicht)mehr!).
also:
nmcli con edit "Supervisor eth0" eingeben.
print ipv4 (zur Ansicht)
set ipv4.addresses 192.168.1.1/24 (entsprechend abändern!!)
Die ipv4.method Frage(falls es vorher nicht vi net update gesetzt wurde) mit manual(yes) bestätigen.
save
exit

Hinweis:
sowohl DNS als auch den folgenden Eintrag mit DNS IPs belegen.
Danach den Raspi reboot(en) lassen.
Zauberei:
ENDLICH eine Verbindung!!


Weitere Verwirrungen entstehen beim Lesen diverser Problem-"Lösungen" im Netz, viele sind veraltet und schlichtweg falsch(übersetzt..)!

Beispiel:
Für die Netzwerkkonfiguration(im Falle des Fehlschlags von DHCP/static IPs..) OHNE direkten physischen Zugriff auf das laufende System(kein HDMI Monitor,..) kann man die SD-Karte bearbeiten:
Die Partition hassos-overlay enthält eine Konfigurationsdatei unter /etc/NetworkManager/system-connections/Supervisor eth0.nmconnection
Diese kann unter dem Abschnitt ipv4 angepasst werden:
[ipv4]
address1=192.168.100.1/24,192.168.100.255
dns=192.168.19.255;
dns-search=1.1.1.1;8.8.8.8
method=manual
Werte natürlich an das eigene Netz anpassen, so wird das nichts!!


Dummerweise ist nach einer frischen Installation auf die SD-Karte die Partition hassos-overlay noch komplett leer..
Vielleicht KANN man ja den Ordnerpfad einmalig von einer funktionsfähigen SD-Karte kopieren und anpassen?

Falls man die Config quasi zerschossen hat, kein Problem:
rm -r /mnt/overlay/etc/NetworkManager/system-connections
reboot
 * overlay oder hassos-overlay? k.A. vielleicht unterscheiden sich die Namen bei direktem Zugriff vs. SSH Zugriff?

Memo: das gehört hier nicht hin! Sollte nach Hardware verschoben werden, eigene Seite Home Assistant..
Diese Seite wurde zuletzt am 09.02.2023 um 18:50 geändert.

(c) 2024 DHLF ☮🇺🇦