Infos über / welches Programm und die Fehlermeldung(en) wären sicher hilfreich ...


Michael

Nur doof, dass unter SUSE soweit ich weiß die Datei /bin/sh ein Verweis auf die /bin/bash ist. Das ist dann uncool, oder?

Versuch das Skript mal mit ner anderen Shell auszuführen.

cat /etc/shells

Ich seh grad - unter Debian ist das bei mir auch so. *lol* Wußt ich gar nicht.

versuch ne zsh, csh oder ne tcsh.


Gruß - Bye

> Versuch das Skript mal mit ner anderen Shell auszuführen.

neee, des wird nichts!
Jede Shell hat eine eigene Syntax (Sprache), die kann man nicht mal kurz wie ein paar stinkende Socken auswechseln ...


Michael

> Jede Shell hat eine eigene Syntax (Sprache), die kann man nicht mal kurz wie ein
> paar stinkende Socken auswechseln ...
>
Diesehalb und desterwegen, schreibt man Shell-Skripte auch immer fuer die orig. sh (/bin/sh).

Selbst die Debian Entwickler haben die tottelige Angewohnheit /bin/bash als Shebang zu setzen.

Zitat

neee, des wird nichts!
Jede Shell hat eine eigene Syntax (Sprache), die kann man nicht mal kurz wie ein paar stinkende Socken auswechseln ...

@Michael
Is mir schon klar. Es hatte sich nur so dargestellt, als ob das von ihm verwendete shell-skript in seiner Shell nicht läuft. Sollte nur ein Versuch sein. Also nicht bös sein über mein Brainstorming.

@ShadowOne
Hab dann noch ne Idee. Ich wette, Deine PATH-Variable ist Dein Problem.
Überprüf die mal.
Ist es bestimmt. Wenn er sagt - command not found - findet er min. eins der verwendeten Programme nicht.

Arbeitest Du als root?

wie wechselst Du da hin?

echo $PATH

jepp jepp jepp

@Neo23X0:

solange der Bub keine weiteren Infos rausrückt, kann unsereiner doch nur raten, wo der Fehler liegen könnte!
So geht das nicht ...

Michael

> Nur doof, dass unter SUSE soweit ich weiß die Datei /bin/sh ein Verweis auf die /bin/bash ist.

AFAIK ist das bei allen Linuxen so.

> Das ist dann uncool, oder?

Nicht nur das, das ist totaler Muell.
Ein Script, das einen /bin/sh She-bang hat und nur auf der Bash laeuft ist eine typische Linux Erfindung...

Gruss
kp

Zitat

Original von kernelpanic
Ein Script, das einen /bin/sh She-bang hat und nur auf der Bash laeuft ist eine typische Linux Erfindung...

Ist es nicht so, dass die Bash, wenn sie als sh aufgerufen wurde, im Bourne Shell "Kompatibilitätsmodus" läuft und daher keine Bash-Extras akzeptiert?

Zitat

If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well.

Daher könnte eine Änderung im Shebang von /bin/sh auf /bin/bash durchaus etwas bewirken.

Zitat

Original von kernelpanic
> Nur doof, dass unter SUSE soweit ich weiß die Datei /bin/sh ein Verweis auf die /bin/bash ist.

AFAIK ist das bei allen Linuxen so.

> Das ist dann uncool, oder?

Nicht nur das, das ist totaler Muell.
Ein Script, das einen /bin/sh She-bang hat und nur auf der Bash laeuft ist eine typische Linux Erfindung...

Gruss
kp

Mal schön den Ball flach halten, welche Shell statt der bash soll denn sonst /bin/sh sein?

Es gibt grundsätzlich zwei Shell-Familien "Bourne-Shell" und "C-Shell", die wirklich vollkommen unterschiedlich sind.
Die "Bourne-Shell" ist die, die mit /bin/sh aufgerufen wird. Ich behaupte, es gibt gar keine Original-Bourne Shells mehr. Sowohl bei GNU als auch bei den kommerziellen Unixen ist diese weiter entwickelt worden. Es entstanden bash und Korn-Shell; diese können alles was die Bourne-Shell kann plus eigener Erweiterungen. In der Regel haben diese Nachfolger das Feature, dass sie beim Aufruf prüfen, unter welchem Namen sie aufgerufen wurden, und wenn das /bin/sh ist, dann werden die Erweiterungen ausgeschaltet. So ist das auch bei der bash, wie sich in der Doku leicht nachlesen lässt.

Also der ursprüngliche Fehler liegt woanders. Und da fehlen halt noch ein paar Infos...

Ciao,
tacuma
.

Halt Du mal lieber den Ball flach. Zitat D. Nuhr: "Wenn man keine Ahnung hat.."

> Mal schön den Ball flach halten, welche Shell statt der bash soll denn
> sonst /bin/sh sein?
>
Eine Bourne-Shell - kompatible Shell (SH, ASH, ..) bzw. ein Symlink
gegen eine solche Shell. Es sind *nur* Linux - Distrubtionen die dort
einen Symlink gegen die Bash haben; bei keinem (kommerziellen) UNIX ist
die Bash Bestandteil des Systems (weder bei SunOS, HP-UX, AIX; IRIX;
OSF, ..), sondern lediglich als Zusatzpaket verfuegbar.

> Es gibt grundsätzlich zwei Shell-Familien "Bourne-Shell" und "C-Shell",
> die wirklich vollkommen unterschiedlich sind.
>
Das ist Schwachsinn. Es gibt exakt eine Bourne-Shell; der Rest (CSH;
Bash, KSH, ..) sind abgeleitete Varianten der Bourne-Shell und die CSH
ist ein Haufen Scheisse, weil sie nicht aufwaertskompatibel zur
Bourne-Shell ist.

> Die "Bourne-Shell" ist die, die mit /bin/sh aufgerufen wird. Ich behaupte, es
> gibt gar keine Original-Bourne Shells mehr.
>
Die Bourne-Shell ist die Standard-Shell von UNIX-System V; das war sie, das
ist sie und das wird wahrscheinlich auch immer bleiben. SunOS z. B.
faehrt ohne der Bourne-Shell als /bin/sh gar nicht erst hoch, weil
*alle* INIT-Scripte diese Shell parsen. Gleiches gilt fuer AIX und
Ultrix. Ferner ist auch die originale Bourne-Shell Bestandteil von
4.4BSD.

> Sowohl bei GNU als auch bei den kommerziellen Unixen ist diese weiter
> entwickelt worden.
>
Nein. Bourne-Shell != Bash/KSH/CSH
Die Bourne-Shell kann z. B. "$()", "print" und "$[]" im Gegensatz zur
Bash nicht verarbeiten, weil es im IEEE Std 1003.1 nicht spezifiziert
ist. So enthaelt auch fast jedes rc/INIT/.. - Script bei den meisten
Distrubtionen Arithmetische Expandierung und wenn man solche Script mit
der Bourne-Shell abarbeiten will, ist man im Arsch.

> Es entstanden bash und Korn-Shell; diese können alles was die Bourne-Shell
> kann plus eigener Erweiterungen.
>
Ein Satz von folgeloser Richtigkeit. Du bist also doch in der Lage
/DESCRIPTION der Manpages besagter Shells zu lesen.

> In der Regel haben diese Nachfolger das Feature, dass sie beim Aufruf
> prüfen, unter welchem Namen sie aufgerufen wurden, und wenn das /bin/sh ist,
> dann werden die Erweiterungen ausgeschaltet.
>
Der Kernel liefert, wenn er Shellscripte ausfuehren soll, die kein
"#!/path/to/interpreter" am Anfang stehen haben, ENOEXEC als
Fehlermeldung zurueck, und es ist Sache der Shell, dann noch etwas
vernuenftiges zu machen. tcsh, pdksh und tclsh machen es so dass sie
"/bin/sh script" starten.
Die Bash arbeitet da anders - sie fuehrt das Script (in dem schon
geforkten neuen Prozess) selbst aus (und sollte der Sinn der Uebung der
gewesen sein zu pruefen ob das Script fehlerfrei nicht nur unter Bash,
sondern auch unter einer "primitiveren" Shell laufen kann, dann hat man
Pech). rc (die Plan9-Shell) fuehrt Scripte ohne "#!" gar nicht erst aus
und bei csh ist es noch lustiger. Wenn das Script mit ":" beginnt, wird
es an /bin/sh weitergegeben, ansonsten selber ausgefuehrt.

> So ist das auch bei der bash, wie sich in der Doku leicht nachlesen
> lässt.
>
Dann zitiere doch bitte mal den entsprechenden Abschnitt (mit Quellenangabe).

Zitat

Original von Chucky the Devil
Halt Du mal lieber den Ball flach. Zitat D. Nuhr: "Wenn man keine Ahnung hat.."

> Mal schön den Ball flach halten, welche Shell statt der bash soll denn
> sonst /bin/sh sein?
>
Eine Bourne-Shell - kompatible Shell (SH, ASH, ..) bzw. ein Symlink
gegen eine solche Shell. Es sind *nur* Linux - Distrubtionen die dort
einen Symlink gegen die Bash haben; bei keinem (kommerziellen) UNIX ist
die Bash Bestandteil des Systems (weder bei SunOS, HP-UX, AIX; IRIX;
OSF, ..), sondern lediglich als Zusatzpaket verfuegbar.

Den Ball flach halten:
http://www.redensarten-index.de/suche.ph…te%5B%5D=bsp_ou

Ich habe habe niemanden beschimpft, sondern einen Sachverhalt in, für manche Leute in unzumutbar verkürzter Form, dargestellt.

Zitat

> Es gibt grundsätzlich zwei Shell-Familien "Bourne-Shell" und "C-Shell",
> die wirklich vollkommen unterschiedlich sind.
>
Das ist Schwachsinn. Es gibt exakt eine Bourne-Shell; der Rest (CSH;
Bash, KSH, ..) sind abgeleitete Varianten der Bourne-Shell und die CSH
ist ein Haufen Scheisse, weil sie nicht aufwaertskompatibel zur
Bourne-Shell ist.

Halt mal, ich sage, es gibt zwei Familien, die Bären und die Affen und brüllst dazwischen:
"Das ist Schwachsinn, weil es gibt nur einen Papa-Bär, und die Affen sind Scheisse, weil sie keinen Lachs fischen"
Etwas mehr Abstraktionsvermögen könnte für die Rezeption eines Web-Forums schon hilfreich sein.

BTW: Meinst Du nicht eigentlich abwärtskompatibel?

Zitat

> Die "Bourne-Shell" ist die, die mit /bin/sh aufgerufen wird. Ich behaupte, es
> gibt gar keine Original-Bourne Shells mehr.
>
Die Bourne-Shell ist die Standard-Shell von UNIX-System V; das war sie, das
ist sie und das wird wahrscheinlich auch immer bleiben. SunOS z. B.
faehrt ohne der Bourne-Shell als /bin/sh gar nicht erst hoch, weil
*alle* INIT-Scripte diese Shell parsen. Gleiches gilt fuer AIX und
Ultrix. Ferner ist auch die originale Bourne-Shell Bestandteil von
4.4BSD.

Ein Unix-System V gibt es genau so wenig wie einen Lateiner.
Meines Wissens ist die sh auf Aix ein Symlink auf die ksh, die dann die Extras abschaltet, vergleichbar der bash.

Zitat

> Sowohl bei GNU als auch bei den kommerziellen Unixen ist diese weiter
> entwickelt worden.
>
Nein. Bourne-Shell != Bash/KSH/CSH

Steht nicht im Widerspruch zu meiner Aussage

Zitat

Die Bourne-Shell kann z. B. "$()", "print" und "$[]" im Gegensatz zur
Bash nicht verarbeiten, weil es im IEEE Std 1003.1 nicht spezifiziert
ist. So enthaelt auch fast jedes rc/INIT/.. - Script bei den meisten
Distrubtionen Arithmetische Expandierung und wenn man solche Script mit
der Bourne-Shell abarbeiten will, ist man im Arsch.

Sehr gut beobachtet, wenn die Anführung an dieser Stelle auch etwas beliebig wirkt.

Zitat

> Es entstanden bash und Korn-Shell; diese können alles was die Bourne-Shell
> kann plus eigener Erweiterungen.
>
Ein Satz von folgeloser Richtigkeit. Du bist also doch in der Lage
/DESCRIPTION der Manpages besagter Shells zu lesen.

Das ist nicht folgelos, wenn man das zu dem Anspruch der bash, unter dem Name sh aufgerufen, dessen Verhalten emulieren zu können, in Beziehung setzt.

Zitat

> In der Regel haben diese Nachfolger das Feature, dass sie beim Aufruf
> prüfen, unter welchem Namen sie aufgerufen wurden, und wenn das /bin/sh ist,
> dann werden die Erweiterungen ausgeschaltet.
>
Der Kernel liefert, wenn er Shellscripte ausfuehren soll, die kein
"#!/path/to/interpreter" am Anfang stehen haben, ENOEXEC als
Fehlermeldung zurueck, und es ist Sache der Shell, dann noch etwas
vernuenftiges zu machen. tcsh, pdksh und tclsh machen es so dass sie
"/bin/sh script" starten.
Die Bash arbeitet da anders - sie fuehrt das Script (in dem schon
geforkten neuen Prozess) selbst aus (und sollte der Sinn der Uebung der
gewesen sein zu pruefen ob das Script fehlerfrei nicht nur unter Bash,
sondern auch unter einer "primitiveren" Shell laufen kann, dann hat man
Pech). rc (die Plan9-Shell) fuehrt Scripte ohne "#!" gar nicht erst aus
und bei csh ist es noch lustiger. Wenn das Script mit ":" beginnt, wird
es an /bin/sh weitergegeben, ansonsten selber ausgefuehrt.

Statt folgeloser Richtigkeit muss ich hier richtige Folgelosigkeit konstatieren -- zumindest was das eigentliche Thema angeht.
Aber ich habe wieder was gelernt; der Autor erhält einen Fleißpunkt

Zitat

> So ist das auch bei der bash, wie sich in der Doku leicht nachlesen
> lässt.
>
Dann zitiere doch bitte mal den entsprechenden Abschnitt (mit Quellenangabe).

Aus der Manual Page der bash, debian woody:
...
If bash is invoked with the name sh, it tries to mimic the startup behavior of
historical versions of sh as closely as possible, while conforming to the POSIX
standard as well.
...

Zusammenfassend:
Hey Chucky, Du mich auch!

> Halt mal, ich sage, es gibt zwei Familien, die Bären und die Affen und
> brüllst dazwischen:
> "Das ist Schwachsinn, weil es gibt nur einen Papa-Bär, und die Affen sind
> Scheisse, weil sie keinen Lachs fischen"
>
Dein Vergleich hinkt. Und zwar ganz gewaltig (so wie alle Vergleiche).

> BTW: Meinst Du nicht eigentlich abwärtskompatibel?
>
Nein. Sonst haette ich es geschrieben.

> Ein Unix-System V gibt es genau so wenig wie einen Lateiner.
>
Man moege mir verzeihen. Dann nennen wir es mal SVR4 oder System V
Release 4

> Meines Wissens ist die sh auf Aix ein Symlink auf die ksh, die dann die
> Extras abschaltet, vergleichbar der bash.
>
Nein.


> Steht nicht im Widerspruch zu meiner Aussage
>
Nein. Die Bourne-Shell wurde nicht von GNU oder "kommerziellen Unixen"
weiterentwickelt, sondern die Bourne-Shell als /bin/sh hat bei Linux
"ausgedient" und ist nicht mehr Bestandteil des Systems.

> Aus der Manual Page der bash, debian woody:
>
recursion(42). Die Erweiterungen werden nicht "abgeschaltet", sondern
lediglich POSIX-konform abgearbeitet.

Könnt ihr auch programmieren?

Noe. Ich kann weder Programmieren noch hab ich Ahnung von Un*x/Linux

Zitat

Original von rantanplan
Könnt ihr auch programmieren?

klar word-makros

Zitat

Original von rantanplan
Könnt ihr auch programmieren?

nur basic, da arbeitet man noch mit goto