Linux Skript ausführen - geht nicht!

>#!bin/sh

#!/bin/sh

pfad trotzdem prüfen mit "which sh"

;-)

PittyJ schrieb:
> Wobei ich statt der /bin/sh immer die /bin/bash nehme.
> Die hat mehr Möglichkeiten, auch in Skripten.

Die ist dafür deutlich aufgeblähter. Und /bin/sh ist auch portabler, da 
im Gegensatz zur bash POSIX-Standard.

>CR mag linux nicht

besonders fies ist Wordpad
ich lade einen Text aus dem Linux-Rechner per Filezilla in den 
Windows-Rechner und schaue es mit Wordpad an. Anschließend 
zurückspeichern in den Linux-Rechner.

Wordpad hat ungefragt vor jedes 0A ein 0D eingefügt und das mag Linux 
nicht mehr.

bingo schrieb:
> :-) schrieb:
>> "Die" ist ist aller Regel bash.
>> ls -n /bin/sh
>> /bin/sh -> bash*
>
> Bei mir (ubuntu 18.04) ist es die dash

Das ist bei Debian-basierten Distributionen soweit ich weiß der 
Standard. Die kommt schließlich von Debian ("dash" steht für "Debian 
Almquist Shell") und ist extra dafür gemacht, zwar voll POSIX-konform, 
aber schlanker und auch deutlich schneller als die Bash und damit besser 
für Skripte geeignet zu sein.

Wenn man nicht genau weiß wo ein Befehl steht (je nach OS kann es mal 
bin... mal /usr/bin/... sein), kann man auch env nehmen:

#!/usr/bin/env bash

Ist allerdings eher nur für "Userskripte" sinnvoll, Diskussion dazu 
hier:

https://stackoverflow.com/questions/16365130/what-is-the-difference-between-usr-bin-env-bash-and-usr-bin-bash

Ansonsten, ja, die bash ist sicherlich aufgebläht, bringt aber auch 
viele eingebaute Features mit, z.B. Arrays, Expressions etc., wo man bei 
anderen Shells teilweise üble Klimmzüge machen müsste.

Aber die ksh ist jetzt auch nicht viel kleiner:

-rwxr-xr-x 1 root root 942K Aug  8  2019 /bin/bash
-rwxr-xr-x 1 root root 1.5M Feb 24 17:21 /bin/ksh93

Rolf M. schrieb:
> bingo schrieb:
>> :-) schrieb:
>>> "Die" ist ist aller Regel bash.
>>> ls -n /bin/sh
>>> /bin/sh -> bash*
>>
>> Bei mir (ubuntu 18.04) ist es die dash
>
> Das ist bei Debian-basierten Distributionen soweit ich weiß der
> Standard. Die kommt schließlich von Debian ("dash" steht für "Debian
> Almquist Shell") und ist extra dafür gemacht, zwar voll POSIX-konform,
> aber schlanker und auch deutlich schneller als die Bash und damit besser
> für Skripte geeignet zu sein.

Die bash(1) ist genau so gut für Skripte geeignet, benötigt aber etwas 
mehr als 3 MB Arbeitsspeicher -- während die dash(1) nur etwa die Hälfte 
braucht, dafür aber viele nützliche Bashisms nicht beherrscht.

Im Debian-Projekt haben die Befürworter des Wechsels von bash(1) auf 
dash(1) damals primär mit zwei Argumenten gepunktet: mit der geringfügig 
besseren Performance und einem kleinen Speicherprofil der dash(1) (das 
war in Zeiten des sequentiellen SysV-Init womöglich wichtiger als heute 
mit dem parallelisierten systemd-Init), zweitens werden Entwickler von 
Init-Skripten dazu animiert, POSIX-kompatible Initskripte zu schreiben.

Ich persönlich kann das POSIX-Argument zwar nachvollziehen -- frage mich 
dann aber, warum die Debian-Entwickler nicht gleichzeitig versucht 
haben, die Initskripte und ihre Helferfunktionen mit anderen 
Linux-Distributoren zu synchronisieren. Bevor die großen Distributionen 
auf systemd gewechselt sind, mußte ein Entwickler nämlich für jede 
Linux-Distributionsfamilie ein eigenes Initskript schreiben, das war 
IMHO sehr ärgerlich und manchmal auch zeitraubend... und hat 
Softwarehersteller sicher auch nicht sonderlich motiviert, ihre Software 
für Linux anzubieten.

Das Performanceargument verstehe ich allerdings nur aus einem Standpunkt 
aus, der sich sehr, sehr hoch im Elfenbeinturm befindet, in der Praxis 
halte ich das für unsinnig. Daß es die Bashisms gibt, hat ja Gründe, 
nämlich: daß sie nützlich sind. Für viele durchaus nicht exotische 
Anwendungsfälle hat eine bash(1) bereits viele Funktionen gleich 
eingebaut, während ich in der dash(1) dazu einen oder mehrere Subprozess 
mit sed(1), awk(1) oder sogar perl(1) oä. starten muß. Aber leider sind 
Unterprozesse und context switches auf jedem modernen Betriebssystem 
relativ teuer, was die Vorteile der dash(1) dann schnell wieder zunichte 
macht -- und wer wirklich Ressourcen sparen will, beispielsweise weil er 
auf einem kleinen Embedded-System unterwegs ist, der nimmt eh 
busybox(1)... Heute benutzen Debian, Ubuntu und alle anderen großen 
Linux-Distributionen ohnehin nur noch selten klassische Shellskripte 
beim Systemstart, da entfällt auch das schnellere Booten.

leo (Gast)

>Christoph db1uq K. schrieb:
>> ich lade einen Text aus dem Linux-Rechner per Filezilla in den
>> Windows-Rechner und schaue es mit Wordpad an. Anschließend
>> zurückspeichern in den Linux-Rechner.

>Immer wenn ich mir in den Fuss schiesse, tut es weh.

Ja genau. Das ist nunmal bei Windows Standard, warum soll Windows da 
fragen?
Zumal 0a0d (LF + CR) eigentlich auch richtiger ist als nur 0a.

Jens G. schrieb:

> Zumal 0a0d (LF + CR) eigentlich auch richtiger ist als nur 0a.

Du meinst CR+LF.

LF+CR benutzt m.W. kein System.

Jens G. schrieb:
> Ja genau. Das ist nunmal bei Windows Standard, warum soll Windows da
> fragen?

Naja, es werden dadurch immerhin große Teile der Datei verändert, die
der Benutzer gar nicht angerührt hat. Da wäre eine kurze Nachfrage, ob
das wirklich so gewollt ist, schon anständig.

Alle mir bekannten Editoren unter Linux sind da rücksichtsvoller und
behalten das Textformat (Unix oder DOS) bei. Soll der Editor tatsächlich
von einem Format ins andere konvertieren, muss man ihn explizit dazu
auffordern.

> Zumal 0a0d (LF + CR) eigentlich auch richtiger ist als nur 0a.

Aus der Sicht eines Fernschreibers ist das schon so, aber die meisten
der 33 ASCII-Steuerzeichen für Fernschreiber machen in einer Textdatei
keinen Sinn. Deswegen wurde für Textdateien zwar die Zeichenkodierung
von ASCII übernommen, dabei aber die Bedeutung der Steuerzeichen auf
sinnvolle Weise angepasst.

Die Unix-Macher und Apple haben bereits frühzeitig erkannt, dass zur
Kennzeichnung eines Zeilenumbruchs in einer Textdatei ein einzelnes
Steuerzeichen völlig ausreichend ist. Schade ist nur, dass sie dabei
nicht dasselbe Zeichen verwenden. Bei CP/M und damit auch bei den
Nachfolgern MS-DOS und Windows ist man halt in der Fernschreiberära
stecken geblieben.

Yalu X. schrieb:
> Jens G. schrieb:
>> Ja genau. Das ist nunmal bei Windows Standard, warum soll Windows da
>> fragen?
>
> Naja, es werden dadurch immerhin große Teile der Datei verändert, die
> der Benutzer gar nicht angerührt hat. Da wäre eine kurze Nachfrage, ob
> das wirklich so gewollt ist, schon anständig.
>
> Alle mir bekannten Editoren unter Linux sind da rücksichtsvoller und
> behalten das Textformat (Unix oder DOS) bei.

Verzeihung, aber nicht alles, das Textdateien editieren kann, ist auch 
ein Editor. Wordpad zum Beispiel ist kein Editor, sondern ein 
Wortprozessor, also zum Schreiben von Texten mit Layout gedacht -- quasi 
ein abgespecktes Microsoft Word. Deswegen ist es zwar fähig, 
PlainText-Dateien zu laden und zu speichern, aber nicht besonders gut 
dazu geeignet, Quellcode oder Konfigurationsdateien zu editieren. Dafür 
nimmt man besser einen Texteditor, von denen es auch für Windows eine 
unglaubliche Menge an ausgesprochen leistungsfähigen Werkzeugen gibt, 
angefangen bei Microsofts Visual Studio Code über Atom, Sublime, 
Programmer's Notepad, Notepad++, UltraEdit, vi und natürlich auch den 
guten alten Emacs, und die beherrschen das mit den Umbrüchen, ebenso wie 
viele andere nützliche Funktionen. Dem Teilnehmer, der Linux-Dateien mit 
Wordpad editiert, sei daher geraten, sich einen richtigen Texteditor 
zuzulegen...