/bin/bash^m: defekter interpreter: datei oder verzeichnis nicht gefunden

I just shifted from Windows to Linux (Ubuntu 18.04)...and following a tutorial to learn bash scripting...

I wrote a simple shell script

#!bin/bash 

echo "Hello World" 

but when I tried to run it using

$ ./test1.sh

it throws an error

bash: ./test1.sh: bin/bash: bad interpreter: No such file or directory

When I am running it using

$ bash test1.sh

it runs fine

I tried searching it and found many answers but all covers errors due to some difference between windows newline ^M and ubuntu newline...I tried opening it in VIM under binary mode(don't know what it is) but it did'not have any ^M tag after bin/bash.

Please suggest what I am doing wrong.

Melebius

10.8k8 gold badges47 silver badges74 bronze badges

asked Jul 16, 2019 at 6:38

Shubham PandeyShubham Pandey

1431 gold badge2 silver badges9 bronze badges

You’re missing a leading slash making the shebang an absolute path:

#!/bin/bash
# ↑ here

In your case, the shell seems to be searching for ./bin/bash.

The shebang (and also executable permission) is only taken into account if you’re running the script as a program:

$ ./test1.sh

It is ignored if you directly run the interpreter and provide your script as an argument:

$ bash test1.sh

See also: https://askubuntu.com/a/850387/250300

answered Jul 16, 2019 at 6:40

2

Although this is an old question, since there is no explanation towards the ^M problem, maybe it's useful:

• ^M comes from the difference between "Windows" return and Linux return.
• Simplest solution is to use an editor to convert all the return in your script from CRLF (Win) to LF (Linux), e.g. VS Code.

answered Jan 5, 2021 at 7:32

Au-ChiKinAu-ChiKin

511 silver badge1 bronze badge

1

Sorry for reviving old topic but I had the same issue and managed to fix it, not sure what exactly helped but did all the things listed below. First of all install Gedit through the command:

sudo apt-get install gedit

Then make sure that you saved the script with Unix/Linux line ending. After this, type in terminal, while being in the proper folder:

chmod +x filename

The last thing is replacing in script itself

#!bin/bash 

with

#!/bin/bash 

answered Mar 10, 2020 at 14:11

1

• Forum
  • µC & Elektronik
  • Analogtechnik
  • FPGA, VHDL & Co.
  • DSP
  • Compiler & IDEs
  • Projekte & Code
  • Markt
  • Platinen
  • Mechanik & Werkzeug
  • HF, Funk & Felder
  • Fahrzeugelektronik
  • Haus & Smart Home
  • PC-Programmierung
  • PC Hard- & Software
  • Ausbildung & Beruf
  • Offtopic
  • Webseite
• Artikelübersicht
• Letzte Änderungen

 
• • Forenliste
  • Threadliste
  • Neuer Beitrag
  • Suchen
  • Benutzerliste
  • Bildergalerie
  • Hilfe
  • Anmelden
  • Login

Forum: PC-Programmierung Linux Skript ausführen - geht nicht!

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"

;-)

von leo (Gast)

04.05.2020 16:43

Kontrabass schrieb:
> #!bin/sh

Was ist an ...

> ... Datei oder
> Verzeichnis nicht gefunden

... unklar?
Es fehlt ein Slash.

leo

von PittyJ (Gast)

04.05.2020 19:42

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

von watz (Gast)

05.05.2020 00:26

weil ich da selbst erst wieder versehentlich drübergestolpert bin: 
korrektes Zeilenende.
LF/CR oder LF. Das unter Mac übliche CR mag linux nicht.

von foobar (Gast)

05.05.2020 04:58

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

von Codo (Gast)

05.05.2020 09:14

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.

von :-) (Gast)

05.05.2020 10:22

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

von bingo (Gast)

05.05.2020 10:34

:-) schrieb:
> "Die" ist ist aller Regel bash.
> ls -n /bin/sh
> /bin/sh -> bash*

Bei mir (ubuntu 18.04) ist es die dash

von Tom (Gast)

05.05.2020 10:37

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

05.05.2020 10:48: 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.

05.05.2020 11:17: 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

von leo (Gast)

05.05.2020 15:50

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.

von Yalu X. (yalu) (Moderator)

10.05.2020 20:07

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.

10.05.2020 20:09: 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...

von rbx (Gast)

12.05.2020 06:42

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

• Groß- und Kleinschreibung verwenden
• Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

• [c]C-Code[/c]
• [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
• [math]Formel in LaTeX-Syntax[/math]
• [[Titel]] - Link zu Artikel
• Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
  "Adresse kopieren", und in den Text einfügen

Warum #!/ Bin bash?

Was ist bash Datei?

Was ist die bash bei Linux?