Discussion :

[kochi56]

Bonjour,

Je suis sur une machine Solaris.
Je cherche a ordonnancer l'arrêt d'une base de données Sybase IQ.

Pour cela j'ai fais un script contenant l'appel au .profil et la commande qui permet de coupé ma base de données.

Voici mon script :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
/sybase/iq1510/.profile
/sybase/iq1510/IQ-15_1/bin64/dbstop -c "uid=DBA;pwd=sql;eng=iqif520;dbn=if5infoaco_aa;unconditional=true"

J'ai le message d'erreur suivant qui apparait dans mon fichier de log

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
stty: : No such device or address
/sybase/iq1510/arret_relance_sybaseIQ.ksh: -o: bad option(s)

[ok.Idriss]

Bonjour.

Le script fonctionne bien lorsqu'il est lancé manuellement ? Ou bien cette erreur n'apparait que lorsqu'il est lancé via un cron job ?

Si c'est le cas, merci de donner la ligne du cron job en question, on sait jamais (l'option "-o" inconnue y figure peut être par exemple).



Idriss

[kochi56]

Re,

Le script fonctionne bien lorsque je le lance directement.

Voici mon crontab

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

54 14 29 * * /sybase/iq1510/arret_relance_sybaseIQ.ksh > /sybase/iq1510/erreurs.log 2>&1

Merci d'avance pour votre aide.

[Sve@r]

Re,

Le script fonctionne bien lorsque je le lance directement.

Voici mon crontab

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

54 14 29 * * /sybase/iq1510/arret_relance_sybaseIQ.ksh > /sybase/iq1510/erreurs.log 2>&1

Merci d'avance pour votre aide.

Salut
Un cron que tu lances à 14h54 ??? C'est vrai qu'aucune heure n'est privilégiable par rapport à une autre mais intuitivement on a plutôt tendance à mettre des divisions parfaites de 60 comme 14h15 ou 14h30 ou même parfois 14h05.

Ceci dit, il serait aussi utile de contenu du .profile. Il faut savoir que le cron se lance sans terminal associé (normal, il est prévu pour travailler sans utilisateur). Et ce message qui parle de stty ressemble fort à un pb dû à ce manque de terminal.
De plus, un ".profile" ne s'exécute jamais mais se charge dans le contexte courant. C.a.d. qu'on ne lance pas .profile (dans un sous processus) mais source .profile (chargement dans le contexte courant). Bref peut-être que ton .profile n'est pas prévu pour s'exécuter 1) en tant que script et 2) dans un cron donc sans terminal...

De toute façon, si tu veux que le .profile soit intégré dans ton script, il faut le modifier ainsi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
source /sybase/iq1510/.profile
/sybase/iq1510/IQ-15_1/bin64/dbstop -c "uid=DBA;pwd=sql;eng=iqif520;dbn=if5infoaco_aa;unconditional=true"

Déjà ton script est mieux câblé. Et peut-être que ça résoudra même le problème...

[kochi56]

Bonjour,

Merci pour votre aide.

En faite l'heure paramétré dans le crontab c'est juste pour ne pas attendre trop longtemps quand je fais mon test (je change cette heure à chaque modif).

J'ai corrigé l'appel au .profile en ajoutant source devant.

Le message d'erreur à changé :

/sybase/iq1510/arret_relance_sybaseIQ.ksh: source: not found
ld.so.1: dbstop: fatal: libdblib11_r.so: open failed: No such file or directory
Killed

[Sve@r]

Le message d'erreur à changé :

/sybase/iq1510/arret_relance_sybaseIQ.ksh: source: not found

J'avais pas tilté que t'étais en ksh. L'instruction "source" est une instruction Bourne Again Shell mais n'existe pas en Korn. L'instruction d'origine est "." (point tout court) qui vient du Bourne Shell de base. Comme c'est pas trop parlant ce point tout court, ça a évolué en bash vers "source".

Ce qui me rappelle aussi qu'un script embarque toujours avec lui le nom de son exécutable. Pour qu'il puisse être exécuté par un autre utilisateur qui ne travaille pas forcément dans le même shell que celui du script.

Donc ton script devrait-être comme cela

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#!/bin/ksh
. /sybase/iq1510/.profile
/sybase/iq1510/IQ-15_1/bin64/dbstop -c "uid=DBA;pwd=sql;eng=iqif520;dbn=if5infoaco_aa;unconditional=true"

...

[jlliagre]

"source" est un bashisme qui ne choque bien sûr personne dans le forum GNU.
La syntaxe portable est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

. .profile

[ok.Idriss]

Ici on adore les bashismes

(perso j’utilise toujours "source" car je trouve ça plus lisible).

[disedorgue]

Bonjour,
Je ne savais pas que bash était plus vieux que csh

[Sve@r]

(perso j’utilise toujours "source" car je trouve ça plus lisible).

C'est aussi parce que les developpeurs de bash trouvaient ça plus lisible qu'ils l'ont créée...

[jlliagre]

Il ne l'ont pas créé mais repris de csh qui l'avait implémenté au moins dix ans plus tôt, c'est un bashisme issu d'un cshisme ...

Je n'ai jamais aimé source, il n'est pas portable, est plus long à taper, gaspille de la place et des électrons ...

Ça me rappelle les défenseurs du Pascal qui trouvaient begin et end plus lisibles que les { et } du C ...

[ok.Idriss]

Bonsoir.

Ça me rappelle les défenseurs du Pascal qui trouvaient begin et end plus lisibles que les { et } du C ...

Je ne plaide pas coupable, j'étais dans le camps des codeurs C

Par contre, j'aime pas trop le . parce qu'il a souvent un homonyme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

. ./script_a_sourcer.sh

Après ça ne me dérange pas plus que ça et je comprends tout à fait les problématiques de portabilité. Bien que pour ma part je ne travail que sur des environnements Bash/Linux ou bien avec mon mac perso pour lequel je bosse aussi avec bash et des commandes GNU, et je suis de ceux qui préfèrent profiter des nouveautés qu'apporte ce dernier et ne pas se limiter (depuis le temps, Bash est suffisamment rependu et éprouvé pour qu'on ne risque plus ces problèmes de portabilité dans beaucoup de cas).

Cordialement,
Idriss

[disedorgue]

Moi, je ne comprends pas trop ces problèmes de portabilité...
Personnellement quand je fais un script en bash, je ne lui mets pas un shebang sh ou ksh

[Sve@r]

Moi, je ne comprends pas trop ces problèmes de portabilité...
Personnellement quand je fais un script en bash, je ne lui mets pas un shebang sh ou ksh

Le fait de mettre un shebang n'est pas fait pour régler le problème de portabilité mais pour que différents utilisateurs, sur une même machine mais travaillant chacun dans un shell différent, puissent utiliser indifféremment les scripts de l'un ou de l'autre. C'est donc fait pour améliorer l'interopérabilité et non la portabilité.
Parce que même mettre#!/bin/bash ne règlera pas le problème si le script est utilisé sur un os unix qui ne possède pas /bin/bash. C'est ça le problème de portabilité...

[disedorgue]

J'ai du mal avec ça, les différents shell sont portés sur la plupart des OS, donc le fait de ne pas installer bash sur une machine et de vouloir utiliser un script bash, pour moi, c'est aussi incohérent que de vouloir par exemple utiliser un script perl sur une machine où il n'y a que python.
KSH et BASH sont censés avoir une compatibilité SH et donc je suis d'accord que l'on soit en droit de vouloir utiliser un script SH sur une machine où il n'y que bash ou ksh mais la portabilité s'arrête là.
Si on écrit un script bash ou ksh, on utilise le shebang en conséquence au moins pour dire en quoi le script a été pensé lors de son écriture.A charge de celui qui veut l'utiliser sur une autre machine, de modifier si besoin le shebang pour spécifier le nouvel endroit du même interprêteur ou de le porter sur son interprêteur préféré.

[Sve@r]

J'ai du mal avec ça, les différents shell sont portés sur la plupart des OS, donc le fait de ne pas installer bash sur une machine et de vouloir utiliser un script bash, pour moi, c'est aussi incohérent que de vouloir par exemple utiliser un script perl sur une machine où il n'y a que python.

Ben, oui mais parfois tu ne maitrises pas tout. Tu es sur Solaris et tu veux essayer un truc téléchargé sur le net manque de bol le script est écrit en zsh...

...A charge de celui qui veut l'utiliser sur une autre machine, de modifier si besoin le shebang pour spécifier le nouvel endroit du même interpréteur ou de le porter sur son interpréteur préféré.

"ou de le porter" donc tu as bien conscience qu'il y a un "problème de portabilité" à résoudre
Et qu'une des façons de le résoudre est de le réécrire en modifiant les instructions incompatibles avec l'environnement ciblé c.a.d. "le porter"...

[disedorgue]

"ou de le porter" donc tu as bien conscience qu'il y a un "pb de portabilité" à résoudre
Et qu'une des façons de le résoudre est de le réécrire en modifiant les instructions incompatibles avec l'environnement ciblé c.a.d. "le porter"...

Mais ici, on ne parle pas de la même chose, il est évident que l'on aura des problèmes de portabilité entre shell différents.
Ce que je ne conçois pas c'est de dire que l'on doit éviter d'utiliser tel ou tel instruction pour s'éviter des problèmes de portabilité inter-shell.
Je ne vois pas l'intéret d'avoir un shell plus complet que sh si on ne peut se permettre d'utiliser le plus du dit shell.
Ici, on parle de ne pas utiliser "source" au lieu "." pour des questions de portabilité, c'est ici que je ne comprends pas, un bash sur solaris comprendra l'instruction "source".
Après l'erreur cela a été de faire automatiquement du "bashisme" alors que la question porte sur du ksh.

[ok.Idriss]

Pour ma part je fait du SH ou KSH lorsque je sais que mes scripts sont destinés à une plateforme Unix non GNU.

Or j'en rencontre plus aujourd'hui (j'ai rencontré du HP-UX une fois et qui se faisait progressivement remplacer par du RedHat, j'ai testé FreeBSD et OpenSolaris chez moi mais juste pour le fun et non dans un cadre professionnel), il y en a encore c'est vrai mais je ne vois pas pourquoi il faudrait se limiter (parce quoi c'est pas uniquement profiter de syntaxes alternatives mais bien de profiter d'améliorations apportées par les shells récents) lorsqu'on ne bosse que pour des plateformes Linux qui sont aujourd'hui majoritaires.

Après être conscient des problématiques de portabilité c'est bien aussi, mais lorsqu'elles ont lieu. Bon on s'écarte un peu (beaucoup) du sujet initial, et puis de plus le cas ". vs source" n'est pas bien représentatif puisqu'il ne s'agit que de syntaxes équivalentes, dans ce cas précis je comprends à la limite la philosophie "autant choisir une syntaxe portable puisque ça n'apporte rien de plus" (je comprends seulement, j'applique pas car je considère que la lisibilité et davantage importante que la portabilité dans un contexte ou il n'est nul besoin de rendre mes scripts portables)

Dans le cas présent de toute façon, il vaut mieux utilise "." ça ne fait aucun doute.

[kochi56]

J'avais pas tilté que t'étais en ksh. L'instruction "source" est une instruction Bourne Again Shell mais n'existe pas en Korn. L'instruction d'origine est "." (point tout court) qui vient du Bourne Shell de base. Comme c'est pas trop parlant ce point tout court, ça a évolué en bash vers "source".

Ce qui me rappelle aussi qu'un script embarque toujours avec lui le nom de son exécutable. Pour qu'il puisse être exécuté par un autre utilisateur qui ne travaille pas forcément dans le même shell que celui du script.

Donc ton script devrait-être comme cela

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#!/bin/ksh
. /sybase/iq1510/.profile
/sybase/iq1510/IQ-15_1/bin64/dbstop -c "uid=DBA;pwd=sql;eng=iqif520;dbn=if5infoaco_aa;unconditional=true"

...

Bonjour,

Merci pour votre aide, il manquait en effet #!/bin/ksh au début de mon script.

Cordialement,

[Sve@r]

Merci pour votre aide, il manquait en effet #!/bin/ksh au début de mon script.

Mouais. Et comme le cron ne bosse pas en ksh mais en sh, il exécutait le script en sh d'où le pb initial.
N'oublie pas la de cliquer sur le bouton "RESOLU"...