getopt und case

[scientific]

Statt

Code: Alles auswählen

firefox

würd ich

Code: Alles auswählen

sensible-browser

verwenden. Denn das öffnet ein Fenster/Tab im bereits geöffneten Browser, ansonsten im voreingestellten System-Browser... Abhängig vom Interface... Im TTY wird damit z.B. ein Textbrowser geöffnet...

Ist eine Debian-Besonderheit, soweit ich weiß.

lg scientific

[scientific]

Hier mein endgültiger Code.
[...]

Willst du nicht doch:

Code: Alles auswählen

for i do

(mit $i), statt:

Code: Alles auswählen

while test $# -gt 0; do

(mit $1 und shift) verwenden?

Ich hab früher einmal relativ umfangreiche Shellskripte geschrieben, und da hab ich diese Methode als am wenigsten Fehleranfällig wahrgenommen.
Die While-Schleife wird nur so lange ausgeführt, als die Anzahl der Argumente in $@ größer als 1 ist. Funktioniert doch gut

lg scientific

[geier22]

@scientific
Danke für den

sensible-browser

hatte ich zwar schon gesehen, wusste aber die Bedeutung nicht.
Jetzt bleibt das Skript auch nicht mehr hängen und wartet auf das Schließen des Browsers.

[scientific]

DAS hätte wohl auch ein & am Ende des Firefoxaufrufes erledigt.

Aber der sensible-browser ist besser.

Probiers mal auf dem TTY aus!

[Lord_Carlos]

Ich wuerde das ganze anders loesen.
Youtube-dl mit archive parameter als cron job laufen lassen. Dann werden neue Episoden automatisch runtergeladen und konvertiert. Ganz ohne Benutztereingabe oder UI, geht also auch auf 'nem ollen server.

[Meillo]

Hier mein endgültiger Code.
[...]

Willst du nicht doch:

Code: Alles auswählen

for i do

(mit $i), statt:

Code: Alles auswählen

while test $# -gt 0; do

(mit $1 und shift) verwenden?

Ich hab früher einmal relativ umfangreiche Shellskripte geschrieben, und da hab ich diese Methode als am wenigsten Fehleranfällig wahrgenommen.
Die While-Schleife wird nur so lange ausgeführt, als die Anzahl der Argumente in $@ größer als 1 ist. Funktioniert doch gut

``Funktioniert doch gut'' und ``am wenigsten fehleranfaellig'' sind zwei verschiedene Dinge. Vieles daran mag eine Stilfrage und persoenliche Praeferenz und Gewohnheit sein, aber es gibt auch eine sachliche Ebene:

`for i do' garantiert, dass die Schleife fuer jedes Argument genau einmal durchlaeuft. Das ist sehr robust. Bei deiner Schleifenbedigung koennen off-by-one Fehler passieren, falls man aus Versehen ``-ge 0'' oder ``-gt 1'' schreibst. Dies ist im anderen Fall ausgeschlossen. Zudem muss man bei deiner Variante als Programmierer dran denken, dass jeder Fall ein ``shift'' enthaelt. Dies ist bei ``for i do'' unnoetig. Zudem reduziert mein Vorschlag den Codeumfang, was statistisch wiederum Fehler reduziert. Folglich faellt aus meiner Sicht die sachliche Analyse zur Fehleranfaelligkeit klar anders rum aus. Aber du hast ja auch nur geschrieben, dass du die Fehleranfaelligkeit so wahrgenommen hast; ich habe hier sachlich argumentiert.

Du kannst das von mir aus auch weiter so machen wie du willst -- sind ja deine Scripte -- ich denke nur, dass es hier sachliche Gruende gibt, es anders zu tun, und die ueberzeugen dich vielleicht.

[owl102]

ich denke nur, dass es hier sachliche Gruende gibt, es anders zu tun, und die ueberzeugen dich vielleicht.

Es gibt aber IMHO auch sachliche Gründe, die hier gegen "for" sprechen: Der Ansatz von scientific ist flexibler, was die Auswertung der Kommandozeilenparameter angeht. Wenn z.B. eine Option einen zusätzlichen Parameter hat (zum Beispiel "-f <dateiname>"), kommt die einfache Lösung mit "for i" nicht in Frage, zumindest dann nicht, wenn man nicht auch noch eine State-Variable einführen möchte. Sicher, in diesem Beispiel ist das nicht der Fall, aber wer hat schon Lust, alles umzuschreiben, falls bei dem Script doch einmal eine Option mit Parameter dazu kommt? (Hinzu kommt, daß das Umschreiben auch fehleranfällig ist.)

[Meillo]

ich denke nur, dass es hier sachliche Gruende gibt, es anders zu tun, und die ueberzeugen dich vielleicht.

Es gibt aber IMHO auch sachliche Gründe, die hier gegen "for" sprechen: Der Ansatz von scientific ist flexibler, was die Auswertung der Kommandozeilenparameter angeht. Wenn z.B. eine Option einen zusätzlichen Parameter hat (zum Beispiel "-f <dateiname>"), kommt die einfache Lösung mit "for i" nicht in Frage, zumindest dann nicht, wenn man nicht auch noch eine State-Variable einführen möchte.

Da hast du Recht.

Sicher, in diesem Beispiel ist das nicht der Fall, aber wer hat schon Lust, alles umzuschreiben, falls bei dem Script doch einmal eine Option mit Parameter dazu kommt? (Hinzu kommt, daß das Umschreiben auch fehleranfällig ist.)

Das ist immer ein Abwaegen im Spektrum zwischen der einfachsten und der flexibelsten Umsetzung. Welches die bessere Anfangsform war weiss man erst hinterher.

(Ja, Umschreiben ist fehleranfaellig, trotzdem sollte man Umschreiben als den normalsten Vorgang der Programmierung ansehen, und nicht etwa das Neuschreiben.)