Sollte man noch #!/binsh schreiben?

[Bauform B. (bauformb)]

hallo,

wann beginnt die nahe Zukunft? Vor 11 Jahren schrieb Fedora

Features/UsrMove
All the old paths are reachable, because there a compat symlinks
in place, which will not go away (at least not in the near future).
All your scripts and binaries should work, like they did before.

Die Symlinks /bin->/usr/bin usw. abzuschaffen, ist ja der nächste 
logische Schritt. Debian bookworm ist jetzt die zweite Generation ohne 
echtes /bin, wie lange geht das noch gut? Habt ihr schon alle eure 
Scripts auf #!/usr/bin/sh umgebaut?

https://fedoraproject.org/wiki/Features/UsrMove#I_don%E2%80%99t_have_/usr_as_a_separate_partition._What_changes_for_me?

[(prx) A. K. (prx)]

Bauform B. schrieb:
> Habt ihr schon alle eure Scripts auf #!/usr/bin/sh umgebaut?

Ich denke nicht, dass ich die Zeit noch erleben werde, in der /bin/sh 
nicht mehr nutzbar ist.

[Motopick (motopick)]

Vermutlich hast du ohnehin keine Bourneshell auf deinem System.
Dann entscheidet die /etc/alternativs Lotterie welche Shell den
Job bekommt.

Man arbeitet fieberhaft daran, Linux kaputt zu frickeln.

Es waere also eine gute Tat™, den tatsaechlich benutzen Interpreter
mit dem nativen Pfad anzugeben.

> in der /bin/sh nicht mehr nutzbar ist

Das kann schneller gehen als einem lieb ist.

[Jörg W. (dl8dtl) (Moderator)]

(prx) A. K. schrieb:
> Ich denke nicht, dass ich die Zeit noch erleben werde, in der /bin/sh
> nicht mehr nutzbar ist.

Solaris? Wo die Posix-Shell sich unter /usr/xpg4/bin/sh versteckt … 
/bin/sh hat dort nur eine sehr historische Variante.

Auf allen anderen Systemen sollte man erwarten können, dass /bin/sh eine 
Posix-Shell ist. Ob das nun bash, ash, dash oder sonstwas ist, bleibt 
sich eigentlich gleich.

[Bauform B. (bauformb)]

Motopick schrieb:
> Vermutlich hast du ohnehin keine Bourneshell auf deinem System.
> Dann entscheidet die /etc/alternativs Lotterie welche Shell den
> Job bekommt.

Das wäre ja einfach ;) Wenn man dabei gewinnt, kommt man nur in nächsten 
Level: man dash

HISTORY
 dash is a POSIX-compliant implementation of /bin/sh that aims to be
 as small as possible.  dash is a direct descendant of the NetBSD
 version of ash (the Almquist SHell), ported to Linux in early 1997.

 The current version of dash is in the process of being changed to
 conform with the POSIX 1003.2 and 1003.2a specifications for the
 shell.  This version has many features which make it appear similar
 in some respects to the Korn shell, but it is not a Korn shell clone
 (see ksh(1)). Only features designated by POSIX, plus a few Berkeley
 extensions, are being incorporated into this shell.

Die man page ist von Januar 2003, da weiß man, was man hat :)

Jörg W. schrieb:
> Auf allen anderen Systemen sollte man erwarten können, dass /bin/sh eine
> Posix-Shell ist. Ob das nun bash, ash, dash oder sonstwas ist, bleibt
> sich eigentlich gleich.

Na gut, aber wenn der Link /bin->/usr/bin abgeschafft wird, erwischt das 
Script garkeine shell mehr.

[Jörg W. (dl8dtl) (Moderator)]

Bauform B. schrieb:
> Na gut, aber wenn der Link /bin->/usr/bin abgeschafft wird, erwischt das
> Script garkeine shell mehr.

Es gibt inzwischen genügend Systeme, bei denen /bin und /usr/bin das 
gleiche sind. Bislang ist noch keiner auf die Schnapsidee gekommen, 
deshalb /bin in die Tonne zu kloppen.

Aber man kann natürlich auch einfach den Script mit ":" auf der ersten 
Zeile anfangen.

[Daniel A. (daniel-a)]

Ich denke, eigentlich sollte man /usr/bin/env nehmen, aber dann ist 
/usr/bin/env hartkodiert.

Ich finde das momentane System sowieso doof. Wenn man mal einrichten 
könnte, dass z.B. #!sh automatisch das macht, was heute "#!/usr/bin/env 
sh" macht, das wäre die Lösung!

[(prx) A. K. (prx)]

Motopick schrieb:
> Vermutlich hast du ohnehin keine Bourneshell auf deinem System.
> Dann entscheidet die /etc/alternativs Lotterie welche Shell den
> Job bekommt.

In welchem Linux wird die Shell über /etc/alternatives geschaltet? Ich 
habe auf die Schnelle keines gefunden. Das wäre m.E. erstklassige 
Tretmine.

Ob "sh" auf "bash" oder auf "dash" verlinkt wird, darin unterscheiden 
sie sich aber.

[Jörg W. (dl8dtl) (Moderator)]

(prx) A. K. schrieb im Beitrag #7370261:
> Wer ein Shell-Script schreibt, schreibt es für einen bestimmten
> Shell-Standard. Und wenn das Posix ist, wärs eher unklug, auf solche
> Weise eine "csh" unterzujubeln.

csh nimmt man eh nicht für Scripte. :)

[Foobar (asdfasd)]

Daniel schrieb:
> Ich finde das momentane System sowieso doof. Wenn man mal einrichten
> könnte, dass z.B. #!sh automatisch das macht, was heute "#!/usr/bin/env
> sh" macht, das wäre die Lösung!

Das kannst du mit binfmt_misc[1] sehr einfach erledigen.  Hat aber das 
übliche Problem eines nicht-Standards - geht nur bei dir, bei anderen 
fallen solche Dateien auf die Schnauze.


[1] https://en.wikipedia.org/wiki/Binfmt_misc
    https://lwn.net/Articles/679310/
    file://localhost/usr/src/linux/Documentation/binfmt_misc.txt

[Norbert (der_norbert)]

Ich muss gestehen das ich das für den Prototypen eines ›Erste Welt 
Problems‹ halte.

1. Alles geht solange es geht. Seit Jahren, seit Jahrzehnten.
2. Wenn's nicht mehr geht, dann helfen einem die Freunde ›find‹, ›sed‹, 
›awk‹
3. Danach geht's wieder, hat ein paar Minuten gedauert und hält wieder 
Jahre und Jahrzehnte.

[(prx) A. K. (prx)]

Für mich sieht das eher nach einer Diskussion aus, die verzweifelt nach 
einem Problem sucht, wo weit und breit keines zu finden ist.

[Motopick (motopick)]

> /bin/sh that aims to be as small as possible.

Passend dazu waere dann ein vi aus den (AT&T) Originalquellen 
compiliert.
Und zum "Fensterln" ein wm2 oder wmx.

> Das wäre m.E. erstklassige Tretmine.

Ich bin im Moment da etwas sparsam ausgestattet.
Ich bin mir aber sicher, dass es ueber uns kommen wird.

[Jörg W. (dl8dtl) (Moderator)]

Motopick schrieb:
> Passend dazu waere dann ein vi aus den (AT&T) Originalquellen
> compiliert.

Nur, dass AT&T gar keinen vi kannte …

[Motopick (motopick)]

> Nur, dass AT&T gar keinen vi kannte …

Das waere aber komisch.
Was hat denn AT&T in seinen Unixen dann als Editor verwendet?
So deiner Meinung nach?

Edit:
Den ed mal nicht mitgerechnet.

[(prx) A. K. (prx)]

Motopick schrieb:
> Was hat denn AT&T in seinen Unixen dann als Editor verwendet?

Anfangs entwickelte man ohne Text-Terminal, z.B. mit Teletype (*) aka 
Fernschreiber. Da reichte erst "ed" (AT&T), dann "ex" (BSD).

*: Rate mal wovon sich /dev/tty ableitet. ;-)

[Jörg W. (dl8dtl) (Moderator)]

Motopick schrieb:
> Das waere aber komisch.

Dann solltest du dir die UNIX-Geschichte etwas besser ansehen, bevor du 
solche Aussagen machst. ;-)

vi kommt von BSD, einer der Autoren war Bill Joy, der später Sun 
Microsystems mitgegründet hat.

[MaWin O. (mawin_original)]

Ich sehe überhaupt keinen Grund dazu /bin überall gegen /usr/bin zu 
ersetzen.
Das wäre ein massiver Bruch und würde uns über Jahrzehnte beschäftigen.
Und wozu das alles? Um den /bin -> /usr/bin Symlink einzusparen, den 
moderne Distros eh schon oft nutzen? /bin und vieles andere im 
Wurzelverzeichnis sind doch bereits weg.

[Motopick (motopick)]

> die UNIX-Geschichte

Immerhin wird man bei den Bell Labs aber fuendig:

Und gehoeren die etwa nicht zu AT&T?

http://man.cat-v.org/unix_8th/1/vi

"8th Edition of Bell Labs' Unix."

     VI(1)                                                       VI(1)

     NAME
          ex, vi - text editor

     SYNOPSIS
          ex [ - ] [ -v ] [ -t tag ] [ -r ] [ -R ] [ +command ] [ -l ]
          name ...

          edit [ options ]

          vi [ -t tag ] [ -r ] [ -R ] [ +command ] [ -l ] [ -wn ] name
          ...

     DESCRIPTION
          Ex is a superset of ed(1) with a display editing facility;
          edit is a simplified subset of ex; and vi is a fully
          display-based editor with similar capabilities.  Option -R
          makes the editor read-only.

     FILES
          /usr/lib/ex?.?strings         error messages
          /usr/lib/ex?.?recover         recover command
          /usr/lib/ex?.?preserve        preserve command
          /etc/termcap             describes capabilities of terminals
          ~/.exrc                  editor startup file
          /tmp/Exnnnnn             editor temporary
          /tmp/Rxnnnnn             named buffer temporary
          /usr/preserve            preservation directory

     SEE ALSO
          Edit: A Tutorial
          Ex Reference Manual
          An Introduction to Display Editing with Vi
          Vi Quick Reference Card, all in BSD 4.1 Progammer's Manual,
          Volume 2
          ed(1), jim(9.1), sed(1)

     BUGS
          The undo command causes all marks to be lost on lines
          changed and then restored if the marked lines were changed.
          Undo never clears the buffer modified condition.
          The z command prints a number of logical rather than physi-
          cal lines.  More than a screen full of output may result if
          long lines are present.
          File input/output errors don't print a name if the command
          line `-' option is used.
          There is no easy way to do a single scan ignoring case.
          The editor does not warn if text is placed in named buffers
          and not used before exiting the editor.
          Null characters are discarded in input files, and cannot
          appear in resultant files.

     VI(1)                                                       VI(1)

          Software tabs using ^T work only immediately after the
          autoindent.
          The wrapmargin option can be fooled since it looks at output
          columns when blanks are typed.  If a long word passes
          through the margin and onto the next line without a break,
          then the line won't be broken.
          The source command does not work when executed as :source;
          there is no way to use the :append, :change, and :insert
          commands in vi, since it is not possible to give more than
          one line of input to a : escape.  To use these on a :global
          you must Q to ex command mode, execute them, and then reen-
          ter the screen editor with vi or open.

[(prx) A. K. (prx)]

Motopick schrieb:
> Vi Quick Reference Card, all in BSD 4.1 Progammer's Manual,

q.e.d.

Natürlich hatte AT&T den "vi" übernommen.

> "8th Edition of Bell Labs' Unix."

Die ist von 1985. BSD 4.1 ist von 1981.

[Motopick (motopick)]

Aaah :).

> Natürlich hatte AT&T den "vi" übernommen.

q.e.d.

[(prx) A. K. (prx)]

Motopick schrieb:
> Aaah :).
>
>> Natürlich hatte AT&T den "vi" übernommen.
>
> q.e.d.

Motopick schrieb:
> Passend dazu waere dann ein vi aus den (AT&T) Originalquellen
> compiliert.

Zum Zeitpunkt von Version 8 war der Quellcode von AT&T UNIX nicht mehr 
problemlos verfügbar. Der kommentierte Quellcode des Kernels von UNIX 
Version 6 beschäftigte indes noch Jahre später die Copyshops rund um die 
Unis, als Lernmaterial:
https://de.wikipedia.org/wiki/Lions_Book

[Motopick (motopick)]

Da. Schau mal:

https://github.com/Cube9999/vi/blob/master/vax/ex.c

/*
********************************************************************************
*                         Copyright (c) 1985 AT&T                              *
*                           All Rights Reserved                                *
*                                                                              *
*                                                                              *
*          THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T                 *
*        The copyright notice above does not evidence any actual               *
*        or intended publication of such source code.                          *
********************************************************************************
*/
/* Copyright (c) 1981 Regents of the University of California */

https://github.com/Cube9999/vi/blob/master/vax/ex.c

[(prx) A. K. (prx)]

Motopick schrieb:
> Regents of the University of California

Yep. Eben BSD, nicht AT&T, auch wenns auf den ersten Blick anders 
aussieht. Die BSD Lizenz erlaubt eine ziemlich freie Nutzung des 
Quellcodes, solange die hier gezeigte letzte Zeile drin bleibt.

"Die Berkeley Software Distribution (BSD) ist eine Variante des 
Betriebssystems Unix, die an der Universität von Kalifornien in Berkeley 
ab 1977 entstanden ist." (Wikipedia)

Da BSD lange Zeit noch Originalquellcode von AT&T enthielt, gab es 
folgerichtig so lange Zoff zwischen den beiden, bis BSD die letzte Zeile 
AT&T Code eliminierte. Umgekehrt sah aufgrund der freien Lizenz AT&T 
keine Probleme darin, BSD Code zu übernehmen.

[Motopick (motopick)]

> (BSD) ist eine Variante des Betriebssystems Unix

Jaja. Aber nur wo AT&T drauf steht, ist wirklich UNIX drin. :)

[(prx) A. K. (prx)]

Motopick schrieb:
> Jaja. Aber nur wo AT&T drauf steht, ist wirklich UNIX drin. :)

Bist du ein Wiedergänger von Darl McBride? ;-)

[Motopick (motopick)]

> Darl McBride

Von dem hab ich einen schicken Kuli.

Ich habe geliefert. Fuer mich ist das Thema damit abgeschlossen.

[Xanthippos (xanthippos)]

Seit Jahren fangen alle Scripte bei mir mit #!/usr/bin/python3 an.

Gibt es außer bauformb und dl8dtl überhaupt noch irgend jemanden der 
Scripte für die Bourneshell schreibt?

[Foobar (asdfasd)]

Xanthippos schrieb:
> Seit Jahren fangen alle Scripte bei mir mit #!/usr/bin/python3 an.

Bei mir ist das Lua, bei anderen Perl.  Allerdings haben diese Sprachen 
das Problem, dass sie nicht überall vorhanden sind (python3 z.B. gibt's 
bei mir nicht) und dass man mit den reinen Sprachen meist nicht 
allzuweit kommt - man braucht zusätzlich oft noch irgendwelche externen 
Module (evtl sogar eigene).  Deshalb beschränke ich das auf Skripte, die 
ausschließlich bei mir laufen sollen - da weiß ich, was vorhanden ist, 
was ich benutzen darf.

> Gibt es außer bauformb und dl8dtl überhaupt noch irgend jemanden der
> Scripte für die Bourneshell schreibt?

Nun ja, einige Sachen sind in der Shell einfacher zu lösen.  Und halt 
alles, was auf Standardsystemen laufen soll.  Die hier benötigten 
"externen Module" beschränken sich auf POSIX-Kommandos (d.h. u.a. auch, 
#!/bin/sh und nicht #!/bin/bash!).

Bei Makefiles und in der Kommandozeile selbst ist etwas mehr sh-Wissen 
auch nicht verkehrt ...

[Jörg W. (dl8dtl) (Moderator)]

Xanthippos schrieb:
> Gibt es außer bauformb und dl8dtl überhaupt noch irgend jemanden der
> Scripte für die Bourneshell schreibt?

Sagen wir mal so: die Posix-Shell.

Die Bourne-Shell ist es nur noch bei Solaris (falls sie es nicht 
inzwischen doch mal geändert haben – habe ich schon 'ne Weile nicht mehr 
in den Fingern gehabt).

Es gibt ziemlich viele Standardaufgaben, die halt damit nach wie vor 
erledigt werden, und wie schon genannt wurde, die Shell ist halt auf 
einem unixoiden System immer da, alles andere kann da sein, muss 
nicht.

/usr/bin/python3 ist genauso unportabel wie /bin/bash – bei mir würdest 
du Python3 beispielsweise unter /usr/local/bin/python vorfinden, ein 
/usr/local/bin/python3 gibt es nicht, aber ein /usr/local/bin/python3.* 
(je nach aktueller Version).

[(prx) A. K. (prx)]

Ich hatte mich zwar vor zig Jahren entschieden, alle nicht-trivialen 
Scripte in Perl zu schreiben, weil ich das für alle im Laufe der Zeit 
genutzten Plattformen hatte (darunter DOS, 16/32 Bit OS/2, NT). Aber für 
Trivialkram in Unix/Linux war immer noch die Shell da.

[Rolf M. (rmagnus)]

Motopick schrieb:
>> /bin/sh that aims to be as small as possible.
>
> Passend dazu waere dann ein vi aus den (AT&T) Originalquellen
> compiliert.
> Und zum "Fensterln" ein wm2 oder wmx.

Wozu sollte man die in Shellskripten brauchen?

Foobar schrieb:
> Xanthippos schrieb:
>> Seit Jahren fangen alle Scripte bei mir mit #!/usr/bin/python3 an.
>
> Bei mir ist das Lua, bei anderen Perl.  Allerdings haben diese Sprachen
> das Problem, dass sie nicht überall vorhanden sind (python3 z.B. gibt's
> bei mir nicht)

Wo gibt's denn kein python3? Ich dachte, das sei überall vorhanden, 
wobei ich zugegebenermaßen außerhalb der Linux-Welt nicht weiß, wie 
populär da Python ist.

> und dass man mit den reinen Sprachen meist nicht allzuweit kommt - man
> braucht zusätzlich oft noch irgendwelche externen Module (evtl sogar
> eigene).

Also zumindest Python liefert da ja schon ziemlich viel mit, was für die 
üblichen Skripting-Aufgaben mehr als ausreichend ist.

>> Gibt es außer bauformb und dl8dtl überhaupt noch irgend jemanden der
>> Scripte für die Bourneshell schreibt?
>
> Nun ja, einige Sachen sind in der Shell einfacher zu lösen.

Ja, vor allem wenn das Skript im Wesentlich nur daraus besteht, ein paar 
Kommandozeilenprogramme aufzurufen und miteinander zu 'verpipen'.

[Jörg W. (dl8dtl) (Moderator)]

Rolf M. schrieb:
> Wo gibt's denn kein python3?

S.o., beispielsweise auf FreeBSD. Dort war man konsequenter als Linux: 
*) "python" ist dort ein Python 3, steht allerdings in /usr/local/bin, 
da es nicht Bestandteil des Basissystems ist.

*) Als die meisten Linux-Distris. Keine Ahnung, ob es welche gibt, die 
das anders handhaben.

[Motopick (motopick)]

>> Und zum "Fensterln" ein wm2 oder wmx.
>
> Wozu sollte man die in Shellskripten brauchen?

Die Frage ist falsch gestellt.
Haette man sie richtig gestellt, haette man auch schon die Antwort.

Es gibt durchaus Systeme, bei denen eine vorhandene initiale
Textkonsole nur dazu taugt, Fehlermeldungen auszugeben und eine
andere Umgebung zu starten. Vermutlich kennst du sowas nicht.

[Daniel A. (daniel-a)]

Foobar schrieb:
> Das kannst du mit binfmt_misc[1] sehr einfach erledigen.

Hab ich jetzt mal umgesetzt, siehe Anhang. Anschalten mit "./shebang 
--enable", abschalten mit "./shebang --disable", Verwendung auf eigene 
Gefahr.

Anders als bei normalen shebang Zeilen in Linux interpretiert es auch 
noch \ escapes, erlaubt mehrere Argumente und kann - darum gieng es mir 
eigentlich - Binaries im Path suchen.

Es wäre mir zwar lieber, wenn der Kernel das machen würde. Jedes mal so 
ein Programm zu starten ist doch einiges an unnötigem Overhead.

[🕵︎ Joachim L. (Gast)]

Motopick schrieb:

> Man arbeitet fieberhaft daran, Linux kaputt zu frickeln.
> Das kann schneller gehen als einem lieb ist.

Bei manchen Projekten habe ich den Eindruck, das da Leute kommen mit 
enormen Fachwissen und erst ein paar einwandfreie Beitraege machen, und 
dann, ganz ploetzlich einen Riesen"fehler" der sich erst spaeter 
auswirkt, bzw. auffaellt.

Das passierst meistens bei erfolgreichen Projekten mit closed-source 
Konkurrenz und/oder Schluesseltechnologien wie Grafikkartentreiber etc.

Ein Schelm wer boeses dabei denkt. Wer macht bloss sowas?

https://www.fudzilla.com/media/k2/items/cache/377d06745597733b1a389a68ae653035_L.jpg