Ganz unten innen drin ist es egal, ob die Datei eine .sh Endung hat. In /etc/init.d endet ca. ein Dritte auf .sh. Für Zufall oder Tradition ist das viel zu viel, niemand tippt freiwillig 3 unnütze Zeichen ein. Einzige Erklärung: Irgendwo wird der Unterschied für schwarze Magie genutzt, aber wofür?
Für Zufall oder Tradition ist
das viel zu viel, niemand tippt freiwillig 3 unnütze Zeichen ein.
Einzige Erklärung: Irgendwo wird der Unterschied für schwarze Magie
genutzt, aber wofür?
Eher „Ist halt so und keiner hat’s für nötig befunden, es zu ändern“. Solange die Scripte ausführbar sind, und eine korrekte ›#!‹-Zeile (in Fachkreisen „Shebang“-Zeile genannt, aber das alleine zu nennen, hätte wohl für verständnislose Blicke gesorgt) existiert, gibt es technisch keinen Unterschied. Kannst es ja ausprobieren – dabei drauf achten, dass symbolische Verknüpfungen beim Umbenennen des Ziels kaputtgehen.
Die drei Zeichen zu tippen, stellt hingegen keinen Aufwand dar, der einer Abwägung bedürfte – das nimmt bei jemandem, der mit der Tastatur umgehen kann, nicht einmal ’ne Sekunde in Anspruch und im Zweifelsfall ist die bewusste Entscheidung, es bei einem Shellscript /nicht/ zu schreiben, für jemanden, der’s normalerweise automatisch dranhängt, zeitlich teurer.
Es wäre geschickt gewesen, wenn du das betreffende OS benannt hättest. Musste ein wenig suchen, bis ich hier eines gefunden habe, das überhaupt noch das ›init.d/‹-Verzeichnis hat …
Eher „Ist halt so und keiner hat’s für nötig befunden, es zu ändern“.
würde ich auch so sehen.
Die drei Zeichen zu tippen, stellt hingegen keinen Aufwand dar, der
einer Abwägung bedürfte – das nimmt bei jemandem, der mit der Tastatur
umgehen kann, nicht einmal ’ne Sekunde in Anspruch
Du tippst die normal sowieso nicht, sondern verwendest einfach schon lange vor dem Ende des Dateinamens die Autocompletion mit Tab. Diese Zeichen spielen also was das Tippen angeht gar keine Rolle.
Du tippst die normal sowieso nicht, sondern verwendest einfach schon
lange vor dem Ende des Dateinamens die Autocompletion mit Tab.
Beim Anlegen halt schon. Bei existierenden Files hast du natürlich Recht – das ist mir hier gar nicht mal eingefallen, weil irgendwie selbstverständlich.
Die drei Zeichen zu tippen, stellt hingegen keinen Aufwand dar
Mechanisch nicht, geistig und moralisch schon. Wo sonst hat ausführbares eine Endung? "ls.exe -la" vielleicht?
Aber, nur eine Tasse Kaffee später: Ubuntu 7.1, /etc/init.d/rc
1
# Debian Policy §9.3.1 requires .sh scripts in runlevel S to be sourced
2
# However, some important packages currently contain .sh scripts
3
# that do "exit" at some point, thus killing this process. Bad!
4
#[ S = "$runlevel" ] && sh=.
5
for script in $scripts ; do
6
case "$script" in
7
*.sh)
8
startup_progress $debug $sh "$script" $action
9
;;
10
*)
11
startup_progress $debug "$script" $action
12
;;
13
esac
14
done
In Debian 8 und 9 hab' ich das nicht mehr gefunden, jetzt spendiert man eben für jedes Script eine extra Shell, der Strom kommt ja aus der Steckdose ;)
Für Zufall oder Tradition ist
das viel zu viel, niemand tippt freiwillig 3 unnütze Zeichen ein.
Einzige Erklärung: Irgendwo wird der Unterschied für schwarze Magie
genutzt, aber wofür?
Eher „Ist halt so und keiner hat’s für nötig befunden, es zu ändern“.
Solange die Scripte ausführbar sind, und eine korrekte ›#!‹-Zeile (in
Fachkreisen „Shebang“-Zeile genannt, aber das alleine zu nennen, hätte
wohl für verständnislose Blicke gesorgt) existiert, gibt es technisch
keinen Unterschied. Kannst es ja ausprobieren – dabei drauf achten, dass
symbolische Verknüpfungen beim Umbenennen des Ziels kaputtgehen.
Werden die Scripte nur via init aufgerufen, braucht es das
#!/bin/sh
regelmässig nicht, weil ohnehin klar ist, dass sie von /bin/sh
gesourced werden (sollten).
Benutzt nur jemand etwas anderes als /bin/sh als Loginshell, und
ist die nicht hinreichend kompatibel genug zu /bin/sh, und will
unbedingt eines der Skripte von Hand starten:
Ja, da ist das #!/bin/sh dann natürlich hilfreich.
Der Suffix .sh ist dagagen für überhaupt nichts gut. ☺
Gerade geistig ist der Aufwand höher, es nicht zu schreiben. Zumindest mit Leuten, die’s halt so gelernt haben. Und was genau wäre die moralische Komponente?
Wo sonst hat ausführbares
eine Endung? "ls.exe -la" vielleicht?
Falsches System? Die Endung bei Scriptfiles ist lediglich ’n Hinweis für die Shell, welcher Interpreter zu nutzen wäre; aufgrund der Shebang-Zeile ist’s heute eher ein Hinweis für den User. Ausführbare Binaries hatten hier hingegen noch nie eine entsprechende Endung
Spräche ja dafür, dass die Scripte von damals halt ihren Namen behalten haben. Insbesondere sind’s zumindest auf dem System, auf dem ich nachgeschaut habe (du verweigerst ja leider die Angabe des Systems, auf das du dich beziehst) von Debian stammende Scripte, welche die Endung haben.
jetzt spendiert man
eben für jedes Script eine extra Shell, der Strom kommt ja aus der
Steckdose ;)
In welchem Jahrzehnt bist du denn hängengeblieben? Jetzt macht systemd den Job – und man kann dem viel vorwerfen – aber dass es den Systemstart ineffizient gestalten würde, gehört nicht dazu.
Joa … sorry, dass wir versucht haben, dir bei der Beantwortung deiner Frage zu helfen. Kommt zumindest von mir nicht mehr vor (wenn ich dran denke, ansonsten halt vielleicht schon).
du verweigerst ja leider die Angabe des Systems, auf
das du dich beziehst
Die Frage ist ja System-unabhängig, die Suchmaschine kannte auch passende Fundstellen bei FreeBSD. Der Beweis, dass es mal nicht egal war, ist von Ubuntu 7.1; in Debian 8 "Jessie" und Debian 9 "Stretch" war das schon auf dem heutigen Stand. Aktueller Anlass ist die Debian-Installation auf dem PC, der heute ankam; Forky auf dem Umweg über Trixie, natürlich mit sysvinit :)
Jetzt macht systemd den Job
oder irgendein anderes init
– und man kann dem viel vorwerfen – aber dass es den Systemstart
ineffizient gestalten würde, gehört nicht dazu.
Ich rede ja auch nicht von systemd. Immerhin habe ich gerade einen echten Nachteil von sysvinit gefunden.
Debian Policy §9.3.1 requires .sh scripts in runlevel S to be sourced
However, some important packages currently contain .sh scripts
that do "exit" at some point, thus killing this process. Bad!
Ach, weiß doch jeder, dass sich bei diesem GNU/Linux in so kurzer Zeit kaum was verändert, und auch so antike Quellen die aktuelle Situation wiedergeben.
Eher 20 Jahre, Ubuntu 7.10. Leider ändert sich zu viel zu oft. Debian wird nicht im Supermarkt in Augenhöhe verkauft. NEU!!!1!!11 ist hier kein Verkaufsargument.
Naja … immerhin kann man sich bei Stretch / Debian 9 nicht mehr vom Root-Account ausschließen – da gibt’s ja nun einen Stapel nutzbarer Lücken. Wenn man dann noch bisschen Software aus der Zeit übers Netz erreichbar hat, kann man sich u.U. auch von überall aus einloggen.
Der Suffix .sh ist dagagen für überhaupt nichts gut.
Finde ich nicht. Sieht man als Benutzer wenigstens sofort, dass es sich um ein Shell-Script handelt. Klar, für das System selber is der Suffix irrelevant. Aber wenn man mit einem System nur auf der Kommandozeile arbeitet, zum Beispiel ein Server, wo 'ls --color' was auf den meisten GNU/Linux Distributionen zwar standardmäßig aktiviert ist, aber auf Systemen wie OpenBSD nicht, dann sind die zusätzlichen Zeichen im Dateinamen schon hilfreich.
Bessere Erklärung: warum nicht? Eine funktionelle Bedeutung hat es nicht, kann aber eine individuelle Konvention sein. Nicht jeder ist so schreibfaul wie du.
Sieht man als Benutzer wenigstens sofort, dass es sich
um ein Shell-Script handelt.
Und das Schöne dabei ist, man kann jede nur erdenkliche Datei so aussehen lassen wie man will. Doch, wie so oft, der Schein kann trügerisch sein.
Erinnert fast an ein anderes OS…
Wenn man skeptisch ist, dann hat man ja immer noch ›file *‹ um zu sehen was es tatsächlich beinhaltet.
