avec KSH, j'utilise la commande 'cp /usr1/appli/data /export/donnees' pour
faire une copie du répertoire data vers le répertoire donnees. cela
fonctionne très bien !
mais dans un script, la même commande génère un message d'erreur :
exdata[6]: /bin/cp: 0403-027 Liste de paramètres trop longue.
Sur les Unix à deux balles, style *.BSD, sh c'est sh.
C'est quoi un unix à deux balles ?
-- Je ne suis pas d'accord. Je ne vois pas pourquoi il faudrait savoir réfléchir pour faire des AAD. C'est du pur racisme envers les participants actuels d'un groupe bientôt défunt. -+- MH in : <http://www.le-gnu.net> - So live and let split -+-
Moi <moi@ici.org> writes:
'Lut,
Sur les Unix à deux balles, style *.BSD, sh c'est sh.
C'est quoi un unix à deux balles ?
--
Je ne suis pas d'accord. Je ne vois pas pourquoi il faudrait savoir
réfléchir pour faire des AAD. C'est du pur racisme envers les
participants actuels d'un groupe bientôt défunt.
-+- MH in : <http://www.le-gnu.net> - So live and let split -+-
Sur les Unix à deux balles, style *.BSD, sh c'est sh.
C'est quoi un unix à deux balles ?
-- Je ne suis pas d'accord. Je ne vois pas pourquoi il faudrait savoir réfléchir pour faire des AAD. C'est du pur racisme envers les participants actuels d'un groupe bientôt défunt. -+- MH in : <http://www.le-gnu.net> - So live and let split -+-
Stephane Chazelas
2006-12-12, 18:50(+01), Moi:
ksh != sh même si ce sont des bournes, ils peuvent réagir différement
Sur la plupart des Unix commerciaux, ksh == sh ksh est une implementation du sh standard.
Sur les Unix à deux balles, style *.BSD, sh c'est sh.
Sur tous les Unix, sh, c'est a dire une implementation ou une autre du "sh" defini par la single unix specification ou eventuellement.
En l'occurrence, sur les BSD, il s'agit d'un shell derivé du Almquist shell.
Le Bourne shell est un vieux shell qu'on ne trouve aujourd'hui que sous tres peu d'OS et encore que pour backward compatibility pour des tres vieux scripts. Le Bourne shell n'est d'ailleurs pas un sh standard.
Pourquoi, bash c'est "standard" peut-être ?
bash quand appelé "sh" est quasi POSIX conformant avec certaines extensions XSI mais pas toutes comme le sh des BSDs.
L'exception la plus significative est son "echo" qui devrait afficher "-e<NL>" dans "echo -e" pour etre POSIX et qui devrait afficher "<NL>" dans echo 'nc' pour etre Unix (mais le comportement de echo pour bash peut etre modifié par une option de compilation).
Beaucoup de sh non-basés sur bash ont d'ailleurs le meme probleme. POSIX et Unix recommandent de toutes facons de ne pas utiliser echo.
[...]
Un lien "bash" à la Linux ?
Un lien vers bash est probablement ce qu'il y a de plus proche de ce qui est specifié a
ksh != sh
même si ce sont des bournes, ils peuvent réagir différement
Sur la plupart des Unix commerciaux, ksh == sh
ksh est une implementation du sh standard.
Sur les Unix à deux balles, style *.BSD, sh c'est sh.
Sur tous les Unix, sh, c'est a dire une implementation ou une
autre du "sh" defini par la single unix specification ou
eventuellement.
En l'occurrence, sur les BSD, il s'agit d'un shell derivé du
Almquist shell.
Le Bourne shell est un vieux shell qu'on ne trouve aujourd'hui
que sous tres peu d'OS et encore que pour backward compatibility
pour des tres vieux scripts. Le Bourne shell n'est d'ailleurs
pas un sh standard.
Pourquoi, bash c'est "standard" peut-être ?
bash quand appelé "sh" est quasi POSIX conformant avec certaines
extensions XSI mais pas toutes comme le sh des BSDs.
L'exception la plus significative est son "echo" qui devrait
afficher "-e<NL>" dans "echo -e" pour etre POSIX et qui devrait
afficher "<NL>" dans echo 'nc' pour etre Unix (mais le
comportement de echo pour bash peut etre modifié par une option
de compilation).
Beaucoup de sh non-basés sur bash ont d'ailleurs le meme
probleme. POSIX et Unix recommandent de toutes facons de ne pas
utiliser echo.
[...]
Un lien "bash" à la Linux ?
Un lien vers bash est probablement ce qu'il y a de plus proche
de ce qui est specifié a
ksh != sh même si ce sont des bournes, ils peuvent réagir différement
Sur la plupart des Unix commerciaux, ksh == sh ksh est une implementation du sh standard.
Sur les Unix à deux balles, style *.BSD, sh c'est sh.
Sur tous les Unix, sh, c'est a dire une implementation ou une autre du "sh" defini par la single unix specification ou eventuellement.
En l'occurrence, sur les BSD, il s'agit d'un shell derivé du Almquist shell.
Le Bourne shell est un vieux shell qu'on ne trouve aujourd'hui que sous tres peu d'OS et encore que pour backward compatibility pour des tres vieux scripts. Le Bourne shell n'est d'ailleurs pas un sh standard.
Pourquoi, bash c'est "standard" peut-être ?
bash quand appelé "sh" est quasi POSIX conformant avec certaines extensions XSI mais pas toutes comme le sh des BSDs.
L'exception la plus significative est son "echo" qui devrait afficher "-e<NL>" dans "echo -e" pour etre POSIX et qui devrait afficher "<NL>" dans echo 'nc' pour etre Unix (mais le comportement de echo pour bash peut etre modifié par une option de compilation).
Beaucoup de sh non-basés sur bash ont d'ailleurs le meme probleme. POSIX et Unix recommandent de toutes facons de ne pas utiliser echo.
[...]
Un lien "bash" à la Linux ?
Un lien vers bash est probablement ce qu'il y a de plus proche de ce qui est specifié a
Sur les Unix à deux balles, style *.BSD, sh c'est sh.
C'est quoi un unix à deux balles ?
Un truc en libre service que tu graves sur 2 ou 3 CD Le prix des CD vierges Et puis, c'est écrit plus haut: [Net|Free|Open]BSD
Stephane Chazelas
2006-12-12, 20:35(+00), Luc Habert:
Stephane Chazelas :
Quels sont les non-conformités de dash?
echo -n -e vs echo 'c...'
comme je disais
J'ai dit « dash », pas « bash ».
La, ca evolue aussi.
dash est basé sur le sh de soit OpenBSD soir NetBSD, je sais plus.
Ya "[" qui n'est pas standard.
[ ! = ! ]
renvoie false (enfin une erreur)
ce qui fait que [ "$a" = "$b" ] ne marche pas.
a=b=c,d d=foo IFS=,
export $a
n'exporte pas la variable "d"
Gasp! Je ne savais que la norme autorisait cette horreur.
Quelle "horreur"?
D'apres POSIX, "export" est une simple command comme une autre.
Donc
export $a
devrait etre parsé comme n'importe quelle
cmd $a
il n'y a pas de raison pour laquelle l'expansion de $a devrait etre faite differemment dans le cas d'export et pour les autres commandes. ash/dash, pdksh et zsh se comportent normalement, pas ksh ni bash. Pour ksh, c'est parce que "export" est plutot un attribut d'un assignment qu'une builtin command, pour bash, c'est pas clair.
-- Stéphane
2006-12-12, 20:35(+00), Luc Habert:
Stephane Chazelas :
Quels sont les non-conformités de dash?
echo -n -e vs echo 'c...'
comme je disais
J'ai dit « dash », pas « bash ».
La, ca evolue aussi.
dash est basé sur le sh de soit OpenBSD soir NetBSD, je sais
plus.
Ya "[" qui n'est pas standard.
[ ! = ! ]
renvoie false (enfin une erreur)
ce qui fait que [ "$a" = "$b" ] ne marche pas.
a=b=c,d
d=foo
IFS=,
export $a
n'exporte pas la variable "d"
Gasp! Je ne savais que la norme autorisait cette horreur.
Quelle "horreur"?
D'apres POSIX, "export" est une simple command comme une autre.
Donc
export $a
devrait etre parsé comme n'importe quelle
cmd $a
il n'y a pas de raison pour laquelle l'expansion de $a devrait
etre faite differemment dans le cas d'export et pour les autres
commandes. ash/dash, pdksh et zsh se comportent normalement, pas
ksh ni bash. Pour ksh, c'est parce que "export" est plutot un
attribut d'un assignment qu'une builtin command, pour bash,
c'est pas clair.
dash est basé sur le sh de soit OpenBSD soir NetBSD, je sais plus.
Ya "[" qui n'est pas standard.
[ ! = ! ]
renvoie false (enfin une erreur)
ce qui fait que [ "$a" = "$b" ] ne marche pas.
a=b=c,d d=foo IFS=,
export $a
n'exporte pas la variable "d"
Gasp! Je ne savais que la norme autorisait cette horreur.
Quelle "horreur"?
D'apres POSIX, "export" est une simple command comme une autre.
Donc
export $a
devrait etre parsé comme n'importe quelle
cmd $a
il n'y a pas de raison pour laquelle l'expansion de $a devrait etre faite differemment dans le cas d'export et pour les autres commandes. ash/dash, pdksh et zsh se comportent normalement, pas ksh ni bash. Pour ksh, c'est parce que "export" est plutot un attribut d'un assignment qu'une builtin command, pour bash, c'est pas clair.
-- Stéphane
Moi
Sur tous les Unix, sh, c'est a dire une implementation ou une autre du "sh" defini par la single unix specification ou eventuellement.
En l'occurrence, sur les BSD, il s'agit d'un shell derivé du Almquist shell.
Toutafé, j'ai regardé les sources de NetBSD, c'est Kenneth Almquist qui l'a écrit en 1989. On le trouve également sous le nom de ash. En attendant il est suffisant pour exécuter toute la scriptitude contenue dans un /etc ou pour faire la même chose sur petite machine.
bash quand appelé "sh" est quasi POSIX conformant avec certaines extensions XSI mais pas toutes comme le sh des BSDs.
Oui quand le lien est invoqué il change de mode. Si je me souviens bien des sources il y avait un coup de basename(3) au début
L'exception la plus significative est son "echo" qui devrait afficher "-e<NL>" dans "echo -e" pour etre POSIX et qui devrait afficher "<NL>" dans echo 'nc' pour etre Unix (mais le comportement de echo pour bash peut etre modifié par une option de compilation).
qui va s'amuser à recompiler ?
Beaucoup de sh non-basés sur bash ont d'ailleurs le meme probleme. POSIX et Unix recommandent de toutes facons de ne pas utiliser echo.
quel "echo" est exécuté dans un script ? le builtin ou l'autre ? je pense au builtin
Un lien vers bash est probablement ce qu'il y a de plus proche de ce qui est specifié a http://www.opengroup.org/onlinepubs/009695399/toc.htm
En attendant l'abus de basherie nuit gravement à l'exécution de commande simples. Il y a peu j'ai voulu compiler un truc sur NetBSD et oh surprise. Ca s'arrête en plein milieu. Il faut bash. Un simple lien bash-sh a résolu le problème. la basherie était inutile
Sur tous les Unix, sh, c'est a dire une implementation ou une
autre du "sh" defini par la single unix specification ou
eventuellement.
En l'occurrence, sur les BSD, il s'agit d'un shell derivé du
Almquist shell.
Toutafé, j'ai regardé les sources de NetBSD, c'est Kenneth Almquist
qui l'a écrit en 1989. On le trouve également sous le nom de ash.
En attendant il est suffisant pour exécuter toute la scriptitude
contenue dans un /etc ou pour faire la même chose sur petite machine.
bash quand appelé "sh" est quasi POSIX conformant avec certaines
extensions XSI mais pas toutes comme le sh des BSDs.
Oui quand le lien est invoqué il change de mode.
Si je me souviens bien des sources il y avait un coup de basename(3)
au début
L'exception la plus significative est son "echo" qui devrait
afficher "-e<NL>" dans "echo -e" pour etre POSIX et qui devrait
afficher "<NL>" dans echo 'nc' pour etre Unix (mais le
comportement de echo pour bash peut etre modifié par une option
de compilation).
qui va s'amuser à recompiler ?
Beaucoup de sh non-basés sur bash ont d'ailleurs le meme
probleme. POSIX et Unix recommandent de toutes facons de ne pas
utiliser echo.
quel "echo" est exécuté dans un script ?
le builtin ou l'autre ?
je pense au builtin
Un lien vers bash est probablement ce qu'il y a de plus proche
de ce qui est specifié a
http://www.opengroup.org/onlinepubs/009695399/toc.htm
En attendant l'abus de basherie nuit gravement à l'exécution de commande
simples. Il y a peu j'ai voulu compiler un truc sur NetBSD et oh
surprise. Ca s'arrête en plein milieu. Il faut bash. Un simple lien
bash-sh a résolu le problème. la basherie était inutile
Sur tous les Unix, sh, c'est a dire une implementation ou une autre du "sh" defini par la single unix specification ou eventuellement.
En l'occurrence, sur les BSD, il s'agit d'un shell derivé du Almquist shell.
Toutafé, j'ai regardé les sources de NetBSD, c'est Kenneth Almquist qui l'a écrit en 1989. On le trouve également sous le nom de ash. En attendant il est suffisant pour exécuter toute la scriptitude contenue dans un /etc ou pour faire la même chose sur petite machine.
bash quand appelé "sh" est quasi POSIX conformant avec certaines extensions XSI mais pas toutes comme le sh des BSDs.
Oui quand le lien est invoqué il change de mode. Si je me souviens bien des sources il y avait un coup de basename(3) au début
L'exception la plus significative est son "echo" qui devrait afficher "-e<NL>" dans "echo -e" pour etre POSIX et qui devrait afficher "<NL>" dans echo 'nc' pour etre Unix (mais le comportement de echo pour bash peut etre modifié par une option de compilation).
qui va s'amuser à recompiler ?
Beaucoup de sh non-basés sur bash ont d'ailleurs le meme probleme. POSIX et Unix recommandent de toutes facons de ne pas utiliser echo.
quel "echo" est exécuté dans un script ? le builtin ou l'autre ? je pense au builtin
Un lien vers bash est probablement ce qu'il y a de plus proche de ce qui est specifié a http://www.opengroup.org/onlinepubs/009695399/toc.htm
En attendant l'abus de basherie nuit gravement à l'exécution de commande simples. Il y a peu j'ai voulu compiler un truc sur NetBSD et oh surprise. Ca s'arrête en plein milieu. Il faut bash. Un simple lien bash-sh a résolu le problème. la basherie était inutile
