ubuntuusers.de

Hallo liebes Forum,

es ist zum Haare raufen. Ich habe folgendes Problem:

1

var="$(unbuffer bin/toot --max-width 200 status "$id" | grep ...)"

Wenn ich mein Programm im Terminal ausführe, wird alles korrekt verarbeitet. unbuffer brauche ich für die Option --max-width 200 für den toot-Befehl in der command substitution, ansonsten greift die Option --max-width nicht. So weit so gut. Wenn ich mein Programm allerdings mit Cron laufen lasse, funktioniert unbuffer nicht mehr. Wie kann ich das lösen?

Gruß

Carsten

Welcher $PATH ist in deiner Crontab denn gesetzt? Vielleicht hilft es, den vollen Pfad vor das unbuffer-Kommando zu schreiben. Ich nutze ansonsten lieber komplette Skripte, die ich einfach über die Crontab aufrufe.

Oder nutze lieber eine SystemD-Unit für den Job, da sind die Debugging-Möglichkeiten besser. Bei der Crontab ist das leider recht umständlich.

@CarstenHa: Kann es sein, dass da ein / vor bin/toot fehlt‽

@Doc_Symbiosis

Ja, PATH ist richtig eingetragen. Ich habe mich jetzt für die Mastodon-API anstelle von toot entschieden. Das hätte ich man gleich machen sollen, das hätte mir viel Zeit erspart. Das ist einfach robuster. Aber mit der systemd-Unit ist ein guter Tipp. Danke ☺

Marc_BlackJack_Rintsch schrieb:

@CarstenHa: Kann es sein, dass da ein / vor bin/toot fehlt‽

Ne, das passt. Das Ganze Repo liegt in einer Python-VE. Der Pfad wird am Anfang des Skriptes bestimmt. Das passt so. Aber gut wenn da immer noch mal ein paar Augen mehr drauf schauen 😉

CarstenHa schrieb:

Wenn ich mein Programm allerdings mit Cron laufen lasse, funktioniert unbuffer nicht mehr.

Was genau bedeutet das? Gibt es Fehlermeldungen?

Hallo,

rklm schrieb:

Was genau bedeutet das? Gibt es Fehlermeldungen?

Ich müsste eher sagen "... funktionierte unbuffer nicht mehr so wie ich das erhofft hatte." Also toot ist ja in Python geschrieben und die Option --max-width wirkt sich unterschiedlich aus (Alle Befehlsbeispiele standen in einem Shellskript):

1. Terminal geöffnet:
1.1 Funktionierte wie gewünscht (Ausgabe wird richtig auf 200 Zeichen begrenzt; nur zu Testzwecken probiert):

1

bin/toot --max-width 200 status "$id" | grep ...

1.2 Funktionierte nicht (Ausgabe wird auf 82 Zeichen (wenn ich das noch richtig in Erinnerung habe) begrenzt):

1

var="$(bin/toot --max-width 200 status "$id" | grep ...)"

1.3 Funktionierte wie gewünscht:

1

var="$(unbuffer bin/toot --max-width 200 status "$id" | grep ...)"

2. Via Cron:
2.1 Funktionierte nicht wie gewünscht:

1

var="$(unbuffer bin/toot --max-width 200 status "$id" | grep ...)"

Ich hatte gedacht, Punkt 1.3 und 2.1 würden sich gleich verhalten. Aber das tun sie nicht. Ich hatte bei der Verarbeitung mit Cron den Inhalt mal in eine Logdatei schreiben lassen, da hatte ich anschließend den ganzen Content so in der Datei stehen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

E
i
n

W
o
r
t

u
s
w

Das Verhalten von toot (Python) und der Option --max-width in Verbindung mit dem Terminal kann ich ja nachvollziehen. Bei unbuffer scheine ich noch ein Verständnisproblem zu haben. Mal sehen, wenn ich etwas Zeit habe dann schaue ich mir das noch mal genauer an. Es sei denn, Euch fällt noch was auf oder könnt mir dazu noch was sagen. Dann immer her damit 😉

Ach ja, meine neue Lösung via API sieht übrigens jetzt so aus:

1

var="$(curl -s "https://${mastoserver}/api/v1/statuses/${id}" | jq -r '.content' | grep ...)"

Viiel besser 😉

Gruß

Carsten

Auch wenn ich wahrscheinlich vor Scham gleich rot werde, veröffentliche ich das trotzdem mal 😉

Das funktioniert auch mit Cron:

1

var="$(COLUMNS=200 bin/toot --max-width 200 status "$id" | grep ...)"

Viele Grüße

Carsten

Wozu dienen die äußeren Anführungsstriche bei allen Zuweisungen?

user_unknown schrieb:

Wozu dienen die äußeren Anführungsstriche bei allen Zuweisungen?

Eigentlich müsste ich auch "$id" nicht quoten, weil die ID einfach eine Zahlenfolge ist. Das ist einfach nur stilistisch und die Macht der Gewohnheit. Ich kann so schneller in meinem "Mist den ich verzapfe" den Code finden, wo word splitting, etc. benötigt wird 😉