Pour une utilisation interactive, je ne vois pas l'interet. bash ne doit sa notorieté qu'au fait que ce soit le shell du projet GNU (et donc le shell par defaut sur la plupart des Unix).
Par contre bash est plus respecteux de Posix. Et programmer avec, évite des expressions en écriture seules comme
Pour une utilisation interactive, je ne vois pas l'interet. bash
ne doit sa notorieté qu'au fait que ce soit le shell du projet
GNU (et donc le shell par defaut sur la plupart des Unix).
Par contre bash est plus respecteux de Posix. Et programmer avec,
évite des expressions en écriture seules comme
Pour une utilisation interactive, je ne vois pas l'interet. bash ne doit sa notorieté qu'au fait que ce soit le shell du projet GNU (et donc le shell par defaut sur la plupart des Unix).
Par contre bash est plus respecteux de Posix. Et programmer avec, évite des expressions en écriture seules comme
echo /tmp/foo*(u0^@:t)
(extrait du manuel de zsh)
Stephane Chazelas
2004-09-3, 10:37(+00), Laurent Wacrenier: [...]
Par contre bash est plus respecteux de Posix. Et programmer avec, évite des expressions en écriture seules comme
bash a des extensions aussi (copiees de ksh), moins bien concues que celles de zsh. Pour la programmation, c'est sur que c'est mieux de se cantonner a la syntaxe POSIX, mais le choix du shell importe peu, tous les shells (Bourne-like) recents connaissent la syntaxe POSIX).
echo /tmp/foo*(u0^@:t)
(extrait du manuel de zsh)
Oui, en ecriture seule, tres utile dans une utilisation interactive.
Le nom (tail :t) des fichiers dont le nom commence par foo qui appartiennent aux utilisateurs d'id 0 (u0) qui ne sont pas (^) des liens symboliques (@ comme dans l'output de ls -F).
C'est intuitif a defaut d'etre lisible.
L'equivalent en utilisant find est beaucoup, beaucoup plus long. Du coup, en bash, on a plus vite fait de faire un ls -l /tmp/foo* et de faire un vgrep dessus, ce qui est beaucoup plus fastidieux.
-- Stephane
2004-09-3, 10:37(+00), Laurent Wacrenier:
[...]
Par contre bash est plus respecteux de Posix. Et programmer avec,
évite des expressions en écriture seules comme
bash a des extensions aussi (copiees de ksh), moins bien concues
que celles de zsh. Pour la programmation, c'est sur que c'est
mieux de se cantonner a la syntaxe POSIX, mais le choix du shell
importe peu, tous les shells (Bourne-like) recents connaissent
la syntaxe POSIX).
echo /tmp/foo*(u0^@:t)
(extrait du manuel de zsh)
Oui, en ecriture seule, tres utile dans une utilisation
interactive.
Le nom (tail :t) des fichiers dont le nom commence par foo qui
appartiennent aux utilisateurs d'id 0 (u0) qui ne sont pas (^)
des liens symboliques (@ comme dans l'output de ls -F).
C'est intuitif a defaut d'etre lisible.
L'equivalent en utilisant find est beaucoup, beaucoup plus long.
Du coup, en bash, on a plus vite fait de faire un ls -l
/tmp/foo* et de faire un vgrep dessus, ce qui est beaucoup plus
fastidieux.
Par contre bash est plus respecteux de Posix. Et programmer avec, évite des expressions en écriture seules comme
bash a des extensions aussi (copiees de ksh), moins bien concues que celles de zsh. Pour la programmation, c'est sur que c'est mieux de se cantonner a la syntaxe POSIX, mais le choix du shell importe peu, tous les shells (Bourne-like) recents connaissent la syntaxe POSIX).
echo /tmp/foo*(u0^@:t)
(extrait du manuel de zsh)
Oui, en ecriture seule, tres utile dans une utilisation interactive.
Le nom (tail :t) des fichiers dont le nom commence par foo qui appartiennent aux utilisateurs d'id 0 (u0) qui ne sont pas (^) des liens symboliques (@ comme dans l'output de ls -F).
C'est intuitif a defaut d'etre lisible.
L'equivalent en utilisant find est beaucoup, beaucoup plus long. Du coup, en bash, on a plus vite fait de faire un ls -l /tmp/foo* et de faire un vgrep dessus, ce qui est beaucoup plus fastidieux.
-- Stephane
Thomas
In article (Dans l'article) , Stephane Chazelas wrote (écrivait) :
je passerais peut etre à bash plus tard, puisque c'est ce qu'apple a choisi
Pour une utilisation interactive, je ne vois pas l'interet. bash ne doit sa notorieté qu'au fait que ce soit le shell du projet GNU (et donc le shell par defaut sur la plupart des Unix).
merci pour l'info :-)
-- "In a world without walls and fences, who needs windows and gates ?" "petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article)
<slrncjghu7.10o.stephane.chazelas@spam.is.invalid>,
Stephane Chazelas <cette.adresse@est.invalid> wrote (écrivait) :
je passerais peut etre à bash plus tard, puisque c'est ce qu'apple a
choisi
Pour une utilisation interactive, je ne vois pas l'interet. bash
ne doit sa notorieté qu'au fait que ce soit le shell du projet
GNU (et donc le shell par defaut sur la plupart des Unix).
merci pour l'info :-)
--
"In a world without walls and fences, who needs windows and gates ?"
"petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) , Stephane Chazelas wrote (écrivait) :
je passerais peut etre à bash plus tard, puisque c'est ce qu'apple a choisi
Pour une utilisation interactive, je ne vois pas l'interet. bash ne doit sa notorieté qu'au fait que ce soit le shell du projet GNU (et donc le shell par defaut sur la plupart des Unix).
merci pour l'info :-)
-- "In a world without walls and fences, who needs windows and gates ?" "petit Free qui devient grand, gêne les requins blancs"
Stephane Chazelas
2004-09-03, 10:30(+00), Stephane Chazelas: [...]
Pour une utilisation interactive, je ne vois pas l'interet. bash ne doit sa notorieté qu'au fait que ce soit le shell du projet GNU (et donc le shell par defaut sur la plupart des Unix).
sur la plupart des *Linux*, pardon. C'est le shell par defaut (le /bin/sh) d'assez peu d'Unix (Linux, Hurd, certaines versions de Cygwin ou MacOSX) ; en general, c'est plutot des derivés de ksh ou ash.
-- Stephane
2004-09-03, 10:30(+00), Stephane Chazelas:
[...]
Pour une utilisation interactive, je ne vois pas l'interet. bash
ne doit sa notorieté qu'au fait que ce soit le shell du projet
GNU (et donc le shell par defaut sur la plupart des Unix).
sur la plupart des *Linux*, pardon. C'est le shell par defaut
(le /bin/sh) d'assez peu d'Unix (Linux, Hurd, certaines versions
de Cygwin ou MacOSX) ; en general, c'est plutot des derivés de
ksh ou ash.
Pour une utilisation interactive, je ne vois pas l'interet. bash ne doit sa notorieté qu'au fait que ce soit le shell du projet GNU (et donc le shell par defaut sur la plupart des Unix).
sur la plupart des *Linux*, pardon. C'est le shell par defaut (le /bin/sh) d'assez peu d'Unix (Linux, Hurd, certaines versions de Cygwin ou MacOSX) ; en general, c'est plutot des derivés de ksh ou ash.