Hallo, ich möchte gerne unter Linux ein Skript ausführen. Das sieht so aus: #!bin/sh echo hallo Ich habe es ausführbar gemacht und starte es mit ./meinskript.sh Dann kommt folgender Fehler: bash: ./meinskript.sh: bin/sh: Defekter Interpreter: Datei oder Verzeichnis nicht gefunden Was auch immer das heißt... Kann mir jemand weiterhelfen? Danke :-)
>#!bin/sh
#!/bin/sh
pfad trotzdem prüfen mit "which sh"
;-)
Kontrabass schrieb: > #!bin/sh Was ist an ... > ... Datei oder > Verzeichnis nicht gefunden ... unklar? Es fehlt ein Slash. leo
Wobei ich statt der /bin/sh immer die /bin/bash nehme. Die hat mehr Möglichkeiten, auch in Skripten.
weil ich da selbst erst wieder versehentlich drübergestolpert bin: korrektes Zeilenende. LF/CR oder LF. Das unter Mac übliche CR mag linux nicht.
> Wobei ich statt der /bin/sh immer die /bin/bash nehme. > Die hat mehr Möglichkeiten, auch in Skripten. Wie ich diese Was-kostet-die-Welt-Einstellung hasse :-(
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.
PittyJ schrieb: > Wobei ich statt der /bin/sh immer die /bin/bash nehme. > Die hat mehr Möglichkeiten, auch in Skripten. Wobei es dem TO lediglich darum ging, daß er sein script nicht zum Laufen kriegt. Aber daß ein fehlender slash die Ursache ist, wurde ihm bereits beantwortet.
Rolf M. schrieb: > 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. "Die" ist ist aller Regel bash. ls -n /bin/sh /bin/sh -> bash* man bash When invoked as sh, bash enters posix mode after ...
:-) schrieb: > "Die" ist ist aller Regel bash. > ls -n /bin/sh > /bin/sh -> bash* Bei mir (ubuntu 18.04) ist es die dash
:-) schrieb: > "Die" ist ist aller Regel bash Außer wenn sie es nicht ist. Dieses Forum ist voll von Fragen a la "Mein Script geht auf dem Raspberry Pi nicht richtig, warum???", deren Antwort meistens "Raspbian linkt sh auf dash" lautet.
>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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
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. leo
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.
:
Bearbeitet durch Moderator
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...
Sheeva P. schrieb: > Dem Teilnehmer, der Linux-Dateien mit > Wordpad editiert, sei daher geraten, sich einen richtigen Texteditor > zuzulegen... Zum Übersetzen bzw. Austauschen der Textdateien von Windows nach Cygwin hatte ich Notepad++ genommen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.