J'ai vu qu'il y avait déjà des discussion a` ce sujet, mais je ne suis
pas réussi a trouver les réponses a mes questions (seulement 2).
Si les réponses existent déjà (je crois que oui) sur internet je serai
heureux si vous me pouvez adresser.
Les questions sont:
1. des scripts écrits en bash ou en ksh ou en bourne shell peuvent avoir
des problèmes a` marcher sous zsh?
2. ou` (sur quels systèmes UNIX) je trouve déjà nativement zsh et sur
quels je la dois installer et quoi comporte l'installer?
Merci a tous ceux qui me répondrons, salutations a tout le monde,
1. des scripts écrits en bash ou en ksh ou en bourne shell peuvent avoir des problèmes a` marcher sous zsh?
Il y a pas mal de differences entre ces differents shells, du moins dans leur comportement par defaut respectif.
Maintenant pourquoi voudrais-tu faire interpreter un script ecrit pour bash ou ksh par zsh ? A part pour /etc/profile, je ne vois pas l'interet.
Je pensais generiquement a des problemes de compatibilite et peut etre de development pour les quels qui connais l'une n'a pas problemes avec les autres.
2. ou` (sur quels systèmes UNIX) je trouve déjà nativement zsh et sur quels je la dois installer et quoi comporte l'installer?
[...]
Sur MacOSX et sur Solaris 8+ (si tu installes tout, mais c'est une tres vieille version).
Solaris 8+ est >=8?
Tu dois pouvoir trouver des packages binaires sur la plupart des systemes. Sinon, tu peux toujours compiler.
Merci,
Andrea
Stephane Chazelas wrote:
2004-10-30, 18:37(+00), andrea ferraris:
[...]
1. des scripts écrits en bash ou en ksh ou en bourne shell peuvent
avoir des problèmes a` marcher sous zsh?
Il y a pas mal de differences entre ces differents shells, du
moins dans leur comportement par defaut respectif.
Maintenant pourquoi voudrais-tu faire interpreter un script
ecrit pour bash ou ksh par zsh ? A part pour /etc/profile, je ne
vois pas l'interet.
Je pensais generiquement a des problemes de compatibilite et peut etre
de development pour les quels qui connais l'une n'a pas problemes avec
les autres.
2. ou` (sur quels systèmes UNIX) je trouve déjà nativement zsh et
sur quels je la dois installer et quoi comporte l'installer?
[...]
Sur MacOSX et sur Solaris 8+ (si tu installes tout, mais c'est
une tres vieille version).
Solaris 8+ est >=8?
Tu dois pouvoir trouver des packages binaires sur la plupart des
systemes. Sinon, tu peux toujours compiler.
1. des scripts écrits en bash ou en ksh ou en bourne shell peuvent avoir des problèmes a` marcher sous zsh?
Il y a pas mal de differences entre ces differents shells, du moins dans leur comportement par defaut respectif.
Maintenant pourquoi voudrais-tu faire interpreter un script ecrit pour bash ou ksh par zsh ? A part pour /etc/profile, je ne vois pas l'interet.
Je pensais generiquement a des problemes de compatibilite et peut etre de development pour les quels qui connais l'une n'a pas problemes avec les autres.
2. ou` (sur quels systèmes UNIX) je trouve déjà nativement zsh et sur quels je la dois installer et quoi comporte l'installer?
[...]
Sur MacOSX et sur Solaris 8+ (si tu installes tout, mais c'est une tres vieille version).
Solaris 8+ est >=8?
Tu dois pouvoir trouver des packages binaires sur la plupart des systemes. Sinon, tu peux toujours compiler.
Merci,
Andrea
Nicolas George
Eric Masson wrote in message :
Bref, il vaut mieux éviter autant que possible un particularité liée à un shell dit évolué pour assurer une portabilité maximale.
Ça serait vrai si on commence par « #!/bin/sh » et qu'on met ensuite des bashismes ou des zshismes. Mais si on commence honnêtement par un « #!/bin/bash » ou un « #!/bin/zsh », je ne vois pas pourquoi on se priverait d'utiliser les fonctionnalités supplémentaires, qui sont quand même bien pratiques, en particulier pour faire des scripts robustes (pas de problèmes avec les fichiers dont le nom est pénible, etc.).
Eric Masson wrote in message
<86vfco8e5i.fsf@srvbsdnanssv.interne.kisoft-services.com>:
Bref, il vaut mieux éviter autant que possible un particularité liée à
un shell dit évolué pour assurer une portabilité maximale.
Ça serait vrai si on commence par « #!/bin/sh » et qu'on met ensuite des
bashismes ou des zshismes. Mais si on commence honnêtement par un
« #!/bin/bash » ou un « #!/bin/zsh », je ne vois pas pourquoi on se
priverait d'utiliser les fonctionnalités supplémentaires, qui sont quand
même bien pratiques, en particulier pour faire des scripts robustes (pas de
problèmes avec les fichiers dont le nom est pénible, etc.).
Bref, il vaut mieux éviter autant que possible un particularité liée à un shell dit évolué pour assurer une portabilité maximale.
Ça serait vrai si on commence par « #!/bin/sh » et qu'on met ensuite des bashismes ou des zshismes. Mais si on commence honnêtement par un « #!/bin/bash » ou un « #!/bin/zsh », je ne vois pas pourquoi on se priverait d'utiliser les fonctionnalités supplémentaires, qui sont quand même bien pratiques, en particulier pour faire des scripts robustes (pas de problèmes avec les fichiers dont le nom est pénible, etc.).
Eric Masson
"Nicolas" == Nicolas George <nicolas$ writes:
Nicolas> je ne vois pas pourquoi on se priverait d'utiliser les Nicolas> fonctionnalités supplémentaires, qui sont quand même bien Nicolas> pratiques, en particulier pour faire des scripts robustes
Dépend de ce que tu vises et des environnements sur lesquels tu es amené à bosser, /bin/sh tu devrais le trouver partout, même sur une machine administrée par un pervers qui jouit à l'idée d'imposer à ses utilisateurs un shell antédiluvien ;)
Autrement sur le principe, si tu as la maitrise des environnements sur lesquels tu bosses, et que la portabilité n'a qu'une importance secondaire, tu peux utiliser les outils que tu préfères, bien évidemment.
Pour ma part, un soft qui m'impose l'installation d'un shell autre que ceux dont je me sers régulièrement fait normalement un direct poubelle. (hint : sur un bsd, on a (t)csh et sh par défaut)
Eric Masson
-- Le truc c'est qu'avec MacOS l'utilisateur neuneu pouvait aussi etre administrateur neuneu, et que ca, ca sera bien fini. -+ ED in Guide du Macounet Pervers : il voit des neuneus partout -+-
"Nicolas" == Nicolas George <nicolas$george@salle-s.org> writes:
Nicolas> je ne vois pas pourquoi on se priverait d'utiliser les
Nicolas> fonctionnalités supplémentaires, qui sont quand même bien
Nicolas> pratiques, en particulier pour faire des scripts robustes
Dépend de ce que tu vises et des environnements sur lesquels tu es amené
à bosser, /bin/sh tu devrais le trouver partout, même sur une machine
administrée par un pervers qui jouit à l'idée d'imposer à ses
utilisateurs un shell antédiluvien ;)
Autrement sur le principe, si tu as la maitrise des environnements sur
lesquels tu bosses, et que la portabilité n'a qu'une importance
secondaire, tu peux utiliser les outils que tu préfères, bien
évidemment.
Pour ma part, un soft qui m'impose l'installation d'un shell autre
que ceux dont je me sers régulièrement fait normalement un direct
poubelle. (hint : sur un bsd, on a (t)csh et sh par défaut)
Eric Masson
--
Le truc c'est qu'avec MacOS l'utilisateur neuneu pouvait aussi etre
administrateur neuneu, et que ca, ca sera bien fini.
-+ ED in Guide du Macounet Pervers : il voit des neuneus partout -+-
Nicolas> je ne vois pas pourquoi on se priverait d'utiliser les Nicolas> fonctionnalités supplémentaires, qui sont quand même bien Nicolas> pratiques, en particulier pour faire des scripts robustes
Dépend de ce que tu vises et des environnements sur lesquels tu es amené à bosser, /bin/sh tu devrais le trouver partout, même sur une machine administrée par un pervers qui jouit à l'idée d'imposer à ses utilisateurs un shell antédiluvien ;)
Autrement sur le principe, si tu as la maitrise des environnements sur lesquels tu bosses, et que la portabilité n'a qu'une importance secondaire, tu peux utiliser les outils que tu préfères, bien évidemment.
Pour ma part, un soft qui m'impose l'installation d'un shell autre que ceux dont je me sers régulièrement fait normalement un direct poubelle. (hint : sur un bsd, on a (t)csh et sh par défaut)
Eric Masson
-- Le truc c'est qu'avec MacOS l'utilisateur neuneu pouvait aussi etre administrateur neuneu, et que ca, ca sera bien fini. -+ ED in Guide du Macounet Pervers : il voit des neuneus partout -+-
andrea ferraris
Eric Masson wrote:
"andrea" == andrea ferraris writes:
'Lut,
andrea> Why? Pardon, pourquoi? csh est mieux?! Je ne crois pas.
Non, mais sh existe partout et n'est pas forcément un lien symbolique vers /bin/bash.
Je ne disais pas bourne again shell, mais bourne shell.
Bref, il vaut mieux éviter autant que possible un particularité liée à un shell dit évolué pour assurer une portabilité maximale.
Autrement sur le principe, si tu as la maitrise des environnements sur lesquels tu bosses, et que la portabilité n'a qu'une importance secondaire, tu peux utiliser les outils que tu préfères, bien évidemment.
Stéphane parlait de « scripts système », j'avais compris par là des scripts d'administration locaux, qui de toutes façons ne sont par essence pas transposables.
Personnellement, je programme la plupart du temps avant tout pour moi (au sens large, par exemple pour des groupes auxquels je participe), et c'est particulièrement vrai quand il s'agit de scripts shells. Après, si ce que j'écris peut servir à quelqu'un d'autre, tant mieux. Mais s'il n'est pas content parce que j'ai utilisé tel langage de script, c'est le même prix, à savoir gratuit :-Þ
Pour ma part, un soft qui m'impose l'installation d'un shell autre que ceux dont je me sers régulièrement fait normalement un direct poubelle. (hint : sur un bsd, on a (t)csh et sh par défaut)
Et si ce soft demande une bibliothèque un peu inhabituelle ? Ou un compilateur pour un langage peu répandu ? Ou un interpréteur pour un langage peu répandu, par exemple pike ou ruby ?
Personnellement, je vais plutôt prendre en compte la quantité d'efforts que demande l'installation, tout compris, l'intérêt potentiel du logiciel, mettre ça en regard, et décider a posteriori si ça vaut le coup ou pas. Pourquoi se fixer des règles arbitraires ?
Eric Masson wrote in message
<86u0s86teg.fsf@srvbsdnanssv.interne.kisoft-services.com>:
Autrement sur le principe, si tu as la maitrise des environnements sur
lesquels tu bosses, et que la portabilité n'a qu'une importance
secondaire, tu peux utiliser les outils que tu préfères, bien
évidemment.
Stéphane parlait de « scripts système », j'avais compris par là des scripts
d'administration locaux, qui de toutes façons ne sont par essence pas
transposables.
Personnellement, je programme la plupart du temps avant tout pour moi (au
sens large, par exemple pour des groupes auxquels je participe), et c'est
particulièrement vrai quand il s'agit de scripts shells. Après, si ce que
j'écris peut servir à quelqu'un d'autre, tant mieux. Mais s'il n'est pas
content parce que j'ai utilisé tel langage de script, c'est le même prix, à
savoir gratuit :-Þ
Pour ma part, un soft qui m'impose l'installation d'un shell autre
que ceux dont je me sers régulièrement fait normalement un direct
poubelle. (hint : sur un bsd, on a (t)csh et sh par défaut)
Et si ce soft demande une bibliothèque un peu inhabituelle ? Ou un
compilateur pour un langage peu répandu ? Ou un interpréteur pour un langage
peu répandu, par exemple pike ou ruby ?
Personnellement, je vais plutôt prendre en compte la quantité d'efforts que
demande l'installation, tout compris, l'intérêt potentiel du logiciel,
mettre ça en regard, et décider a posteriori si ça vaut le coup ou pas.
Pourquoi se fixer des règles arbitraires ?
Autrement sur le principe, si tu as la maitrise des environnements sur lesquels tu bosses, et que la portabilité n'a qu'une importance secondaire, tu peux utiliser les outils que tu préfères, bien évidemment.
Stéphane parlait de « scripts système », j'avais compris par là des scripts d'administration locaux, qui de toutes façons ne sont par essence pas transposables.
Personnellement, je programme la plupart du temps avant tout pour moi (au sens large, par exemple pour des groupes auxquels je participe), et c'est particulièrement vrai quand il s'agit de scripts shells. Après, si ce que j'écris peut servir à quelqu'un d'autre, tant mieux. Mais s'il n'est pas content parce que j'ai utilisé tel langage de script, c'est le même prix, à savoir gratuit :-Þ
Pour ma part, un soft qui m'impose l'installation d'un shell autre que ceux dont je me sers régulièrement fait normalement un direct poubelle. (hint : sur un bsd, on a (t)csh et sh par défaut)
Et si ce soft demande une bibliothèque un peu inhabituelle ? Ou un compilateur pour un langage peu répandu ? Ou un interpréteur pour un langage peu répandu, par exemple pike ou ruby ?
Personnellement, je vais plutôt prendre en compte la quantité d'efforts que demande l'installation, tout compris, l'intérêt potentiel du logiciel, mettre ça en regard, et décider a posteriori si ça vaut le coup ou pas. Pourquoi se fixer des règles arbitraires ?
Stephane Dupille
Le problème est que bash et zsh ne sont pas forcément dans /bin Par exemple sur freebsd ils sont dans /usr/local/bin
Pas chez moi : [gimli] ~> uname FreeBSD [gimli] ~> which zsh /bin/zsh
Et c'était bien entendu prémedité : [gimli] ~> file /bin/zsh /bin/zsh: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (FreeBSD), for FreeBSD 4.9, statically linked, stripped
-- La maintenance, c'est plus que du « bricolage », c'est un mode de vie, une attitude... -+- GA In : Guide du Neueu Usenet - Neuneu se maintient en forme -+-
Le problème est que bash et zsh ne sont pas forcément dans /bin
Par exemple sur freebsd ils sont dans /usr/local/bin
Pas chez moi :
[gimli] ~> uname
FreeBSD
[gimli] ~> which zsh
/bin/zsh
Et c'était bien entendu prémedité :
[gimli] ~> file /bin/zsh
/bin/zsh: ELF 64-bit LSB executable, Alpha (unofficial), version 1
(FreeBSD), for FreeBSD 4.9, statically linked, stripped
--
La maintenance, c'est plus que du « bricolage », c'est un mode de vie,
une attitude...
-+- GA In : Guide du Neueu Usenet - Neuneu se maintient en forme -+-
Le problème est que bash et zsh ne sont pas forcément dans /bin Par exemple sur freebsd ils sont dans /usr/local/bin
Pas chez moi : [gimli] ~> uname FreeBSD [gimli] ~> which zsh /bin/zsh
Et c'était bien entendu prémedité : [gimli] ~> file /bin/zsh /bin/zsh: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (FreeBSD), for FreeBSD 4.9, statically linked, stripped
-- La maintenance, c'est plus que du « bricolage », c'est un mode de vie, une attitude... -+- GA In : Guide du Neueu Usenet - Neuneu se maintient en forme -+-
Eric Masson
"Nicolas" == Nicolas George <nicolas$ writes:
Nicolas> Et si ce soft demande une bibliothèque un peu inhabituelle ? Nicolas> Ou un compilateur pour un langage peu répandu ? Ou un Nicolas> interpréteur pour un langage peu répandu, par exemple pike ou Nicolas> ruby ?
Dépend de la fonctionnalité qu'il apporte.
Nicolas> Personnellement, je vais plutôt prendre en compte la quantité Nicolas> d'efforts que demande l'installation, tout compris, l'intérêt Nicolas> potentiel du logiciel, mettre ça en regard, et décider a Nicolas> posteriori si ça vaut le coup ou pas. Pourquoi se fixer des Nicolas> règles arbitraires ?
Certains outils valent quelques entorses en raison de leur valeur ajoutée (cvsup, portupgrade, reportlab), d'autres beaucoup moins voire pas du tout. La dépendance à un shell a tout de même une propension irraisonnée à classer le soft dans la deuxième catégorie ;)
Eric Masson
-- J'aurai aimé savoir si en Norvège il y avait effectivement des panneaux de signalisation sur les routes indiquant la présence éventuelle de fantômes? Merci. -+- DM in :GNU- Il y a quelque chose de pouri au royaume du neuneu -+-
"Nicolas" == Nicolas George <nicolas$george@salle-s.org> writes:
Nicolas> Et si ce soft demande une bibliothèque un peu inhabituelle ?
Nicolas> Ou un compilateur pour un langage peu répandu ? Ou un
Nicolas> interpréteur pour un langage peu répandu, par exemple pike ou
Nicolas> ruby ?
Dépend de la fonctionnalité qu'il apporte.
Nicolas> Personnellement, je vais plutôt prendre en compte la quantité
Nicolas> d'efforts que demande l'installation, tout compris, l'intérêt
Nicolas> potentiel du logiciel, mettre ça en regard, et décider a
Nicolas> posteriori si ça vaut le coup ou pas. Pourquoi se fixer des
Nicolas> règles arbitraires ?
Certains outils valent quelques entorses en raison de leur valeur
ajoutée (cvsup, portupgrade, reportlab), d'autres beaucoup moins voire
pas du tout. La dépendance à un shell a tout de même une propension
irraisonnée à classer le soft dans la deuxième catégorie ;)
Eric Masson
--
J'aurai aimé savoir si en Norvège il y avait effectivement des panneaux
de signalisation sur les routes indiquant la présence éventuelle de
fantômes? Merci.
-+- DM in :GNU- Il y a quelque chose de pouri au royaume du neuneu -+-
Nicolas> Et si ce soft demande une bibliothèque un peu inhabituelle ? Nicolas> Ou un compilateur pour un langage peu répandu ? Ou un Nicolas> interpréteur pour un langage peu répandu, par exemple pike ou Nicolas> ruby ?
Dépend de la fonctionnalité qu'il apporte.
Nicolas> Personnellement, je vais plutôt prendre en compte la quantité Nicolas> d'efforts que demande l'installation, tout compris, l'intérêt Nicolas> potentiel du logiciel, mettre ça en regard, et décider a Nicolas> posteriori si ça vaut le coup ou pas. Pourquoi se fixer des Nicolas> règles arbitraires ?
Certains outils valent quelques entorses en raison de leur valeur ajoutée (cvsup, portupgrade, reportlab), d'autres beaucoup moins voire pas du tout. La dépendance à un shell a tout de même une propension irraisonnée à classer le soft dans la deuxième catégorie ;)
Eric Masson
-- J'aurai aimé savoir si en Norvège il y avait effectivement des panneaux de signalisation sur les routes indiquant la présence éventuelle de fantômes? Merci. -+- DM in :GNU- Il y a quelque chose de pouri au royaume du neuneu -+-
andrea ferraris
Stephane Chazelas wrote:
Ca fait des annees que /bin/sh n'est plus un Bourne shell sur la plupart des Unix (exceptions: Solaris, Tru64).
J'ai fait quelque recherche et cela est ce que dit la manpage de sh sur HP-UX, qui a un shell POSIX (je crois) ou Open Group compliant (je ne sais pas comme on le dit en francais et j'ai des problemes a trouver le mot aussi en italien quand je le doit employer bien que le juste mot existe). Mais ailleurs j'ai l'impression que n'est pas necessairement la shell POSIX. Par exemple sous AIX je crois que sh soit une ksh. Enfin Solaris comme diffusion est au moins la moitie du monde UNIX (il a une shell presque POSIX sous /usr/xpg4/bin peut etre). Donc, que est-ce que c'est "la plupart des Unix"? Je ne crois pas que sous la plupart des Unix (au moins comme diffusion) /bin/sh ou` /usr/bin/sh soit une shell Open Group (ou` POSIX) compliant au moins de ne pas l'executer avec quelque option pour la faire etre comme ca. Par exemple sous Linux si je donne /bin/bash --posix, elle agira comme une shell posix (le defait est qu'elle acceptera aussi l'argot bash). S'il te plait, corrige mon francais (pas les accents et le cedilles, car je suis en train d'ecrire avec un english keyboard).
Andrea
Stephane Chazelas wrote:
Ca fait des annees que /bin/sh n'est plus un Bourne shell sur la
plupart des Unix (exceptions: Solaris, Tru64).
J'ai fait quelque recherche et cela est ce que dit la manpage
de sh sur HP-UX, qui a un shell POSIX (je crois) ou Open Group
compliant (je ne sais pas comme on le dit en francais et j'ai des
problemes a trouver le mot aussi en italien quand je le doit employer
bien que le juste mot existe). Mais ailleurs j'ai l'impression que n'est
pas necessairement la shell POSIX. Par exemple sous AIX je crois
que sh soit une ksh. Enfin Solaris comme diffusion est au moins la
moitie du monde UNIX (il a une shell presque POSIX sous /usr/xpg4/bin
peut etre). Donc, que est-ce que c'est "la plupart des Unix"?
Je ne crois pas que sous la plupart des Unix (au moins comme diffusion)
/bin/sh ou` /usr/bin/sh soit une shell Open Group (ou` POSIX) compliant
au moins de ne pas l'executer avec quelque option pour la faire etre
comme ca. Par exemple sous Linux si je donne /bin/bash --posix, elle
agira comme une shell posix (le defait est qu'elle acceptera aussi
l'argot bash). S'il te plait, corrige mon francais (pas les accents
et le cedilles, car je suis en train d'ecrire avec un english keyboard).
Ca fait des annees que /bin/sh n'est plus un Bourne shell sur la plupart des Unix (exceptions: Solaris, Tru64).
J'ai fait quelque recherche et cela est ce que dit la manpage de sh sur HP-UX, qui a un shell POSIX (je crois) ou Open Group compliant (je ne sais pas comme on le dit en francais et j'ai des problemes a trouver le mot aussi en italien quand je le doit employer bien que le juste mot existe). Mais ailleurs j'ai l'impression que n'est pas necessairement la shell POSIX. Par exemple sous AIX je crois que sh soit une ksh. Enfin Solaris comme diffusion est au moins la moitie du monde UNIX (il a une shell presque POSIX sous /usr/xpg4/bin peut etre). Donc, que est-ce que c'est "la plupart des Unix"? Je ne crois pas que sous la plupart des Unix (au moins comme diffusion) /bin/sh ou` /usr/bin/sh soit une shell Open Group (ou` POSIX) compliant au moins de ne pas l'executer avec quelque option pour la faire etre comme ca. Par exemple sous Linux si je donne /bin/bash --posix, elle agira comme une shell posix (le defait est qu'elle acceptera aussi l'argot bash). S'il te plait, corrige mon francais (pas les accents et le cedilles, car je suis en train d'ecrire avec un english keyboard).
Andrea
Stephane Chazelas
2004-11-04, 13:50(+00), andrea ferraris:
Stephane Chazelas wrote:
Ca fait des annees que /bin/sh n'est plus un Bourne shell sur la plupart des Unix (exceptions: Solaris, Tru64).
J'ai fait quelque recherche et cela est ce que dit la manpage de sh sur HP-UX, qui a un shell POSIX (je crois) ou Open Group compliant (je ne sais pas comme on le dit en francais et j'ai des problemes a trouver le mot aussi en italien quand je le doit employer bien que le juste mot existe). Mais ailleurs j'ai l'impression que n'est pas necessairement la shell POSIX. Par exemple sous AIX je crois que sh soit une ksh. Enfin Solaris comme diffusion est au moins la moitie du monde UNIX (il a une shell presque POSIX sous /usr/xpg4/bin peut etre). Donc, que est-ce que c'est "la plupart des Unix"? Je ne crois pas que sous la plupart des Unix (au moins comme diffusion) /bin/sh ou` /usr/bin/sh soit une shell Open Group (ou` POSIX) compliant au moins de ne pas l'executer avec quelque option pour la faire etre comme ca. Par exemple sous Linux si je donne /bin/bash --posix, elle agira comme une shell posix (le defait est qu'elle acceptera aussi l'argot bash). S'il te plait, corrige mon francais (pas les accents et le cedilles, car je suis en train d'ecrire avec un english keyboard). [...]
Il n'y a pas de shell POSIX, il y a des shells qui essaient d'etre conformant a la norme POSIX. Les UNIX qui se proclament conformant a POSIX (maintenant on parle plutot de Single Unix Specificatio aka SUS, aka SUSv3 pour la derniere version qui tente d'uniformiser un peu toutes ces normes) doivent avoir un "sh" (generalement dans /bin) conformant.
bash, ksh, dash, zsh essaient d'etre conformants a cette norme, du moins ont un mode (quand ils sont appelés avec un argv[0] egal a "sh" par exemple) qui essait d'etre conformant.
Sous HPUX, /bin/sh est un derivé d'une version de ksh. Sous AIX, je pense en effet que c'est une version de ksh. Sous (la plupart des )Linux, MacOSX, Hurd, ca doit etre un bash, sous *BSD, Cygwin, c'est un derivé de ash. Sous Solaris, il faut aller le trouver dans /usr/xpg4/bin/sh.
La single Unix Specification peut etre trouvee la: http://www.opengroup.org/onlinepubs/009695399/frontmatter/preface.html http://www.opengroup.org/onlinepubs/009695399/toc.htm
-- Stephane
2004-11-04, 13:50(+00), andrea ferraris:
Stephane Chazelas wrote:
Ca fait des annees que /bin/sh n'est plus un Bourne shell sur la
plupart des Unix (exceptions: Solaris, Tru64).
J'ai fait quelque recherche et cela est ce que dit la manpage
de sh sur HP-UX, qui a un shell POSIX (je crois) ou Open Group
compliant (je ne sais pas comme on le dit en francais et j'ai des
problemes a trouver le mot aussi en italien quand je le doit employer
bien que le juste mot existe). Mais ailleurs j'ai l'impression que n'est
pas necessairement la shell POSIX. Par exemple sous AIX je crois
que sh soit une ksh. Enfin Solaris comme diffusion est au moins la
moitie du monde UNIX (il a une shell presque POSIX sous /usr/xpg4/bin
peut etre). Donc, que est-ce que c'est "la plupart des Unix"?
Je ne crois pas que sous la plupart des Unix (au moins comme diffusion)
/bin/sh ou` /usr/bin/sh soit une shell Open Group (ou` POSIX) compliant
au moins de ne pas l'executer avec quelque option pour la faire etre
comme ca. Par exemple sous Linux si je donne /bin/bash --posix, elle
agira comme une shell posix (le defait est qu'elle acceptera aussi
l'argot bash). S'il te plait, corrige mon francais (pas les accents
et le cedilles, car je suis en train d'ecrire avec un english keyboard).
[...]
Il n'y a pas de shell POSIX, il y a des shells qui essaient
d'etre conformant a la norme POSIX. Les UNIX qui se proclament
conformant a POSIX (maintenant on parle plutot de Single Unix
Specificatio aka SUS, aka SUSv3 pour la derniere version qui
tente d'uniformiser un peu toutes ces normes) doivent avoir un
"sh" (generalement dans /bin) conformant.
bash, ksh, dash, zsh essaient d'etre conformants a cette norme,
du moins ont un mode (quand ils sont appelés avec un argv[0] egal
a "sh" par exemple) qui essait d'etre conformant.
Sous HPUX, /bin/sh est un derivé d'une version de ksh. Sous AIX,
je pense en effet que c'est une version de ksh. Sous (la plupart
des )Linux, MacOSX, Hurd, ca doit etre un bash, sous *BSD,
Cygwin, c'est un derivé de ash. Sous Solaris, il faut aller le
trouver dans /usr/xpg4/bin/sh.
La single Unix Specification peut etre trouvee la:
http://www.opengroup.org/onlinepubs/009695399/frontmatter/preface.html
http://www.opengroup.org/onlinepubs/009695399/toc.htm
Ca fait des annees que /bin/sh n'est plus un Bourne shell sur la plupart des Unix (exceptions: Solaris, Tru64).
J'ai fait quelque recherche et cela est ce que dit la manpage de sh sur HP-UX, qui a un shell POSIX (je crois) ou Open Group compliant (je ne sais pas comme on le dit en francais et j'ai des problemes a trouver le mot aussi en italien quand je le doit employer bien que le juste mot existe). Mais ailleurs j'ai l'impression que n'est pas necessairement la shell POSIX. Par exemple sous AIX je crois que sh soit une ksh. Enfin Solaris comme diffusion est au moins la moitie du monde UNIX (il a une shell presque POSIX sous /usr/xpg4/bin peut etre). Donc, que est-ce que c'est "la plupart des Unix"? Je ne crois pas que sous la plupart des Unix (au moins comme diffusion) /bin/sh ou` /usr/bin/sh soit une shell Open Group (ou` POSIX) compliant au moins de ne pas l'executer avec quelque option pour la faire etre comme ca. Par exemple sous Linux si je donne /bin/bash --posix, elle agira comme une shell posix (le defait est qu'elle acceptera aussi l'argot bash). S'il te plait, corrige mon francais (pas les accents et le cedilles, car je suis en train d'ecrire avec un english keyboard). [...]
Il n'y a pas de shell POSIX, il y a des shells qui essaient d'etre conformant a la norme POSIX. Les UNIX qui se proclament conformant a POSIX (maintenant on parle plutot de Single Unix Specificatio aka SUS, aka SUSv3 pour la derniere version qui tente d'uniformiser un peu toutes ces normes) doivent avoir un "sh" (generalement dans /bin) conformant.
bash, ksh, dash, zsh essaient d'etre conformants a cette norme, du moins ont un mode (quand ils sont appelés avec un argv[0] egal a "sh" par exemple) qui essait d'etre conformant.
Sous HPUX, /bin/sh est un derivé d'une version de ksh. Sous AIX, je pense en effet que c'est une version de ksh. Sous (la plupart des )Linux, MacOSX, Hurd, ca doit etre un bash, sous *BSD, Cygwin, c'est un derivé de ash. Sous Solaris, il faut aller le trouver dans /usr/xpg4/bin/sh.
La single Unix Specification peut etre trouvee la: http://www.opengroup.org/onlinepubs/009695399/frontmatter/preface.html http://www.opengroup.org/onlinepubs/009695399/toc.htm
-- Stephane
Pascal Bourguignon
andrea ferraris writes:
S'il te plait, corrige mon francais (pas les accents et le cedilles, car je suis en train d'ecrire avec un english keyboard).
Et alors ? Moi aussi j'utilise un clavier qwerty et pourtant je peux saisir les accents. Bon, avec emacs, ou avec un Mac c'est plus facile qu'avec MS-Windows, mais quand je devais travailler avec MS-Windows je tapais les accents en saisiant le code ASCII en décimal sur le pavé numérique avec AltGr. Après deux ou trois docs , ça allait aussi vite et aussi naturellement qu'avec un clavier AZERTY (mieux même).
andrea ferraris <andrea_ferraris@libero.it> writes:
S'il te plait, corrige mon francais (pas les accents
et le cedilles, car je suis en train d'ecrire avec un english keyboard).
Et alors ? Moi aussi j'utilise un clavier qwerty et pourtant je peux
saisir les accents. Bon, avec emacs, ou avec un Mac c'est plus facile
qu'avec MS-Windows, mais quand je devais travailler avec MS-Windows je
tapais les accents en saisiant le code ASCII en décimal sur le pavé
numérique avec AltGr. Après deux ou trois docs , ça allait aussi vite
et aussi naturellement qu'avec un clavier AZERTY (mieux même).
S'il te plait, corrige mon francais (pas les accents et le cedilles, car je suis en train d'ecrire avec un english keyboard).
Et alors ? Moi aussi j'utilise un clavier qwerty et pourtant je peux saisir les accents. Bon, avec emacs, ou avec un Mac c'est plus facile qu'avec MS-Windows, mais quand je devais travailler avec MS-Windows je tapais les accents en saisiant le code ASCII en décimal sur le pavé numérique avec AltGr. Après deux ou trois docs , ça allait aussi vite et aussi naturellement qu'avec un clavier AZERTY (mieux même).
