Sollte man noch #!/binsh schreiben?

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.

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.

(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.

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

1

HISTORY

2

 dash is a POSIX-compliant implementation of /bin/sh that aims to be

3

 as small as possible.  dash is a direct descendant of the NetBSD

4

 version of ash (the Almquist SHell), ported to Linux in early 1997.

5

6

 The current version of dash is in the process of being changed to

7

 conform with the POSIX 1003.2 and 1003.2a specifications for the

8

 shell.  This version has many features which make it appear similar

9

 in some respects to the Korn shell, but it is not a Korn shell clone

10

 (see ksh(1)). Only features designated by POSIX, plus a few Berkeley

11

 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.

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.

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!

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.

(prx) A. K. schrieb:

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. :)

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

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.

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

/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.

Motopick schrieb:

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

Nur, dass AT&T gar keinen vi kannte …

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.

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. ;-)

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.

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.

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."

1

     VI(1)                                                       VI(1)

2

3

     NAME

4

          ex, vi - text editor

5

6

     SYNOPSIS

7

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

8

          name ...

9

10

          edit [ options ]

11

12

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

13

          ...

14

15

     DESCRIPTION

16

          Ex is a superset of ed(1) with a display editing facility;

17

          edit is a simplified subset of ex; and vi is a fully

18

          display-based editor with similar capabilities.  Option -R

19

          makes the editor read-only.

20

21

     FILES

22

          /usr/lib/ex?.?strings         error messages

23

          /usr/lib/ex?.?recover         recover command

24

          /usr/lib/ex?.?preserve        preserve command

25

          /etc/termcap             describes capabilities of terminals

26

          ~/.exrc                  editor startup file

27

          /tmp/Exnnnnn             editor temporary

28

          /tmp/Rxnnnnn             named buffer temporary

29

          /usr/preserve            preservation directory

30

31

     SEE ALSO

32

          Edit: A Tutorial

33

          Ex Reference Manual

34

          An Introduction to Display Editing with Vi

35

          Vi Quick Reference Card, all in BSD 4.1 Progammer's Manual,

36

          Volume 2

37

          ed(1), jim(9.1), sed(1)

38

39

     BUGS

40

          The undo command causes all marks to be lost on lines

41

          changed and then restored if the marked lines were changed.

42

          Undo never clears the buffer modified condition.

43

          The z command prints a number of logical rather than physi-

44

          cal lines.  More than a screen full of output may result if

45

          long lines are present.

46

          File input/output errors don't print a name if the command

47

          line `-' option is used.

48

          There is no easy way to do a single scan ignoring case.

49

          The editor does not warn if text is placed in named buffers

50

          and not used before exiting the editor.

51

          Null characters are discarded in input files, and cannot

52

          appear in resultant files.

53

54

     VI(1)                                                       VI(1)

55

56

          Software tabs using ^T work only immediately after the

57

          autoindent.

58

          The wrapmargin option can be fooled since it looks at output

59

          columns when blanks are typed.  If a long word passes

60

          through the margin and onto the next line without a break,

61

          then the line won't be broken.

62

          The source command does not work when executed as :source;

63

          there is no way to use the :append, :change, and :insert

64

          commands in vi, since it is not possible to give more than

65

          one line of input to a : escape.  To use these on a :global

66

          you must Q to ex command mode, execute them, and then reen-

67

          ter the screen editor with vi or open.

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.

Aaah :).

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

q.e.d.

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

Da. Schau mal:

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

1

/*

2

********************************************************************************

3

*                         Copyright (c) 1985 AT&T                              *

4

*                           All Rights Reserved                                *

5

*                                                                              *

6

*                                                                              *

7

*          THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T                 *

8

*        The copyright notice above does not evidence any actual               *

9

*        or intended publication of such source code.                          *

10

********************************************************************************

11

*/

12

/* Copyright (c) 1981 Regents of the University of California */

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

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.

(BSD) ist eine Variante des Betriebssystems Unix

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

Motopick schrieb:

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

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

Darl McBride

Von dem hab ich einen schicken Kuli.

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

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?

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 ...

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).

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.

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'.

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.

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.

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.