syntax error in custom script

[r_kleineisel]

Hallo,

ich versuche Freetz (http://svn.freetz.org/branches/freetz-stable-1.0, Revision 2636) für einen W900V zu kompilieren.

Ich bekomme immer die Fehlermeldung:

2008-10-06 17:41:20 (3.65 MB/s) - `fw_Speedport_W900V_v34.04.57.image' saved [5201920/5201920]

done.

STEP 1: UNPACK
unpacking firmware image
splitting kernel image
unpacking filesystem image
unpacking var.tar
unpacking tk image
done.

STEP 2: MODIFY
applying patches
installing mod base
replacing busybox
installing packages
invoking custom script
Badly placed ()'s.
ERROR: syntax error in custom script
make: *** [firmware-nocompile] Error 1

Außer dem "Alien Hardware Type" habe ich keine Pakete oder Optionen verändert.

Hat jemand eine Ahnung was das ist?

 

[RalfFriedl]

Hast Du etwas geändert an der custom Datei?

Was steht bei Dir in der Datei fwmod_custom ?

 

[Silent-Tears]

Häng mal bitte deine .config-Datei an. Und am besten die fwmod_custom dazu

 

[r_kleineisel]

config und fwmod_custom

sind anbei. Geändert habe ich nichts, nur "svn co", "make menuconfig" und den Hardware type gesetzt.

 

[RalfFriedl]

Hast Du ein ungewöhnliches System, evtl. MAC oder alte oder andere Shell?
Gib mal folgende Kommandos ein:

echo $SHELL
bash --version
bash -n fwmod_custom
$SHELL -n fwmod_custom

 

[r_kleineisel]

Hast Du ein ungewöhnliches System, evtl. MAC oder alte oder andere Shell?

Eigentlich nicht, aktuelles Fedora 9 Linux.

Gib mal folgende Kommandos ein:

$echo $SHELL
/bin/tcsh
$bash --version
GNU bash, version 3.2.33(1)-release (i386-redhat-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
$bash -n fwmod_custom
$$SHELL -n fwmod_custom
Badly placed ()'s.

Wenn ich erst eine bash aufrufe und dann darin "make", bekomme ich den Fehler aber wieder. Anschliießend bin ich wieder in der tcsh. Seltsam.

$bash
$ make
STEP 1: UNPACK
unpacking firmware image
splitting kernel image
unpacking filesystem image
unpacking var.tar
unpacking tk image
done.

STEP 2: MODIFY
applying patches
installing mod base
replacing busybox
installing packages
invoking custom script
Badly placed ()'s.
ERROR: syntax error in custom script
make: *** [firmware-nocompile] Error 1
$ echo $SHELL
/bin/tcsh

 

[McNetic]

Anscheinend hat unser Build-Prozess noch Schwächen im Bezug auf die Auswahl/Nutzung der korrekten Shell. Es wird auf jeden Fall eine Bash oder zumindest sehr Bash-kompatible Shell vorrausgesetzt. Ich denke aber, daß, wenn die Bash im System vorhanden ist, es auch unter einer anderen Shell funktionieren sollte.

Um das Problem zu umgehen, könntest Du jetzt noch versuchen, bei Deinem User als Login Shell die Bash einzutragen (bei Bedarf nach googlen, hat was mit /etc/passwd zu tun), aus- und wieder neu einzuloggen, und dann nochmal zu probieren.

EDIT:
Wenn das nicht funktioniert, könntest Du mal bitte nachsehen, worauf /bin/sh zeigt (ls -l /bin/sh). Wenn das nicht bash ist, könntest Du das mal ändern (als root: rm /bin/sh; ln -s bash /bin/sh und dann nochmal probieren.

Wenn alles nix hilft, dann liegt es wohl doch nicht an der Shell, denke ich. Wenn eine der beiden Möglichkeiten hilft, könntest Du mal ein Ticket im Trac diesbezüglich aufmachen, denn dann ist es ein Bug, der behoben werden sollte.

 

[r_kleineisel]

Wenn ich meine Login-Shell (im /etc/passwd) auf bash stelle ist der Fehler weg und Freetz läuft durch. Ich verstehe zwar nicht, warum man keine tcsh verwenden kann, aber das ist zumindest ein Workaround.

/bin/sh zeigt auf bash.

 

[olistudent]

Wir haben doch im Makefile schon ein Variable SHELL und in den fwmod's schon /bin/bash im shebang!?

MfG Oliver

 

[McNetic]

Hehe. Genau das ist das Problem. Im Makefile wird SHELL definiert; im fwmod aber nicht. Dort wird es trotzdem genutzt, um fwmod_custom aufzurufen. Dadurch wiederum wird die Shebang-Zeile ausser Kraft gesetzt. Ich habe das im aktuellen Trunk mal so behoben, daß ich oben in fwmod auch die Shell-Variable setze; ob das so ideal ist, weiss ich noch nicht.

 

[olistudent]

fwmod wird doch vom Makefile als Kindprozess gestartet. Müsste die Variable da nicht weitergegeben werden?

MfG Oliver

 

[McNetic]

Nein, sie wird nicht exportiert. Das wär noch ne (vielleicht bessere) Alternative.

 

[RalfFriedl]

Im Makefile wird SHELL definiert; im fwmod aber nicht. Dort wird es trotzdem genutzt, um fwmod_custom aufzurufen. Dadurch wiederum wird die Shebang-Zeile ausser Kraft gesetzt.

Das ist nicht ganz richtig. $SHELL wird nur verwendet, um den Syntax-Check von fwmod_custom durchzuführen ($SHELL -n "${BASE_DIR}/fwmod_custom"). Für den Aufruf danach wird fwmod_custom normal aufgerufen, und folgluch wird dafür auch bash verwendet, bzw. würde verwendet werden, wenn der Syntax-Check mit der Default-Shell durchgehen würde.

Ich habe das im aktuellen Trunk mal so behoben, daß ich oben in fwmod auch die Shell-Variable setze; ob das so ideal ist, weiss ich noch nicht.

Die bessere Lösung ist, bei der Syntax-Prüfung $SHELL durch bash zu ersetzen: "bash -n "${BASE_DIR}/fwmod_custom". Damit ist klar, daß das Skript immer mit bash aufgerufen werden soll. Ansonsten entsteht der Eindruck "Welche Shell auch immer der Benutzer eingestellt hat, nur daß viel weiter vorne im Skript SHELL fest auf bash eingestellt wurde". Im Endergebnis ist es aber das gleiche.

Eine andere Frage ist, ob der Syntax-Check überhaupt notwendig ist. Wenn es Syntax-Fehler im custom-Skript gibt, wird dieses mit Fehler abbrechen. Wenn es logische Fehler enthält, werden diese vom Syntax-Check nicht erkannt, und die logischen Fehler sind meistens die schlimmeren.

@r_kleineisel
Abgesehen von den bereits genannten Änderungen hätte es auch gereicht, statt eine andere Shell in /etc/passwd einzutragen, die SHELL nur für den aktuellen Prozeß umzustellen:

SHELL=/bin/bash make
oder
export SHELL=/bin/bash
make

 

[McNetic]

Klar, man kann auch fest 'bash' eintragen. Die Variablen sind aber ja da, um das Ganze parametriesierbar zu machen, darum dachte ich, es wäre sinnvoller, das ganz oben zu definieren, wie man das ja üblicherweise mit Konstanten macht.

[...]
Eine andere Frage ist, ob der Syntax-Check überhaupt notwendig ist. Wenn
[...]

Notwendig ist er nicht; es gibt für den unbedarften User aber eine bessere Fehlermeldung, weil gleich klar ist, warum der Prozess nicht durchläuft.

 

[RalfFriedl]

Variablen sind aber ja da, um das Ganze parametriesierbar zu machen.

Eben, aber in diesem Fall wird nur der Eindruck erweckt, es wäre parametrisierbar, während es das eben nicht ist, weil nur bash richtig ist.

 

[McNetic]

Ja, das betrifft dann aber auch andere Stellen, wo es so aufgerufen wird. Insbesondere ist die vorherige Variante (die ja auch die Variable SHELL benutzte) gleichwertig. Letztendlich ist mir auch egal, wie es auf Dauer gelöst wird; so wie es war, war es eben fehlerhaft.