BASH-Script Probleme

[ChrisF1977]

Hi,

ich habe hier folgendes Script:

echo "Multiconvert Script for Images"
DEF_PFAD=$PWD
echo "Pfad zu den Bildern [$DEF_PFAD]"

#Eingabe der Zieldaten
echo "Dateityp (jpg, tif, gif)"
read FILETYPE

for i in *$FILETYPE; do

                mogrify -font arial -fill white -draw "text 10,10 '(c) www.forgotten-tears.de'" -font arial -fill black -draw "text 11,11 '\
(c) www.forgotten-tears.de'" "$i"
done

Dieses Script läuft unter Linux (BASH) und unter Windows-Cygwin (BASH) ohne Probleme. Nur hier unter OS-X in ner Bash läuft das nicht.
Beim Ausführen kommt folgender Fehler:

[chris@powermac:/Volumes/HD_2/Pictures/Digital_Archiv/2007-01-21_drf_Harz/web]$ convert_console.sh
: command not foundnts/Documents/scripte/convert_console.sh: line 1: 
Multiconvert Script for Images
]fad zu den Bildern [/Volumes/HD_2/Pictures/Digital_Archiv/2007-01-21_drf_Harz/web
: command not foundnts/Documents/scripte/convert_console.sh: line 5: 
Dateityp (jpg, tif, gif)
tif
': not a valid identifiercuments/scripte/convert_console.sh: line 8: read: `FILETYPE
: command not foundnts/Documents/scripte/convert_console.sh: line 9: 
'Users/chris/Documents/Documents/scripte/convert_console.sh: line 10: syntax error near unexpected token `do
'Users/chris/Documents/Documents/scripte/convert_console.sh: line 10: `for i in *$FILETYPE; do
[chris@powermac:/Volumes/HD_2/Pictures/Digital_Archiv/2007-01-21_drf_Harz/web]$

Wasn das los?

MfG
Chris

 

[jpv]

Moin, hast Du möglicherweise nicht Bash sondern eine andere Shell laufen? ich habe das Script mal in eine Textdatei kopiert und nach einem chmod 755 ausgeführt. Dann kommt bei mir tatsächlich nur ganz korrekt: ./test: line 11: mogrify: command not found
(ich habe mogrify nicht ). Ich nutze 10.4 auf einem Intel ...
Gruß, jpv

 

[ChrisF1977]

Moin, hast Du möglicherweise nicht Bash sondern eine andere Shell laufen? ich habe das Script mal in eine Textdatei kopiert und nach einem chmod 755 ausgeführt. Dann kommt bei mir tatsächlich nur ganz korrekt: ./test: line 11: mogrify: command not found
(ich habe mogrify nicht ). Ich nutze 10.4 auf einem Intel ...
Gruß, jpv

Also ist schon die BASH die läuft:

[chris@powermac:~]$ echo $SHELL
/bin/bash
[chris@powermac:~]$

 

[oneOeight]

wenn du nicht explizit eine path setzt solltest du in shell-scripten immer den vollen pfad zu den executables benutzen...
/bin/echo usw

 

[ChrisF1977]

wenn du nicht explizit eine path setzt solltest du in shell-scripten immer den vollen pfad zu den executables benutzen...
/bin/echo usw

Die Pathvariable ist aber gesetzt:

[chris@powermac:~]$ echo $PATH
/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin:/usr/X11R6/bin:/opt/local/bin:/opt/local/lib:/Applications/Graphic/ImageMagick/bin/:/Users/chris/Documents/Documents/scripte/
[chris@powermac:~]$

Oder was meinst du damit?

 

[mapfel]

Hi,

Du must schon angeben welchen Interpreter Du verwenden willst.
Entweder du gibst an der Kommandozeile "sh mein_script.sh" an, oder Du schreibst den Pfad zum Interpreter in Dein Script (Sheebang Zeile):

#!/bin/bash

Muss in der ersten Zeile Deines Scripts stehen. Ich denke mal unter Linux wird per default die Bash benutzt, und unter Windows auch... Unter OS X ist es wahrscheinlich AS.

Gruss,

Martin

 

[Gerundium]

Vermutlich verschluckt er sich an den line breaks von Windows. Speichere das Script im Mac oder Unix Format ab; beispielsweise mit "pico" öffnen und anschließend einfach speichern.

 

[dpr]

Vermutlich verschluckt er sich an den line breaks von Windows.

Entweder das oder Du hast Spaces in Dateinamen oder Pfaden dorthin und das Quoting im Script stimmt noch nicht.

wenn du nicht explizit eine path setzt solltest du in shell-scripten immer den vollen pfad zu den executables benutzen...
/bin/echo usw

Sorry, aber volle Pfade sind (Thema Portier- und Wartbarkeit) ein absolutes No-Go.

 

[jpv]

So, jetzt habe ich auch den Link wiedergefunden, den ich noch hinzufügen wollte: Bash Commands MAN Pages

Dort gibts auch einen Link auf die MacOSX tcsh Shell

 

[maceis]

...
Sorry, aber volle Pfade sind (Thema Portier- und Wartbarkeit) ein absolutes No-Go.

Sorry, aber relative Pfade sind in Hinblick auf Sicherheit ein absolutes No-Go.
Im harmlosesten Fall wird anstelle des gewünschten Befehls (z. B. /usr/bin/find) ein Ersatz (z.B. fink /sw/bin/find) ausgeführt, der andere Optionen verwendet und deswegen nicht das gewünschte Ergebnis liefert. Die ungünstigeren Fälle dürft Ihr Euch selbst ausmalen.

 

[dpr]

Sorry, aber relative Pfade sind in Hinblick auf Sicherheit ein absolutes No-Go.

Der Amerikaner würde sagen: "That's what PATH is for".

Ein schönes Negativ-Beispiel ist/war DB2 für Linux, fein mit absoluten Pfaden in ein rpm gepackt. Die {pre,post}{inst,rm}-Scripte ließen sich mit etwas Aufand fixen, übrig blieben die Binaries, die natürlich auch absolute Pfade der System-Utilities enthielten. Die ganze Geschichte war sicher, keine Frage; lief nur dummerweise (out-of-the-box) nicht auf den Distributionen, die nicht der Zieldistribution des Herstellers entsprachen.

 

[maceis]

Der Amerikaner würde sagen: "That's what PATH is for".
...

Da spricht ja auch grundsätzlich nichts dagegen.
Nur sollte man jedoch sicherstellen, dass im PATH die gewünschten Kommandos auch an erster Stelle gefunden werden.
Wen ich mir das hier:

[chris@powermac:~]

$ echo $PATH
/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin:/usr/X11R6/bin:/opt/local/bin:/opt/local/lib:/Applications/Graphic/ImageMagick/bin/:/Users/chris/Documents/Documents/scripte/

... so ansehe, hab ich da aber gewisse Zweifel.
Hier werden z.B. die Fink Ersatzkommandos vor den gleichnamigen systemeigenen Kommandos gefunden. Da passt dann u.U noch nicht einmal die manpage zum Kommando, das zuerst gefunden wird.

 

[dpr]

Hier werden z.B. die Fink Ersatzkommandos vor den gleichnamigen systemeigenen Kommandos gefunden. Da passt dann u.U noch nicht einmal die manpage zum Kommando, das zuerst gefunden wird.

Zur Ehrenrettung von Fink muß man allerdings ergänzen, daß zwar die Kommandos vor den systemeigenen gefunden werden, Fink allerdings auch MANPATH konsistent anpaßt: zuerst Fink, dann der Rest. Das mag für die interaktive Arbeit praktikabel sein.

Richtig ist natürlich, daß PATH innerhalb des Shell-Scripts neu gesetzt gehört.