pdksh AIX : peut-on inhiber la vérification syntaxique d'un fichier sourcé ? [Résolu]

[jack-ft]

Bonjour,

je voudrais que mon ~/.kshrc puisse être le même pour du ksh que pour du bash.

Pour cela, j'ai mis les fonctions spécifiques bash à la fin, après un return si le shell est un ksh.

ça marche bien sous Linux 2.6.18-128.7.1.el5 (KSH_VERSION='@(#)PD KSH v5.2.14 99/07/13.2'), mais ça ne marche pas sous AIX (je ne sais pas quelle version de pdksh) car ce dernier vérifie manifestement la syntaxe de TOUT le fichier avant de commencer à le sourcer!!!

Est-il possible d'inhiber ce comportement?

Voici un exemple hyper-simplifié avec une erreur de syntaxe volontaire pour illustrer le problème:

Code :

1
2
3
4
$ cat ./bug_syntax.ksh 
echo coucou
return 0
fi

Et voici le comportement sous linux:

Code :

1
2
linux$ . ./bug_syntax.ksh 
coucou

ça me convient parfaitement.

Et voici le comportement sous AIX:

Code :

1
2
AIX$ . ./bug_syntax.ksh                  
ksh: 0403-057 Syntax error: `fi' is not expected.

Même en rajoutant des "set -x" ou "set -v", rien n'y fait! Il refuse systématiquement d'exécuter les lignes "echo" et "return".

Quelqu'un a-t-il une idée pour changer ce comportement?

Merci d'avance
)jack(

[frp31]

a ma connaissance on peut pas changer ce comportement sous AIX, mais un second avis devrai confirmer.

[Mygale1978]

Salut,

Je ne comprends pas très bien ta logique. Pourquoi vouloir à tout prix masquer un problème plutôt que d'essayer de le corriger?

[jack-ft]

Envoyé par Mygale1978

Salut,

Je ne comprends pas très bien ta logique. Pourquoi vouloir à tout prix masquer un problème plutôt que d'essayer de le corriger?

J'avais simplifié l'exemple pour ne pas vous importuner avec un long discours ni prendre trop de votre temps, mais, puisque tu me demandes explicitement ma logique, la voici:

En fait, j'ai 2 besoins:
-1- debeuguer un programme ksh
J'ai un "script.ksh" qui "charge" plein de fichiers de fonctions et contient (entre autres):

Code :

. chemin/vers/script_avec_bug.ksh

Le fichier "script_avec_bug.ksh" (de plusieurs centaines de lignes) contient une erreur de syntaxe pas évidente à trouver (genre un backquote unique à l'intérieur d'un "$( ...`...)", par exemple).
Lorsque j'exécute "script.ksh" sous AIX, j'ai un (laconique) message qui ne me renseigne pas sur l'endroit du bug!
Et l'option "set -x" ou l'insertion de traces ne fonctionne pas.
En fait, on a déjà résolu un problème semblable par dichotomie (en supprimant la moitié des fonctions, puis le quart, etc.), mais c'est beaucoup plus fastidieux qu'un simple "set -x" au début du fichier!

-2- ~/.kshrc
je voudrais bien avoir un unique fichier ~/.kshrc qui fonctionne aussi bien pour un ksh que pour un bash.
Pour cela, j'ai mis les fonctions spécifiques bash à la fin, après un return si le shell est un ksh:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# ----------------------------------------------------------------
# [jack] 110120 Alias common to ksh and bash
[snip]
# ----------------------------------------------------------------
# [jack] 111118 Specific to ksh

if ! dirs >/dev/null 2>&1 ; then
    # Not a bash
    set -o emacs
    stty erase 
    if [ -z "${COLUMNS-}" ] ; then export COLUMNS=180 ; fi
    [snip]
    return 0
fi

# ----------------------------------------------------------------
# [jack] 110131 Alias specific to bash (not suitable for ksh)

alias dsa='dirs | tr '\'' '\'' '\''\n'\'''

function ds {
    for (( i=0; i<${#DIRSTACK[@]}; i++ )); do
	printf "%2d %s\n" $i ${DIRSTACK[$i]}
    done | sed -e "s:${HOME}:~:"
}

[snip]

AIX refuse d'exécuter la moindre ligne du script sous prétexte qu'il contient "for ((" alors que je ne lui demande pas d'aller jusque là, mais de s'arrêter au "return"!

S'il est vraiment impossible de changer le comportement du ksh sous AIX, j'aurai toujours la ressource d'abandonner le souhait d'avoir un unique fichier (facile à transporter de machine en machine et à administrer) pour le remplacer par 3 fichiers (après vérification):

Code :

1
2
3
4
5
6
 
if [[[[test que le shell est un ksh]]]] ; then 
    . .ksh_aliases
elif [[[[test que le shell est un bash]]]] ; then
    . .bash_aliases
fi

Voilà donc mes problèmes.

Merci de votre patience!

)jack(

[Sve@r]

Envoyé par jack-ft

En fait, on a déjà résolu un problème semblable par dichotomie (en supprimant la moitié des fonctions, puis le quart, etc.), mais c'est beaucoup plus fastidieux qu'un simple "set -x" au début du fichier!

Salut

Tu peux aussi essayer d'identifier grossièrement la zone (style une trentaine de lignes) qui pourraient contenir le bug et mettre "set -x" en début de cette zone et "set +x" après...

Envoyé par jack-ft

-2- ~/.kshrc
je voudrais bien avoir un unique fichier ~/.kshrc qui fonctionne aussi bien pour un ksh que pour un bash.
Pour cela, j'ai mis les fonctions spécifiques bash à la fin, après un return si le shell est un ksh:

Code :

AIX refuse d'exécuter la moindre ligne du script sous prétexte qu'il contient "for ((" alors que je ne lui demande pas d'aller jusque là, mais de s'arrêter au "return"!

Bizarre. Je confirme que le shell standard interprète et exécute chaque ligne qu'il voit quand il la voit. C'est d'ailleurs pour ça qu'on est obligé d'écrire les fonctions avant de les appeler. Toutefois j'ai déjà eu de mon coté des surprises avec le ksh d'AIX. Notemment un truc de ce genre

Code bash :

1
2
3
4
5
6
7
#!/bin/ksh
i=0
cat /etc/passwd | while read l
do
    i=`expr $i + 1`
done
echo $i

Et d'avoir en fin de boucle (donc en dehors du processus qui a modifié la variable) la bonne valeur pour i

Envoyé par jack-ft

S'il est vraiment impossible de changer le comportement du ksh sous AIX, j'aurai toujours la ressource d'abandonner le souhait d'avoir un unique fichier (facile à transporter de machine en machine et à administrer) pour le remplacer par 3 fichiers (après vérification):

Code :

Il semble en effet que c'est ce qu'il y a de mieux à faire...

[jack-ft]

Envoyé par Sve@r

Salut
Tu peux aussi essayer d'identifier grossièrement la zone (style une trentaine de lignes) qui pourraient contenir le bug et mettre "set -x" en début de cette zone et "set +x" après...

Bizarre. Je confirme que le shell standard interprète et exécute chaque ligne qu'il voit quand il la voit.

Ben justement non!!!!! (en tout cas, pas chez moi)

Je te rappelle que c'est une erreur de syntaxe et non un bug et que le pdksh d'AIX n'exécute AUCUNE ligne tant qu'il reste des erreurs de syntaxe!
Pas même un "set -x" ni un "echo".
C'est ce que j'explique dans mon premier message et c'est précisément ce comportement que je cherche à modifier!
Je voudrais bien pouvoir mettre un "set -x" ou un "echo" dans mon fichier pour localiser l'erreur de syntaxe!

Oops! Note importante: je viens de refaire un essai et j'ai été surpris de le voir exécuter les premières lignes d'un nouveau fichier de test contenant des erreurs de syntaxe... puis je me suis aperçu que j'avais fait (quasiment sans y penser) un "chmod +x test.ksh". Or, c'est précisément ce qu'il ne faut pas faire! En fait, ce comportement particulier se produit uniquement lorsqu'on SOURCE le fichier et non lorsqu'on l'exécute.
(Évidemment, il est clair que c'est beaucoup moins clair en ksh qu'en csh!)

Sve@r, peux-tu me confirmer que tu as bien sourcé et non exécuté ton fichier de test?

Il semble en effet que c'est ce qu'il y a de mieux à faire...

J'ai effectivement découpé mon (maigre) .kshrc en 2 mais ça ne résout pas mon problème pour la recherche de bugs dans un gros script qui source plusieurs autres gros scripts... quoique... je vais voir si je peux utiliser cette différence de comportement en essayant d'exécuter plutôt que sourcer...

)jack(

[matafan]

J'ai le même comportement que toi. Lorsque le fichier est sourcé (et seulement dans ce cas), le ksh d'AIX n'exécute rien si le fichier contient une erreur de syntaxe.

Par contre tu peux contourner le problème en ne gardant que la partie commune dans ton script principal. Tu met les parties spécifiques ksh et les parties spécifiques bash dans deux fichier séparés, que tu source dans le fichier principal suivant le shell que tu utilises. En effet il ne semble que ksh ne vérifie syntaxiquement que le fichier sourcé, pas les fichiers sourcés par le fichier sourcé.

[jack-ft]

Envoyé par matafan

J'ai le même comportement que toi. Lorsque le fichier est sourcé (et seulement dans ce cas), le ksh d'AIX n'exécute rien si le fichier contient une erreur de syntaxe.

Ouf! Je suis rassuré!

Par contre tu peux contourner le problème en ne gardant que la partie commune dans ton script principal. Tu met les parties spécifiques ksh et les parties spécifiques bash dans deux fichier séparés, que tu source dans le fichier principal suivant le shell que tu utilises.

Oui, oui. c'est bien ce que je disais dans les messages précédents: pour mon petit .kshrc, pas de problème: je l'ai découpé en 2.

Le problème, c'est pour trouver un bug dans un gros script qui source plein de scripts (dont un assez gros avec une erreur de syntaxe!).
Si le cas se présente de nouveau, plutôt que de faire par dichotomie (ce qui nous a pris du temps), j'essaierai de voir si je peux exécuter le programme, mais je doute que ça marche...

En effet il ne semble que ksh ne vérifie syntaxiquement que le fichier sourcé, pas les fichiers sourcés par le fichier sourcé.

Euh... d'après ce que j'ai cru constater, il vérifie dynamiquement les fichiers sourcés. Voici ce que j'entends par dynamiquement:

Si je source A, il vérifie A avant son "sourçage" (exécution des instructions de A dans l'environnement du process courant).

Si au cours du "sourçage" de A, il "tombe" sur l'instruction ". B", alors, avant de commencer à sourcer B, il en vérifie la syntaxe puis, si c'est bon, il le source, sinon il sort en erreur (je n'ai pas essayé de mettre un trap ERR ni EXIT).
Cependant, si le code de A contient une instruction ". C" mais que le sourçage de A ne passe jamais par cette instruction, alors il ne va pas vérifier la syntaxe de C.

Ça semble assez logique, vu que le fichier pourrait même ne pas exister:

Code :

if [[ -r "$file" ]]; then . "$file"; fi

Bref... encore une différence avec Linux...

)jack(

[Sve@r]

Envoyé par jack-ft

Ben justement non!!!!! (en tout cas, pas chez moi)

Je te rappelle que c'est une erreur de syntaxe et non un bug et que le pdksh d'AIX n'exécute AUCUNE ligne tant qu'il reste des erreurs de syntaxe!
Pas même un "set -x" ni un "echo".
C'est ce que j'explique dans mon premier message et c'est précisément ce comportement que je cherche à modifier!
Je voudrais bien pouvoir mettre un "set -x" ou un "echo" dans mon fichier pour localiser l'erreur de syntaxe!

Oops! Note importante: je viens de refaire un essai et j'ai été surpris de le voir exécuter les premières lignes d'un nouveau fichier de test contenant des erreurs de syntaxe... puis je me suis aperçu que j'avais fait (quasiment sans y penser) un "chmod +x test.ksh". Or, c'est précisément ce qu'il ne faut pas faire! En fait, ce comportement particulier se produit uniquement lorsqu'on SOURCE le fichier et non lorsqu'on l'exécute.

Bon ben t'as ta solution. Exécute ton test.ksh jusqu'à trouver l'erreur de syntaxe, puis une fois celle-ci corrigée, tu pourras alors le sourcer sans ennui...

Envoyé par jack-ft

Si le cas se présente de nouveau, plutôt que de faire par dichotomie (ce qui nous a pris du temps), j'essaierai de voir si je peux exécuter le programme, mais je doute que ça marche...

Et pourquoi cela ne marcherait-il pas ??? Evidemment tu pourrais avoir une erreur dans une fonction que ton script n'appelle jamais (puisque destiné à être sourcé) mais rien ne t'interdit de programmer un cas particulier dans ce style

Code bash :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#!/bin/sh
fct1()
{
    ....
}
 
fct2()
{
    ....
}
etc
 
if test "$1" = "main"
then
    fct1
    fct2
fi

Pour tester tu appelles ton script en lui passant le mot clef "main" et une fois qu'il est ok alors tu le sources...