Ma question va peut être vous paraître un peut conne... mais pourquoi
dans le shell de mac os X (et dans tout les unix visiblement), il y a
tant de shell différents pour le terminal ?
Attention, ce n'est pas une critique, mais une simple question, très
conne je l'admet....
--
<http://www.clampin.com/>, l'actualité Mac vue par Clampin
Le seul à déconseiller c'est (t)csh. Mais j'en connais plein qui l'utilisent parce que c'est celui qu'ils utilisent depuis de nombreuses années (et que c'est celui livré par défaut sur les BSD).
J'ai été vacciné grâce à une lecture précoce du fameux article "Csh Programming Considered Harmful".
Ensuite, le sh de MacOS X ne correspond pas au Bourne Shell de base que l'on peut trouver sur d'autre Unix lorsque l'on appelle /bin/sh.
Aucun Unix n'a de Bourn Shell de base. C'est neuf fois sur dix un alias vers un autre shell qui tente de se comporter comme un Bourne Shell classique. En fait, *le* Bourne Shell n'existe plus, c'est le dahu des unices. :)
Sur Linux (et Mac OS X certainement), c'est un alias de bash, à ce dernier de se comporter comme un Bourne Shell.
Je me fais vieux. Je m'aperçois que le sh correspond désormais au Shell Posix et que le bourne shell est désormais considéré comme obsolète (Sur HP-UX, il est planqué dans un répertoire .../old/... ). Quand le bash est appelé via le sh, il se comporte comme le Shell Posix. Voilà une bonne chose.
Stephane Dupille <sdupille+news@teaser.fr> wrote:
Le seul à déconseiller c'est (t)csh. Mais j'en connais plein qui
l'utilisent parce que c'est celui qu'ils utilisent depuis de
nombreuses années (et que c'est celui livré par défaut sur les BSD).
J'ai été vacciné grâce à une lecture précoce du fameux article "Csh
Programming Considered Harmful".
Ensuite, le sh de MacOS X ne correspond pas au Bourne Shell de base que
l'on peut trouver sur d'autre Unix lorsque l'on appelle /bin/sh.
Aucun Unix n'a de Bourn Shell de base. C'est neuf fois sur dix un
alias vers un autre shell qui tente de se comporter comme un Bourne
Shell classique. En fait, *le* Bourne Shell n'existe plus, c'est le
dahu des unices. :)
Sur Linux (et Mac OS X certainement), c'est un alias de bash, à ce
dernier de se comporter comme un Bourne Shell.
Je me fais vieux. Je m'aperçois que le sh correspond désormais au Shell
Posix et que le bourne shell est désormais considéré comme obsolète (Sur
HP-UX, il est planqué dans un répertoire .../old/... ).
Quand le bash est appelé via le sh, il se comporte comme le Shell Posix.
Voilà une bonne chose.
Le seul à déconseiller c'est (t)csh. Mais j'en connais plein qui l'utilisent parce que c'est celui qu'ils utilisent depuis de nombreuses années (et que c'est celui livré par défaut sur les BSD).
J'ai été vacciné grâce à une lecture précoce du fameux article "Csh Programming Considered Harmful".
Ensuite, le sh de MacOS X ne correspond pas au Bourne Shell de base que l'on peut trouver sur d'autre Unix lorsque l'on appelle /bin/sh.
Aucun Unix n'a de Bourn Shell de base. C'est neuf fois sur dix un alias vers un autre shell qui tente de se comporter comme un Bourne Shell classique. En fait, *le* Bourne Shell n'existe plus, c'est le dahu des unices. :)
Sur Linux (et Mac OS X certainement), c'est un alias de bash, à ce dernier de se comporter comme un Bourne Shell.
Je me fais vieux. Je m'aperçois que le sh correspond désormais au Shell Posix et que le bourne shell est désormais considéré comme obsolète (Sur HP-UX, il est planqué dans un répertoire .../old/... ). Quand le bash est appelé via le sh, il se comporte comme le Shell Posix. Voilà une bonne chose.
laurent.pertois
Stephane Dupille <sdupille+ wrote:
En théorie oui, mais il est particulièrement incohérent. Rhooohhhhh :-D
Y'a pas que moi que le dit, hein. Et puis j'ai appris unix avec tcsh, puis bash pendant ma période Linux, puis maintenant zsh (je suis dans ma période BSD et Mac OS).
Ok, tout le monde dit le plus grand bien de zsh, il faudra que je me penche un jour sur les fichiers de config pour retrouver les quelques trucs que j'ai mis dans mon tcsh.
Ben, moi, j'ai du mal pourtant, mais il faut dire que je me plonge dans le truc une fois tous les 6 mois, ça n'aide pas ;-)
C'est clair qu'il faut en avoir l'usage. Si c'est pour juste taper les tips qui sont publiés dans les magazine, autant garder celui par défaut (mais je recommande quand même au moins de passer à bash).
Non, ça va un peu plus loin quand même, mais j'avoue qu'à part les quelques petits trucs (plus esthétiques qu'autre chose, d'ailleurs, à l'exception des modification de PATH) j'utilise aussi très souvent le bash tel que livré dans Mac OS X quand j'interviens sur des machines autres que la mienne et ce sans être géné (à part le rappel du chemin qui n'est pas limité mais on m'a montré comment modifier).
Clair que si ça n'est même pas respecté, ça n'a pas d'intérêt.
C'est surtout une bêtise sans nom : le C est un langage de prog système, et un shell, c'est une interface au système. Ça n'a rien à voir. C'est comme les shell Lisp, c'est rigolo, ça peut être pratique pour faire des scripts, mais à utiliser c'est la plaie.
Ok.
Encore merci.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Stephane Dupille <sdupille+news@teaser.fr> wrote:
En théorie oui, mais il est particulièrement incohérent.
Rhooohhhhh :-D
Y'a pas que moi que le dit, hein. Et puis j'ai appris unix avec
tcsh, puis bash pendant ma période Linux, puis maintenant zsh (je suis
dans ma période BSD et Mac OS).
Ok, tout le monde dit le plus grand bien de zsh, il faudra que je me
penche un jour sur les fichiers de config pour retrouver les quelques
trucs que j'ai mis dans mon tcsh.
Ben, moi, j'ai du mal pourtant, mais il faut dire que je me plonge dans
le truc une fois tous les 6 mois, ça n'aide pas ;-)
C'est clair qu'il faut en avoir l'usage. Si c'est pour juste taper
les tips qui sont publiés dans les magazine, autant garder celui par
défaut (mais je recommande quand même au moins de passer à bash).
Non, ça va un peu plus loin quand même, mais j'avoue qu'à part les
quelques petits trucs (plus esthétiques qu'autre chose, d'ailleurs, à
l'exception des modification de PATH) j'utilise aussi très souvent le
bash tel que livré dans Mac OS X quand j'interviens sur des machines
autres que la mienne et ce sans être géné (à part le rappel du chemin
qui n'est pas limité mais on m'a montré comment modifier).
Clair que si ça n'est même pas respecté, ça n'a pas d'intérêt.
C'est surtout une bêtise sans nom : le C est un langage de prog
système, et un shell, c'est une interface au système. Ça n'a rien à
voir. C'est comme les shell Lisp, c'est rigolo, ça peut être pratique
pour faire des scripts, mais à utiliser c'est la plaie.
Ok.
Encore merci.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
En théorie oui, mais il est particulièrement incohérent. Rhooohhhhh :-D
Y'a pas que moi que le dit, hein. Et puis j'ai appris unix avec tcsh, puis bash pendant ma période Linux, puis maintenant zsh (je suis dans ma période BSD et Mac OS).
Ok, tout le monde dit le plus grand bien de zsh, il faudra que je me penche un jour sur les fichiers de config pour retrouver les quelques trucs que j'ai mis dans mon tcsh.
Ben, moi, j'ai du mal pourtant, mais il faut dire que je me plonge dans le truc une fois tous les 6 mois, ça n'aide pas ;-)
C'est clair qu'il faut en avoir l'usage. Si c'est pour juste taper les tips qui sont publiés dans les magazine, autant garder celui par défaut (mais je recommande quand même au moins de passer à bash).
Non, ça va un peu plus loin quand même, mais j'avoue qu'à part les quelques petits trucs (plus esthétiques qu'autre chose, d'ailleurs, à l'exception des modification de PATH) j'utilise aussi très souvent le bash tel que livré dans Mac OS X quand j'interviens sur des machines autres que la mienne et ce sans être géné (à part le rappel du chemin qui n'est pas limité mais on m'a montré comment modifier).
Clair que si ça n'est même pas respecté, ça n'a pas d'intérêt.
C'est surtout une bêtise sans nom : le C est un langage de prog système, et un shell, c'est une interface au système. Ça n'a rien à voir. C'est comme les shell Lisp, c'est rigolo, ça peut être pratique pour faire des scripts, mais à utiliser c'est la plaie.
Ok.
Encore merci.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
blanc
Yvon Thoraval wrote:
quel est le mieux adapté pour les accents en UTF-8 ? j'utilise zsh mais les majuscules accentuées ne passent pas, les minuscules si...
N'est-ce pas au niveau de la config du terminal qu'il faut régler le pb des accents ? Perso j'utilise zsh, et mes accents ont l'air de bien passer, même en majuscule... Pour la config Terminal (Terminal --> Réglages de la fenêtre --> affichage -->codage jeu caractères) j'ai "Occidental iso-latin 1".
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
quel est le mieux adapté pour les accents en UTF-8 ?
j'utilise zsh mais les majuscules accentuées ne passent pas, les
minuscules si...
N'est-ce pas au niveau de la config du terminal qu'il faut régler le pb
des accents ?
Perso j'utilise zsh, et mes accents ont l'air de bien passer, même en
majuscule...
Pour la config Terminal
(Terminal --> Réglages de la fenêtre --> affichage -->codage jeu
caractères)
j'ai "Occidental iso-latin 1".
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
quel est le mieux adapté pour les accents en UTF-8 ? j'utilise zsh mais les majuscules accentuées ne passent pas, les minuscules si...
N'est-ce pas au niveau de la config du terminal qu'il faut régler le pb des accents ? Perso j'utilise zsh, et mes accents ont l'air de bien passer, même en majuscule... Pour la config Terminal (Terminal --> Réglages de la fenêtre --> affichage -->codage jeu caractères) j'ai "Occidental iso-latin 1".
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
blanc
Stephane Dupille <sdupille+ wrote:
Le seul à déconseiller c'est (t)csh. Mais j'en connais plein qui l'utilisent parce que c'est celui qu'ils utilisent depuis de nombreuses années (et que c'est celui livré par défaut sur les BSD).
Non, non tcsh est un shell super, même s'il a qques incohérences au niveau de la programmation. Une fois qu'on y est habitué, il n'y a pas de problèmes. Je m'en suis servi pendant plus de 10 ans. Le seul reproche qu'on pourrait lui faire est que beaucoup de scripts existants sont écrits en sh ou ksh, et que si on utilise (t)csh on est obligé d'apprendre en fait les deux types de shells. C'est pour cette raison que depuis cette année je suis passé à zsh, qui a à la fois la syntaxe de la famille Bourne/Korn-shell (donc pas de problèmes pour ceux qui ont l'habitude de programmer dans ces shells) et les avantages de la famille C-shell (des alias et un historique qui fonctionnent bien, etc...). Il a d'ailleurs été écrits dans ce but.
J'ajouterai qu'il a une bonne compatibilité posix, et que si on veut on peut le faire se comporter comme sh (posix) ou comme ksh. Il suffit pour cela de mettre les bonnes options, ou simplement de créer un lien de nom sh ou ksh vers l'exécutable zsh.
Ceci étant, je le répète, tcsh est un shell super.
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Stephane Dupille <sdupille+news@teaser.fr> wrote:
Le seul à déconseiller c'est (t)csh. Mais j'en connais plein qui
l'utilisent parce que c'est celui qu'ils utilisent depuis de
nombreuses années (et que c'est celui livré par défaut sur les BSD).
Non, non tcsh est un shell super, même s'il a qques incohérences au
niveau de la programmation. Une fois qu'on y est habitué, il n'y a pas
de problèmes. Je m'en suis servi pendant plus de 10 ans. Le seul
reproche qu'on pourrait lui faire est que beaucoup de scripts existants
sont écrits en sh ou ksh, et que si on utilise (t)csh on est obligé
d'apprendre en fait les deux types de shells.
C'est pour cette raison que depuis cette année je suis passé à zsh, qui
a à la fois la syntaxe de la famille Bourne/Korn-shell (donc pas de
problèmes pour ceux qui ont l'habitude de programmer dans ces shells) et
les avantages de la famille C-shell (des alias et un historique qui
fonctionnent bien, etc...). Il a d'ailleurs été écrits dans ce but.
J'ajouterai qu'il a une bonne compatibilité posix, et que si on veut on
peut le faire se comporter comme sh (posix) ou comme ksh. Il suffit pour
cela de mettre les bonnes options, ou simplement de créer un lien de nom
sh ou ksh vers l'exécutable zsh.
Ceci étant, je le répète, tcsh est un shell super.
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
Le seul à déconseiller c'est (t)csh. Mais j'en connais plein qui l'utilisent parce que c'est celui qu'ils utilisent depuis de nombreuses années (et que c'est celui livré par défaut sur les BSD).
Non, non tcsh est un shell super, même s'il a qques incohérences au niveau de la programmation. Une fois qu'on y est habitué, il n'y a pas de problèmes. Je m'en suis servi pendant plus de 10 ans. Le seul reproche qu'on pourrait lui faire est que beaucoup de scripts existants sont écrits en sh ou ksh, et que si on utilise (t)csh on est obligé d'apprendre en fait les deux types de shells. C'est pour cette raison que depuis cette année je suis passé à zsh, qui a à la fois la syntaxe de la famille Bourne/Korn-shell (donc pas de problèmes pour ceux qui ont l'habitude de programmer dans ces shells) et les avantages de la famille C-shell (des alias et un historique qui fonctionnent bien, etc...). Il a d'ailleurs été écrits dans ce but.
J'ajouterai qu'il a une bonne compatibilité posix, et que si on veut on peut le faire se comporter comme sh (posix) ou comme ksh. Il suffit pour cela de mettre les bonnes options, ou simplement de créer un lien de nom sh ou ksh vers l'exécutable zsh.
Ceci étant, je le répète, tcsh est un shell super.
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Stephane Dupille
Le seul à déconseiller c'est (t)csh. Mais j'en connais plein qui l'utilisent parce que c'est celui qu'ils utilisent depuis de nombreuses années (et que c'est celui livré par défaut sur les BSD). Non, non tcsh est un shell super,
<snip>
Ceci étant, je le répète, tcsh est un shell super.
En tout cas, vous répondez parfaitement à la question qui est encore dans le sujet : s'il y a plusieurs shells différents, c'est que chacun a ses propres goûts.
-- Dis tu nous lâches un peu ? C'est un sujet assez important pour qu'on en parle, peu importe le groupe. C'est à cause de gens comme toi si c'est la merde sur le net. Tes leçons de nétiquéquette, tu peux te les... OK? -+- Ghost in : <http://www.le-gnu.net> - Terrorisme neuneulectuel -+-
Le seul à déconseiller c'est (t)csh. Mais j'en connais plein qui
l'utilisent parce que c'est celui qu'ils utilisent depuis de
nombreuses années (et que c'est celui livré par défaut sur les BSD).
Non, non tcsh est un shell super,
<snip>
Ceci étant, je le répète, tcsh est un shell super.
En tout cas, vous répondez parfaitement à la question qui est encore
dans le sujet : s'il y a plusieurs shells différents, c'est que chacun
a ses propres goûts.
--
Dis tu nous lâches un peu ? C'est un sujet assez important pour qu'on en
parle, peu importe le groupe. C'est à cause de gens comme toi si c'est la
merde sur le net. Tes leçons de nétiquéquette, tu peux te les... OK?
-+- Ghost in : <http://www.le-gnu.net> - Terrorisme neuneulectuel -+-
Le seul à déconseiller c'est (t)csh. Mais j'en connais plein qui l'utilisent parce que c'est celui qu'ils utilisent depuis de nombreuses années (et que c'est celui livré par défaut sur les BSD). Non, non tcsh est un shell super,
<snip>
Ceci étant, je le répète, tcsh est un shell super.
En tout cas, vous répondez parfaitement à la question qui est encore dans le sujet : s'il y a plusieurs shells différents, c'est que chacun a ses propres goûts.
-- Dis tu nous lâches un peu ? C'est un sujet assez important pour qu'on en parle, peu importe le groupe. C'est à cause de gens comme toi si c'est la merde sur le net. Tes leçons de nétiquéquette, tu peux te les... OK? -+- Ghost in : <http://www.le-gnu.net> - Terrorisme neuneulectuel -+-
Nicolas.Michel
Bruno Jargot wrote:
D'une part, dire que tel shell est mieux qu'un autre sans expliquer pourquoi ne sert pas à grand chose.
On a pas besoins de savoir pourquoi on fait juste. Quand on fait un truc faux, là on a besoins de comprendre :-)
Tout le monde n'a pas les mêmes objectifs et il peut être dommage de se priver de fonctionnalités éventuellement utiles.
Tu veux dire : " Pourquoi se restreindre à sh pour scripter, alors que zsh a tellement de fonctionnalités ?"
C'est une mauvaise question pour un débutant, amha.
S'il est vrais que dans certaines circonstances précises un script zsh sera mieux qu'un script sh, il est vrais que dans toutes les circonstances un script sh c'est bien. Alors quite à donner un conseil, autant donner celui-ci, non ?
Ensuite, le sh de MacOS X ne correspond pas au Bourne Shell de base que l'on peut trouver sur d'autre Unix lorsque l'on appelle /bin/sh.
Oui, c'est vais ça. Mais bon, on fait avec... :)
-- Nicolas Michel
Bruno Jargot <see@reply-to.invalid> wrote:
D'une part, dire que tel shell est mieux qu'un autre sans expliquer
pourquoi ne sert pas à grand chose.
On a pas besoins de savoir pourquoi on fait juste.
Quand on fait un truc faux, là on a besoins de comprendre :-)
Tout le monde n'a pas les mêmes
objectifs et il peut être dommage de se priver de fonctionnalités
éventuellement utiles.
Tu veux dire : " Pourquoi se restreindre à sh pour scripter, alors que
zsh a tellement de fonctionnalités ?"
C'est une mauvaise question pour un débutant, amha.
S'il est vrais que dans certaines circonstances précises un script zsh
sera mieux qu'un script sh, il est vrais que dans toutes les
circonstances un script sh c'est bien.
Alors quite à donner un conseil, autant donner celui-ci, non ?
Ensuite, le sh de MacOS X ne correspond pas au Bourne Shell de base que
l'on peut trouver sur d'autre Unix lorsque l'on appelle /bin/sh.
D'une part, dire que tel shell est mieux qu'un autre sans expliquer pourquoi ne sert pas à grand chose.
On a pas besoins de savoir pourquoi on fait juste. Quand on fait un truc faux, là on a besoins de comprendre :-)
Tout le monde n'a pas les mêmes objectifs et il peut être dommage de se priver de fonctionnalités éventuellement utiles.
Tu veux dire : " Pourquoi se restreindre à sh pour scripter, alors que zsh a tellement de fonctionnalités ?"
C'est une mauvaise question pour un débutant, amha.
S'il est vrais que dans certaines circonstances précises un script zsh sera mieux qu'un script sh, il est vrais que dans toutes les circonstances un script sh c'est bien. Alors quite à donner un conseil, autant donner celui-ci, non ?
Ensuite, le sh de MacOS X ne correspond pas au Bourne Shell de base que l'on peut trouver sur d'autre Unix lorsque l'on appelle /bin/sh.
Oui, c'est vais ça. Mais bon, on fait avec... :)
-- Nicolas Michel
PLM
On a pas besoins de savoir pourquoi on fait juste. Quand on fait un truc faux, là on a besoins de comprendre :-)
Ne faites pas les sots avec vos shell, la vie a trop d'intérêt au total. Désolé !!! PLM
On a pas besoins de savoir pourquoi on fait juste.
Quand on fait un truc faux, là on a besoins de comprendre :-)
Ne faites pas les sots avec vos shell, la vie a trop d'intérêt au total.
Désolé !!!
PLM
On a pas besoins de savoir pourquoi on fait juste. Quand on fait un truc faux, là on a besoins de comprendre :-)
Ne faites pas les sots avec vos shell, la vie a trop d'intérêt au total. Désolé !!! PLM
blanc
Stephane Dupille <sdupille+ wrote:
En tout cas, vous répondez parfaitement à la question qui est encore dans le sujet : s'il y a plusieurs shells différents, c'est que chacun a ses propres goûts.
Et oui ;-))
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Stephane Dupille <sdupille+news@teaser.fr> wrote:
En tout cas, vous répondez parfaitement à la question qui est encore
dans le sujet : s'il y a plusieurs shells différents, c'est que chacun
a ses propres goûts.
Et oui ;-))
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
En tout cas, vous répondez parfaitement à la question qui est encore dans le sujet : s'il y a plusieurs shells différents, c'est que chacun a ses propres goûts.
Et oui ;-))
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Nicolas.Michel
PLM wrote:
On a pas besoins de savoir pourquoi on fait juste. Quand on fait un truc faux, là on a besoins de comprendre :-)
Ne faites pas les sots avec vos shell, la vie a trop d'intérêt au total. Désolé !!! PLM
Que voilà un post enrichissant ! :->
Peut-être ne sais-tu pas utiliser ton lecteur de news, ou alors ton lecteur n'est pas à la hauteur, mais en principes quand une enfilade n'intéresse pas un lecteur, au lieu de se mettre à flamber les contributeurs, il suffit de "killer" l'enfilade.
Ceci dit vu le nombre d'heures que représente l'apprentissage du langage de commande, passer un peu de temps à choisir son intérpréteur n'est pas dénué d'intérêt
-- Nicolas Michel
PLM <plm34@free.fr> wrote:
On a pas besoins de savoir pourquoi on fait juste.
Quand on fait un truc faux, là on a besoins de comprendre :-)
Ne faites pas les sots avec vos shell, la vie a trop d'intérêt au total.
Désolé !!!
PLM
Que voilà un post enrichissant ! :->
Peut-être ne sais-tu pas utiliser ton lecteur de news, ou alors ton
lecteur n'est pas à la hauteur, mais en principes quand une enfilade
n'intéresse pas un lecteur, au lieu de se mettre à flamber les
contributeurs, il suffit de "killer" l'enfilade.
Ceci dit vu le nombre d'heures que représente l'apprentissage du langage
de commande, passer un peu de temps à choisir son intérpréteur n'est pas
dénué d'intérêt
On a pas besoins de savoir pourquoi on fait juste. Quand on fait un truc faux, là on a besoins de comprendre :-)
Ne faites pas les sots avec vos shell, la vie a trop d'intérêt au total. Désolé !!! PLM
Que voilà un post enrichissant ! :->
Peut-être ne sais-tu pas utiliser ton lecteur de news, ou alors ton lecteur n'est pas à la hauteur, mais en principes quand une enfilade n'intéresse pas un lecteur, au lieu de se mettre à flamber les contributeurs, il suffit de "killer" l'enfilade.
Ceci dit vu le nombre d'heures que représente l'apprentissage du langage de commande, passer un peu de temps à choisir son intérpréteur n'est pas dénué d'intérêt
-- Nicolas Michel
Anonyme
FiLH wrote:
"Stephane Dupille" <sdupille+ writes:
Aucun Unix n'a de Bourn Shell de base. C'est neuf fois sur dix un alias vers un autre shell qui tente de se comporter comme un Bourne Shell classique. En fait, *le* Bourne Shell n'existe plus, c'est le dahu des unices. :)
Solaris a un sh.
(Deux en fait, un lié dynamiquement et un statiquement).
Je n'ai plus de solaris sous la main, mais je suis quasiement sur que le sh de solaris est un ksh se comportant comme un sh...
Aucun Unix n'a de Bourn Shell de base. C'est neuf fois sur dix un
alias vers un autre shell qui tente de se comporter comme un Bourne
Shell classique. En fait, *le* Bourne Shell n'existe plus, c'est le
dahu des unices. :)
Solaris a un sh.
(Deux en fait, un lié dynamiquement et un statiquement).
Je n'ai plus de solaris sous la main, mais je suis quasiement sur que le
sh de solaris est un ksh se comportant comme un sh...
Aucun Unix n'a de Bourn Shell de base. C'est neuf fois sur dix un alias vers un autre shell qui tente de se comporter comme un Bourne Shell classique. En fait, *le* Bourne Shell n'existe plus, c'est le dahu des unices. :)
Solaris a un sh.
(Deux en fait, un lié dynamiquement et un statiquement).
Je n'ai plus de solaris sous la main, mais je suis quasiement sur que le sh de solaris est un ksh se comportant comme un sh...
