Re: zsh vs bash
hello, > Ton message n'est pas un troll mais un cadeau. joyeux noel alors :) > Merci ! avec plaisir marc
Re: zsh vs bash
Ce n'est pas un troll selon moi car c'est constructif, argumenté et appuyé par
des exemples concrets.
Usuellement, on choisit ses premiers outils parce qu'on a besoin de régler un
problème plutôt urgemment (et on n'a donc pas le temps d'étudier tout ce qui se
existe). Alors, on prend l'outil dont on a le plus entendu parler. Et c'est
rarement le meilleur outil (tiens, ça me fait penser à pourquoi les gens ont
utilisé aussi massivement Windows et Office... ; et aussi à comment je
percevais Linux avant de décider de l'utiliser : trop compliqué, un truc pour
les experts).
Ton message n'est pas un troll mais un cadeau.
Merci !
- Original Message -
From: Marc Chantreux
To: roger tarani
Cc: 'Liste Debian'
Sent: Mon, 24 Dec 2018 12:25:29 +0100 (CET)
Subject: zsh vs bash
salut,
(parceque j'aime lancer un troll a quelques heures du départ en vacances)
> zsh : je suis resté à bash car situé entre le vieux sh et l'évolué
> esh et capable de faire tourner tous les scripts (bash et sh, mais pas
> zsh je crois). Mais la syntaxe de zsh serait beaucoup(?) plus riche.
j'ai été un grand fan quand je ne connaissais que les shells
historiques, j'ai même été à l'origine de la traduction francaise d'ABS
(advanced bash scripting) ... j'ai découvert zsh parceque quelqu'un
avait écrit un post je ne sais plus ou lors de la sortie d'une version
majeure de bash (v3.0 je crois). la conclusion était que l'amélioration
était significative mais que bash restait à la traine. il conseillait de
regarder zsh ... ce que j'ai fais.
depuis je ne subit bash que parceque d'autres me l'infligent (par contre
je me suis mis a utiliser mksh, le ksh de openbsd et rc) en produisant
des outils qu'il m'arrive de devoir maintenir.
le shell scripting a deux énemis à mes yeux:
* la croyance dans la portabilité POSIX
* bash ... un shell a peine superieur à mksh avec le rapport
poids/puissance le pire du monde
mes choix actuels sont
* lorsque j'ai besoin de qqchose de léger, j'utilise rc (fourni par le
paquet 9base)
ou mksh.
* lorsque j'ai besoin de confort (tant pour la puissance de zle que pour
la richesse du langage)
maintenant à chaque fois que quelqu'un vient me montrer les évolutions
de bash, c'est un peu comme quand on me parle de l'évolution de python
ou JS: je trouve ça super cool que mon interlocuteur aie enfin à
disposition des fonctionalités que j'utilise depuis 20 ans mais pourquoi
avoir attendu tout ce temps ? jette un coup d'oeil dans man zshexpn:
cette partie du manuel à elle seule justifie de switcher. (si tu fais
man zsh, tu tombes sur la liste de toutes les sections) je ne détaille
pas ici parceque ce serait vite un roman mais
* une chaine est une chaine (le word splitting n'est pas automatique),
c'est con mais ca rend l'écriture plus naturelle quand tu viens de
langages dynamiques
* il y a plein de raccourcis pratiques pour modifier des chaines ou des
tableaux
cd =perl6(:A:h:h)
est l'équivalent de
cd $( dirname $( dirname $( realpath $( which perl6 )))
= => which
:A => realpath
:h => dirname
notes que tu a evité plein de forks juste parceque la syntaxe vole à
ton secours. c'est souvent le cas
* la syntaxe "alternative" (cf. zshmisc) est pour moi suffisante
for it in *.svg; do
gzip -c9 $it
done
s'écrit en zsh
for it (*.svg) gzip -c9 $it
perso j'ai un petit alias
@='for it'
du coup au quotidien j'écris plutot
@ (*.svg) gzip -c9 $it
* les extendedglob ... permettent des choses extrêmement puissantes
(comme le fait de pouvoir rajouter ses propres filtres, le ** pour
les motifs récursifs) ... globs que tu peux stocker dans des variables
que tu vas pouvoir ensuite jouer avec le modifier ~
images='(#i)*.(png|jpe#g|svg)'
@ ( a.png a.PNG a.jpg a.jpeg ) { [[ $it == $~images ]] && echo ok }
ls -l **/$~images # recursive parceque ** (adieu find dans les cas
simples)
* le shell courant lit dans le dernier élément du pipe courant. ca a
l'air de rien comme ca parceque tu te dis que les deux lignes
suivantes se valent
hostname | read h
h=$(hostname)
sauf que pouvoir écrire
fmt='$login is member of $gid'
getent passwd mc | IFS=: read login _ uid gid _
print ${(e)fmt}
mc is member of 1000
note l'expansion modifier e (evaluation) qui te permet de créer des
templates. si tu utilises les glob expansions en plus tu peux écrire
des trucs cools du genre
fmt='%F{blue}$login%f is member of %K{red}$gid%k'
getent passwd mc | IFS=: read login _ uid gid _
print ${(%e)fmt}
et voilà de la couleur :)
> En pratique, c'est quoi les avantages et les inconvénients de zsh (par
> rapport à bash) ?
l'expressivité de zsh permet d'éviter des forks a répétitions à base de
bricolages qui l'ont de sens que lorsque tu les écris comme t'obligent à
en faire les shells traditionnels. zsh n'est pas seulement plus
aggréable à écrire mais aussi tellement plus aggréable à maintenir.
le seul inconvénient c'est qu'il y a beaucoup de cho
zsh vs bash
salut,
(parceque j'aime lancer un troll a quelques heures du départ en vacances)
> zsh : je suis resté à bash car situé entre le vieux sh et l'évolué
> esh et capable de faire tourner tous les scripts (bash et sh, mais pas
> zsh je crois). Mais la syntaxe de zsh serait beaucoup(?) plus riche.
j'ai été un grand fan quand je ne connaissais que les shells
historiques, j'ai même été à l'origine de la traduction francaise d'ABS
(advanced bash scripting) ... j'ai découvert zsh parceque quelqu'un
avait écrit un post je ne sais plus ou lors de la sortie d'une version
majeure de bash (v3.0 je crois). la conclusion était que l'amélioration
était significative mais que bash restait à la traine. il conseillait de
regarder zsh ... ce que j'ai fais.
depuis je ne subit bash que parceque d'autres me l'infligent (par contre
je me suis mis a utiliser mksh, le ksh de openbsd et rc) en produisant
des outils qu'il m'arrive de devoir maintenir.
le shell scripting a deux énemis à mes yeux:
* la croyance dans la portabilité POSIX
* bash ... un shell a peine superieur à mksh avec le rapport
poids/puissance le pire du monde
mes choix actuels sont
* lorsque j'ai besoin de qqchose de léger, j'utilise rc (fourni par le
paquet 9base)
ou mksh.
* lorsque j'ai besoin de confort (tant pour la puissance de zle que pour
la richesse du langage)
maintenant à chaque fois que quelqu'un vient me montrer les évolutions
de bash, c'est un peu comme quand on me parle de l'évolution de python
ou JS: je trouve ça super cool que mon interlocuteur aie enfin à
disposition des fonctionalités que j'utilise depuis 20 ans mais pourquoi
avoir attendu tout ce temps ? jette un coup d'oeil dans man zshexpn:
cette partie du manuel à elle seule justifie de switcher. (si tu fais
man zsh, tu tombes sur la liste de toutes les sections) je ne détaille
pas ici parceque ce serait vite un roman mais
* une chaine est une chaine (le word splitting n'est pas automatique),
c'est con mais ca rend l'écriture plus naturelle quand tu viens de
langages dynamiques
* il y a plein de raccourcis pratiques pour modifier des chaines ou des
tableaux
cd =perl6(:A:h:h)
est l'équivalent de
cd $( dirname $( dirname $( realpath $( which perl6 )))
= => which
:A => realpath
:h => dirname
notes que tu a evité plein de forks juste parceque la syntaxe vole à
ton secours. c'est souvent le cas
* la syntaxe "alternative" (cf. zshmisc) est pour moi suffisante
for it in *.svg; do
gzip -c9 $it
done
s'écrit en zsh
for it (*.svg) gzip -c9 $it
perso j'ai un petit alias
@='for it'
du coup au quotidien j'écris plutot
@ (*.svg) gzip -c9 $it
* les extendedglob ... permettent des choses extrêmement puissantes
(comme le fait de pouvoir rajouter ses propres filtres, le ** pour
les motifs récursifs) ... globs que tu peux stocker dans des variables
que tu vas pouvoir ensuite jouer avec le modifier ~
images='(#i)*.(png|jpe#g|svg)'
@ ( a.png a.PNG a.jpg a.jpeg ) { [[ $it == $~images ]] && echo ok }
ls -l **/$~images # recursive parceque ** (adieu find dans les cas
simples)
* le shell courant lit dans le dernier élément du pipe courant. ca a
l'air de rien comme ca parceque tu te dis que les deux lignes
suivantes se valent
hostname | read h
h=$(hostname)
sauf que pouvoir écrire
fmt='$login is member of $gid'
getent passwd mc | IFS=: read login _ uid gid _
print ${(e)fmt}
mc is member of 1000
note l'expansion modifier e (evaluation) qui te permet de créer des
templates. si tu utilises les glob expansions en plus tu peux écrire
des trucs cools du genre
fmt='%F{blue}$login%f is member of %K{red}$gid%k'
getent passwd mc | IFS=: read login _ uid gid _
print ${(%e)fmt}
et voilà de la couleur :)
> En pratique, c'est quoi les avantages et les inconvénients de zsh (par
> rapport à bash) ?
l'expressivité de zsh permet d'éviter des forks a répétitions à base de
bricolages qui l'ont de sens que lorsque tu les écris comme t'obligent à
en faire les shells traditionnels. zsh n'est pas seulement plus
aggréable à écrire mais aussi tellement plus aggréable à maintenir.
le seul inconvénient c'est qu'il y a beaucoup de choses écrites en/pour bash.
il m'arrive donc souvent de prendre un script et de le réécrire avec mes
conventions, me coupant ainsi d'une possible communauté upstream.
> Y a-t-il un moyen de travailler (zsh ou bash) avec une double syntaxe,
> cad la syntaxe fine pas facile à mémoriser à moins de l'utiliser tout
> le temps, et une syntaxe plus facile à mémoriser ?
les bases de bash et zsh sont les mêmes: ksh. apres tu vas avoir de
petites subtilités. je parlais par exemple du word splitting
words="they don't come easy"
for w in $words; do
echo $w
done
te donne ca sous bash
they
don't
come
easy
et ca sous zsh
they don't come easy
parcequ'en zsh, une chaine
[HS] zsh vs bash
Bonjour à tous, NB: Désolé pour le HS, mais par extension -pour faire de jolis scripts-, ça l'est pas trop, peut-être !?... :P Dans le cadre de mon auto-formation, je cherche les différences entre bash et zsh ... J'ai bien trouvé quelques trucs : les couleurs, les extensions, la complétion, mais par bribes à différents endroits... Je suis actuellement plongé dans la doc zsh, et à part relire ce que je connais de bash ... Si vous aviez quelque référence pour m'orienter !?... Merci ! Dams -- pgpCgjXIQcl0q.pgp Description: PGP signature
Re: [HS] zsh vs bash
Damien Ulrich a écrit : Bonjour à tous, [...] Dans le cadre de mon auto-formation, je cherche les différences entre bash et zsh ... [...] Si vous aviez quelque référence pour m'orienter !?... http://cli.asyd.net/home/ http://zshwiki.org/home/ Daniel -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [HS] zsh vs bash
Le lundi 16 avril 2007 12:44, Daniel Caillibaud a écrit : Damien Ulrich a écrit : Bonjour à tous, [...] Dans le cadre de mon auto-formation, je cherche les différences entre bash et zsh ... [...] Si vous aviez quelque référence pour m'orienter !?... http://cli.asyd.net/home/ http://zshwiki.org/home/ Merci ! :) Daniel Dams -- pgp1HTcuyRKvh.pgp Description: PGP signature
Re: [HS] zsh vs bash
Damien Ulrich a écrit, lundi 16 avril 2007, à 09:17 : Bonjour à tous, bonjour, NB: Désolé pour le HS, mais par extension -pour faire de jolis scripts-, ça l'est pas trop, peut-être !?... :P Dans le cadre de mon auto-formation, je cherche les différences entre bash et zsh [...] Si vous aviez quelque référence pour m'orienter !?... Ce n'est pas une référence, mais une collection de trucs et astuces --- ça pourra être utile et/ou servir d'exercices --- un paquet deb (et hop, retour en charte :) appelé « zsh-lovers » http://deb.grml.org/pool/main/z/zsh-lovers/ Merci ! de rien, -- Jacques L'helgoualc'h -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [HS] zsh vs bash
Le lundi 16 avril 2007 16:45, Jacques L'helgoualc'h a écrit : Damien Ulrich a écrit, lundi 16 avril 2007, à 09:17 : Bonjour à tous, bonjour, NB: Désolé pour le HS, mais par extension -pour faire de jolis scripts-, ça l'est pas trop, peut-être !?... :P Dans le cadre de mon auto-formation, je cherche les différences entre bash et zsh [...] Si vous aviez quelque référence pour m'orienter !?... Ce n'est pas une référence, mais une collection de trucs et astuces --- ça pourra être utile et/ou servir d'exercices --- un paquet deb (et hop, retour en charte :) appelé « zsh-lovers » http://deb.grml.org/pool/main/z/zsh-lovers/ Rhââh lovely :) NB: le fichier : zsh-lovers_0.6-3_all.deb#deb/CONTENTS/usr/share/vim/syntax/zsh.vim 3: Maintainer: Nikolai Weibull [EMAIL PROTECTED] 4: URL: http://www.pcppopper.org/vim/syntax/pcp/zsh/ cette URL renvoit à une page avec liens commerciaux (uniquement), fenêtre popup (bloquée) et fichier .swf en download ce même fichier est manipulé en 'dpkg-divert' en preinst du .deb je crois que je vais bien étudier ce qu'il fait avant d'installer... :P NB2: j'espère que vous ne considèrerez pas cette remarque comme un troll malsain... Merci ! de rien, Merci -- Jacques L'helgoualc'h -- pgpTZPYxm7nKo.pgp Description: PGP signature
Re: [HS] zsh vs bash
Damien Ulrich a écrit, lundi 16 avril 2007, à 17:54 : Le lundi 16 avril 2007 16:45, Jacques L'helgoualc'h a écrit : [...] http://deb.grml.org/pool/main/z/zsh-lovers/ Rhââh lovely :) NB: le fichier : zsh-lovers_0.6-3_all.deb#deb/CONTENTS/usr/share/vim/syntax/zsh.vim 3: Maintainer: Nikolai Weibull [EMAIL PROTECTED] 4: URL: http://www.pcppopper.org/vim/syntax/pcp/zsh/ cette URL renvoit à une page avec liens commerciaux (uniquement), fenêtre popup (bloquée) et fichier .swf en download Ah oui... Merci w3m, le flash et le popup me sont épargnés. On dirait que ce domaine a été renouvelé/squatté à l'insu du plein gré des titulaires précédents :/ --- cf. un « whois pcppopper.org », ça n'a pas grand-chose à voir avec de sympathiques barbus autrichiens... ce même fichier est manipulé en 'dpkg-divert' en preinst du .deb je crois que je vais bien étudier ce qu'il fait avant d'installer... :P NB2: j'espère que vous ne considèrerez pas cette remarque comme un troll malsain... Non, vendredi est encore loin. -- Jacques L'helgoualc'h -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/sh != /bin/bash ? [was Re: zsh vs bash]
Craig Sanders [EMAIL PROTECTED] writes: /bin/sh and /bin/bash are not equivalent. bash is a superset of sh functionality. bash behaves differently depending on whether it is invoked as sh or as bash (at least the new version 2 does). bash when invoked as /bin/sh is more posix compliant. when invoked as /bin/bash, all the bash enhancements are available. But why would you want posix compliance, and bash extended features in the same time? If you really need bash enhancements in init.d and other misc scripts, invoke them with #!/bin/bash. On the other hand, if you want to make this scripts more portable (as they should be), then invoke them with /bin/sh, and do not use bash extended functionality. You can always try to run it with /bin/sh as zsh to check portability. e.g. /usr/sbin/dwww-doc-index from the dwww package doesn't work at all if the first line is '#! /bin/sh', but works correctly if the first line is '#! /bin/bash'. And that's correct IMO. If you start your script with /bin/sh than use it as posix compliant sh, if you want _any_ of other shells specific features, start your script with explicit call to that shell, and that'll make your script shell dependent, what it really is. -- Tomislav Vujec [EMAIL PROTECTED] --- To understand recursion, one must first understand recursion...
Re: /bin/sh != /bin/bash ? [was Re: zsh vs bash]
[EMAIL PROTECTED] writes: [snip] The only problem is that some packages, such as gzip, give an error in the perl (!!??) postinst script. Here (with gzip 1.2.4-14) the postinst script is for /bin/sh. I suspect the problem is the line in /etc/zshenv: PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:. which means that every time zsh is used, /usr/sbin gets removed from the PATH, which is where install-info (a perl script used by the postinst) is located. I've commented out this line and put it into /etc/zlogin instead, which corresponds with setting PATH for bash in /etc/profile. Maybe I should file a bug report on zsh for this? -- Carey Evans * [EMAIL PROTECTED] Linux and Linux-like systems such as UNIX(R) and FreeBSD... - Yggdrasil Computing, [EMAIL PROTECTED]
Re: /bin/sh != /bin/bash ? [was Re: zsh vs bash]
On Wed, 12 Mar 1997, Steve wrote: The problem is that the scripts only work with bash in sh mode and not with sh-compatible shells such as ash. Try making /bin/sh a symlink to /bin/ash and reboot. You'll get error messages from the startup So if these script doesn't work with ash nor zsh in sh-mode, then shouldn't they be changed to #!/bin/bash ? Most people have no problem using ash or zsh for /bin/sh. But most people are not Debian users. :-/ I'd like to have zsh as my *only* shell on the system. Apparently, this is not possible with Debian. What are those bash-specific options you refer to? Could the scripts be changed to work with ash zsh's sh-compatible modes? // Jonas [EMAIL PROTECTED] [2:201/262.37]
Re: /bin/sh != /bin/bash ? [was Re: zsh vs bash]
Carey Evans ([EMAIL PROTECTED]) wrote on 14 March 1997 13:32: Here (with gzip 1.2.4-14) the postinst script is for /bin/sh. I suspect the problem is the line in /etc/zshenv: PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:. which means that every time zsh is used, /usr/sbin gets removed from the PATH, which is where install-info (a perl script used by the postinst) is located. I've commented out this line and put it into /etc/zlogin instead, which corresponds with setting PATH for bash in /etc/profile. Maybe I should file a bug report on zsh for this? If the zsh package has this line it's obviously a bug. Here I install it manually because I upgrade more often than the maintainer, and I don't have this line. Anyway, this isn't the problem; it happens in a read or something.
Re: /bin/sh != /bin/bash ? [was Re: zsh vs bash]
If those scripts actually require bash then why isn't the first line #!/bin/bash? Is this a bug, or is it written in stone that /bin/sh and /bin/bash are equivalent? /etc/init.d/* do, in fact, all start with #!/bin/sh as they should. I believe that bash was written to be a free version of and painless replacement for sh. So if /bin/sh is a link to bash, all is well. The problem is that the scripts only work with bash in sh mode and not with sh-compatible shells such as ash. Try making /bin/sh a symlink to /bin/ash and reboot. You'll get error messages from the startup scripts. Even when invoked as sh, bash has options not available in other sh clones. The scripts use these options and thus don't work with Bourne shell clones other than bash. It would be nice to be able to use ash instead of bash, especially on small systems, because ash uses less memory. The problem arose when the original writer linked /bin/sh to zsh. I understand, perhaps incorrectly, that zsh is a freen version of ksh, but it apparently has some failure to mesh with sh/bash. Zsh, like bash, has sh compatibility options enabled when invoked as sh. Most people have no problem using ash or zsh for /bin/sh. But most people are not Debian users. :-/
Re: /bin/sh != /bin/bash ? [was Re: zsh vs bash]
On Mar 03, 1997 at 01:45:37PM -0800, Steve wrote: I set my system shell to zsh as well, and replaced all the /bin/bash in /etc/passwd to /usr/bin/zsh, but when I tried to move /bin/sh to point to /usr/bin/zsh, all of the /etc/init.d/* scripts blew up. If those scripts actually require bash then why isn't the first line #!/bin/bash? Is this a bug, or is it written in stone that /bin/sh and /bin/bash are equivalent? And if so, that's not very portable; /bin/sh is typically something else again, and certainly is on this Solaris box I'm typing this on. /bin/sh has no command line editing, for example. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], Melbourne, Australia. Student, computer science computer systems engineering. 3rd year, RMIT. http://yallara.cs.rmit.edu.au/~moffatt CPOM: [ ] 40% PGP key available from web page above.
Re: /bin/sh != /bin/bash ? [was Re: zsh vs bash]
Maybe either the scripts are so old that they were never updated when newer shells besides bash came out, or maybe they assumed that all newer shells would be bash-compatible, or maybe the people who wrote them are just stupid :) Not everyone's a genius you know :) On Wed, 12 Mar 1997, Steve wrote: I set my system shell to zsh as well, and replaced all the /bin/bash in /etc/passwd to /usr/bin/zsh, but when I tried to move /bin/sh to point to /usr/bin/zsh, all of the /etc/init.d/* scripts blew up. If those scripts actually require bash then why isn't the first line #!/bin/bash? Is this a bug, or is it written in stone that /bin/sh and /bin/bash are equivalent?
Re: /bin/sh != /bin/bash ? [was Re: zsh vs bash]
zsh can be used as sh instead of bash for almost everything. I have two machines here where /bin/sh is a link to /bin/zsh. This makes apsfilter work. bash gives an error in a pipe, complaining about some signal. It's a bash bug; with zsh it works. The only problem is that some packages, such as gzip, give an error in the perl (!!??) postinst script. I don't know why. Perhaps the zsh maintainer could investigate this? Carlos
Re: zsh vs bash
Here are two ways I know of: 1) echo set editing-mode vi ~root/.inputrc 2) exec bash -o vi --Bob James W. Lynch wrote: - Received message begins Here - This subject brings up a question I've had for a long time. Bash appears to be the shell that I get when I log in as root or do an su command. I'm from the old school and perfer vi editing of commands, but I have yet to be able to make bash use vi as root. I've set EDITOR and FCEDIT. I've set editing-mode vi. I can't seem to get root to use anything but emacs editing mode. Is this a diabolical plot by the Linux developers to force emacs on the world? 8^) Bash works as expected, described and designed when I'm a normal user. Can I do it? How? Thanks, Jim. Jim Lynch, System Engineer, SGI/Cray Research, Inc. / ARS: K4GVO Federal Business Systems, Phone: (770) 631-2254, Email: [EMAIL PROTECTED] Suite 270, 200 Westpark Drive, Peachtree City, GA 30269
Re: zsh vs bash
[EMAIL PROTECTED] (James W. Lynch) writes: This subject brings up a question I've had for a long time. Bash appears to be the shell that I get when I log in as root or do an su command. I'm from the old school and prefer vi editing of commands, but I have yet to be able to make bash use vi as root. I've set EDITOR and FCEDIT. I've set editing-mode vi. I can't seem to get root to use anything but emacs editing mode. Is this a diabolical plot by the Linux developers to force emacs on the world? 8^) Bash works as expected, described and designed when I'm a normal user. Can I do it? How? I use vi as a root, and vi editing mode, but in zsh. Yes my root shell is zsh. Now days when zsh runs autoconf configure scripts I am even thinking to put it for /bin/sh instead of bash... heard that zsh developers do that. P.S. As a normal user I use xemacs, but of course in viper mode :-) -- Tomislav Vujec [EMAIL PROTECTED] --- To understand recursion, one must first understand recursion...
Re: zsh vs bash
I set my system shell to zsh as well, and replaced all the /bin/bash in /etc/passwd to /usr/bin/zsh, but when I tried to move /bin/sh to point to /usr/bin/zsh, all of the /etc/init.d/* scripts blew up. Most of their scripting is done in bash format, so unless you want to either make zsh bash-compatible before running the scripts, or you want to rewrite every script made for bash, I'd just leave /bin/sh pointing to /usr/bin/bash (I moved my /bin/bash to /usr/bin/bash just for consistancy...) Just a newbie's opinion :) On 12 Mar 1997, Tomislav Vujec wrote: [EMAIL PROTECTED] (James W. Lynch) writes: This subject brings up a question I've had for a long time. Bash appears to be the shell that I get when I log in as root or do an su command. I'm from the old school and prefer vi editing of commands, but I have yet to be able to make bash use vi as root. I've set EDITOR and FCEDIT. I've set editing-mode vi. I can't seem to get root to use anything but emacs editing mode. Is this a diabolical plot by the Linux developers to force emacs on the world? 8^) Bash works as expected, described and designed when I'm a normal user. Can I do it? How? I use vi as a root, and vi editing mode, but in zsh. Yes my root shell is zsh. Now days when zsh runs autoconf configure scripts I am even thinking to put it for /bin/sh instead of bash... heard that zsh developers do that. P.S. As a normal user I use xemacs, but of course in viper mode :-) -- Tomislav Vujec [EMAIL PROTECTED] --- To understand recursion, one must first understand recursion...
/bin/sh != /bin/bash ? [was Re: zsh vs bash]
I set my system shell to zsh as well, and replaced all the /bin/bash in /etc/passwd to /usr/bin/zsh, but when I tried to move /bin/sh to point to /usr/bin/zsh, all of the /etc/init.d/* scripts blew up. If those scripts actually require bash then why isn't the first line #!/bin/bash? Is this a bug, or is it written in stone that /bin/sh and /bin/bash are equivalent?
Re: /bin/sh != /bin/bash ? [was Re: zsh vs bash]
On Wed, 12 Mar 1997, Steve wrote: I set my system shell to zsh as well, and replaced all the /bin/bash in /etc/passwd to /usr/bin/zsh, but when I tried to move /bin/sh to point to /usr/bin/zsh, all of the /etc/init.d/* scripts blew up. If those scripts actually require bash then why isn't the first line #!/bin/bash? Is this a bug, or is it written in stone that /bin/sh and /bin/bash are equivalent? /bin/sh and /bin/bash are not equivalent. bash is a superset of sh functionality. bash behaves differently depending on whether it is invoked as sh or as bash (at least the new version 2 does). bash when invoked as /bin/sh is more posix compliant. when invoked as /bin/bash, all the bash enhancements are available. e.g. /usr/sbin/dwww-doc-index from the dwww package doesn't work at all if the first line is '#! /bin/sh', but works correctly if the first line is '#! /bin/bash'. (reminds me, i should submit this as a bug report. nope, no need...it's already reported as bug #7267 with a patch to fix it) craig
Re: zsh vs bash
- Received message begins Here - This subject brings up a question I've had for a long time. Bash appears to be the shell that I get when I log in as root or do an su command. I'm from the old school and perfer vi editing of commands, but I have yet to be able to make bash use vi as root. I've set EDITOR and FCEDIT. I've set editing-mode vi. I can't seem to get root to use anything but emacs editing mode. Is this a diabolical plot by the Linux developers to force emacs on the world? 8^) Bash works as expected, described and designed when I'm a normal user. Can I do it? How? Thanks, Jim. Jim Lynch, System Engineer, SGI/Cray Research, Inc. / ARS: K4GVO Federal Business Systems, Phone: (770) 631-2254, Email: [EMAIL PROTECTED] Suite 270, 200 Westpark Drive, Peachtree City, GA 30269
Re: zsh vs bash
Telephone Game! James W. Lynch said (on 08:43 AM 3/11/97 -0500): -- Received message begins Here - - -This subject brings up a question I've had for a long time. Bash appears -to be the shell that I get when I log in as root or do an su command. -I'm from the old school and perfer vi editing of commands, but I have -yet to be able to make bash use vi as root. I've set EDITOR and FCEDIT. -I've set editing-mode vi. I can't seem to get root to use anything -but emacs editing mode. Is this a diabolical plot by the Linux developers -to force emacs on the world? 8^) H.setting the EDITOR and FCEDIT commands to vi or path/vi will do it, but if it doesn't then this should: set -o vi or if you decided to use emacs: set -o emacs I personally prefer to use ZSH, but then, using an oddball/combo shell just means that you have to learn it, in addition to the standards: SH/KSH and CSH. The Doctor What Guru of the Gods [EMAIL PROTECTED] Hackers confuse Xmas (25 Dec) with Halloween (31 Oct) Just because you aren't paranoid doesn't mean they aren't out to get you. Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories? -mkj -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.2 mQBtAi5kHGQAAAEDALj1w94Nz9q/sEiDp4wKLR48A1Fotrh8Xee4SgBU6UIb+wMB w8+jeAddEJWXHMQasJPOh9zwY1D2F3BnVwoAoHW7Z8dv8x4FlKVjHH8TQrrVjMUL ZwrwqktTaK7rYU9SHQAFEbQmQ2hyaXN0aWFuIEcuIEhvbHRqZSA8ZG9jd2hhdEB1 aXVjLmVkdT6JAHUDBRAuZjOUU2iu62FPUh0BAQWqAv9NV3rfaM467PAXs7EfyuWS 9ahAuLSzq4jFPCgGOAzO6aCbyMxUI0JV4XBaX0eSVXfUIpSEm29AgvtNf/R30UJM 6Tm7rJbVTgrmpOwGaHG8/jW2hPOuQe06VcH5aI5Ijl4= =AV9k -END PGP PUBLIC KEY BLOCK-
Re: zsh vs bash
Richard Kettlewell [EMAIL PROTECTED] writes: hosts=(valour cushioned myrddin tacitus chiark \ mercury.elmailer.net wigwam.elmail.co.uk sunsite.doc.ic.ac.uk \ ftp.uu.net ftp.sendmail.org tlingit.elmail.co.uk) ssh=(chiark) compctl -k ssh ssh compctl -k hosts telnet ftp rlogin rsh ping traceroute compctl -k hosts -f rcp scp And I'll add my favorite: compctl -x n[1,~] -u -S / - n[1,//] -k hosts -S / - s[] \ -f -k (http:// ftp:// gopher:// telnet:// wais://) -S \ -- lynx Mosaic netscape compctl -x n[1,~] -u -S / - n[1,//] -k hosts -S / - s[] \ -k (http:// ftp://) -S -- wget rftp -- Tomislav Vujec [EMAIL PROTECTED] --- To understand recursion, one must first understand recursion...
Re: zsh vs bash
On Sat, 8 Mar 1997, Bob Clark wrote: This is *not* a flame. This list is kind of touchy lately. It's just that I'm a big fan of bash (with vi editting mode instead of emacs) and if there's a better shell out there I'd like to give it a try. It just doesn't sound like zsh has anything to offer that bash doesn't. Speed. Bash is cumbersome. But if you have the computing power it I don't see that zsh has too much else. Comments anyone? Personally I think they should write a bourne shell in Perl (psh?). Now that could be fun. -- Brian S. Julin
Re: zsh vs bash
This is *not* a flame. This list is kind of touchy lately. It's just that I'm a big fan of bash (with vi editting mode instead of emacs) and if there's a better shell out there I'd like to give it a try. It just doesn't sound like zsh has anything to offer that bash doesn't. Comments anyone? Richard Sharman wrote: Thought writes: Hey, what do you guys think is better, zsh or bash? I prefer zsh, I find it easier to work with. For a while it had several features missing from bash (and most shells), but bash has caught up on many of them. It still has some features which don't seem to be in bash (though perhaps it's just a matter of finding out how to setup bash): * ability to line edit a multi-line command. I find this very useful. Say you've just typed in a multi-line for...done line and need to fix a type or redo it slightly differently. Under zsh you simply using ^p like any single line. Add this to your .bashrc if you;d like this feature in bash too: #put multi-line commands together as one line export command_oriented_history= * the vared builtin -- allows you to line edit a variable (e.g. vared path). Doesn't export PATH=$PATH:other_stuff do the same? * allows you to defined what a word is (e.g. for using backward-word). Using the vared command makes it nice and simple, just do vared WORDCHARS. Is this different from `B' when editing command lines in bash? * accepts both csh and sh syntax, which is useful if you're used to a tcsh environment at work, or just like some of the csh things like prompt instead of PS1, or using a wordlist $path rather than a colon-separated $PATH. Bash also accepts both csh and sh syntax. * ability to try out an interactive command with M-x without having to specifically bind it. I don't know what this means but it may be useful. * the infer next command. (Hmmm, this seems to be broken now; it used to work and was very nice.) (Bash now has something limilar, operate-and-get-next (C-o). I like zsh's approach where you use this command when you want the next command; bash requires you to think ahead and realize before submitting that you will want the next command.) Again I don't know what this means. Is this just `n' in bash? * automatic completion on variables names, e.g. type export DISP and hit tab. (I just checked, in bash you can use Esc-$ to specifically complete a variable name; in zsh the default compctl (completion) has been setup to complete for a variable name if the command is export. While the zsh seemed easier, I guess the bash approach allows you to control it more.) However, bash has some advantages: * better built-in help (zsh has some if you set it up as suggested, but bash seems better and works out-of-the-box) * Ability to interactively define keyboard macros (similar to within emacs) * Bash uses the GNU readline which can be used from any C-program. Actually, I think the last point is probably a very important one. Both shell's line editing is good, but bash's readline can be included in any C program. By putting your preferences in your ~/.inputrc file you can thus customize many programs in one fell swoop. In any case, I would say try them both, and then pick one and read the manual or info and get familiar with it. And every so often read it again to pick some more hints. There are 2 programs that really pay off putting a bit of effort into learning: the shell you use and the editor you use. Picking a simple and easy to use editor is a short sighted approach. Pick a powerful editor and invest some time in learning it. (You don't have to learn it all, and you don't have to learn all that much at first, either.) It will really pack off. And I think the same philosophy applies, perhaps to a lesser degree, to the shell you use. Richard
Re: zsh vs bash
Bob Clark [EMAIL PROTECTED] writes:
This is *not* a flame. This list is kind of touchy lately. It's just
that I'm a big fan of bash (with vi editting mode instead of emacs) and
if there's a better shell out there I'd like to give it a try. It just
doesn't sound like zsh has anything to offer that bash doesn't.
[snip]
* ability to line edit a multi-line command. I find this very
useful. Say you've just typed in a multi-line for...done line
and need to fix a type or redo it slightly differently. Under zsh
you simply using ^p like any single line.
Add this to your .bashrc if you;d like this feature in bash too:
#put multi-line commands together as one line
export command_oriented_history=
That doesn't do quite the same here - it joins the lines together.
zsh leaves the line breaks intact.
* the vared builtin -- allows you to line edit a variable
(e.g. vared path).
Doesn't export PATH=$PATH:other_stuff do the same?
It's OK for adding stuff to either end, but not so good for
interactively removing a bit from the middle of a variable, or
rearranging a bit.
* allows you to defined what a word is (e.g. for using
backward-word). Using the vared command makes it nice and simple,
just do vared WORDCHARS.
Is this different from `B' when editing command lines in bash?
It sets what B (in zsh's vi mode) moves backwards over. I don't see
any way to do this in readline(3), but I wouldn't be very surprised if
it's possible. I would be more surprised if it's possible without
reloading bash.
* accepts both csh and sh syntax, which is useful if you're used to a
tcsh environment at work, or just like some of the csh things like
prompt instead of PS1, or using a wordlist $path rather than a
colon-separated $PATH.
Bash also accepts both csh and sh syntax.
tcsh% echo $path
/usr/bin/X11 /var/qmail/bin /usr/local/bin /usr/bin /bin /usr/games
zsh% echo $path
/usr/bin/X11 /var/qmail/bin /usr/local/bin /usr/bin /bin /usr/games
bash$ echo $path
* ability to try out an interactive command with M-x without having
to specifically bind it.
I don't know what this means but it may be useful.
Like if I don't have expand-cmd-path bound to a key but I want to
try it, I type M-x expand-cmd-pathEnter to see what happens.
* the infer next command. (Hmmm, this seems to be broken now;
it used to work and was very nice.) (Bash now has something limilar,
operate-and-get-next (C-o). I like zsh's approach where you use this
command when you want the next command; bash requires you to think
ahead and realize before submitting that you will want the next command.)
Again I don't know what this means. Is this just `n' in bash?
It's C-o in bash in emacs mode. I don't know about vi mode. (What
*is* `n' in bash's vi mode? It beeps at me in command mode.)
* automatic completion on variables names, e.g. type
export DISP and hit tab. (I just checked, in bash you can use
Esc-$ to specifically complete a variable name; in zsh the default
compctl (completion) has been setup to complete for a variable name
if the command is export. While the zsh seemed easier, I guess
the bash approach allows you to control it more.)
The programmable completion is even better if you have the time to set
it up. I quite like my kill completion
(compctl -j -P % -x 'p[1] s[-]' -k signals -- kill), and I have a
function somewhere to do completion on hostnames for ncftp.
[snip]
Another nice feature is that variables are split differently than most
sh-like shells. This means /tmp/$0.$$ does what you expect even if
$0 contains a space.
There are also extra redirection methods, like:
% ghostview =( zcat /usr/man/man8/pppd.8.gz | groff -man )
which creates a temporary file for ghostview to display pages from
properly.
And there are extensions to the pattern matching to make find(1) less
necessary:
% rm **/*.{orig,rej}(.)
does nearly the same as:
% find . -type f -name '*.orig' -o -name '*.rej' -print0 \
| xargs -r0 rm
unless I got the find syntax wrong.
The next version of zsh should use loadable modules (like Perl) so
that the line editing code, for example, won't get loaded unless it is
needed.
There's also an RPS1 variable which prints on the RHS of the line if
the terminal can do it and there's enough space. It was a bit buggy
in zsh 2.x, but works perfectly in 3.0. My setting is %~ which
puts the full path on the RHS for each command.
zsh also comes with a shell function that implements a simple file
editor, useful for editing very small files when the startup time of
vi is an issue. :-)
I'm sure there's more, but I'm going to stop now.
--
Carey Evans * [EMAIL PROTECTED]
Linux and Linux-like systems such as UNIX(R) and FreeBSD...
- Yggdrasil Computing, [EMAIL PROTECTED]
Re: zsh vs bash
On 8 Mar 1997, Richard Sharman wrote: [completion control] compctl (completion) has been setup to complete for a variable name if the command is export. While the zsh seemed easier, I guess the bash approach allows you to control it more.) I hope that's a typo.. The zsh way is more powerful. looking in /usr/doc/zsh/examples there are several examples of how to use zsh's advanced completion control. Example: if i type kill -Htab, zsh fills in UP. Next, I type systab, and zsh fills in klogd. The hyphen tells zsh that I want a signal to be completed, and the kill starting the line tells zsh I want a job to be completed. [bash] * Ability to interactively define keyboard macros (similar to within Tried the 'bindkey'-command yet? I use zsh to have alt-d mapped to direnter, I also have alt-z mapped to ../enter (making zsh go to parent directory). I have alt-l mapped to pipelistenter. They prove very useful. I also use bindkey to get INS and DEL keys working properly in the shell. // Jonas [EMAIL PROTECTED] [2:201/262.37]
Re: zsh vs bash
Both are excellent interactive shells. * automatic completion on variables names, e.g. type export DISP and hit tab. (I just checked, in bash you can use Esc-$ to specifically complete a variable name; in zsh the default compctl (completion) has been setup to complete for a variable name if the command is export. While the zsh seemed easier, I guess the bash approach allows you to control it more.) IIRC bash will complete over variable names when you write a $ at the start. zsh has other cute completion features, e.g. I have this in my .zshrc: hosts=(valour cushioned myrddin tacitus chiark \ mercury.elmailer.net wigwam.elmail.co.uk sunsite.doc.ic.ac.uk \ ftp.uu.net ftp.sendmail.org tlingit.elmail.co.uk) ssh=(chiark) compctl -k ssh ssh compctl -k hosts telnet ftp rlogin rsh ping traceroute compctl -k hosts -f rcp scp which gives me hostname completion on a selection of network commands. There are 2 programs that really pay off putting a bit of effort into learning: the shell you use and the editor you use. Picking a simple and easy to use editor is a short sighted approach. Pick a powerful editor and invest some time in learning it. (You don't have to learn it all, and you don't have to learn all that much at first, either.) It will really pack off. And I think the same philosophy applies, perhaps to a lesser degree, to the shell you use. Agreed. -- Richard Kettlewell http://www.elmail.co.uk/~richard/
zsh vs bash
Thought writes: Hey, what do you guys think is better, zsh or bash? I prefer zsh, I find it easier to work with. For a while it had several features missing from bash (and most shells), but bash has caught up on many of them. It still has some features which don't seem to be in bash (though perhaps it's just a matter of finding out how to setup bash): * ability to line edit a multi-line command. I find this very useful. Say you've just typed in a multi-line for...done line and need to fix a type or redo it slightly differently. Under zsh you simply using ^p like any single line. * the vared builtin -- allows you to line edit a variable (e.g. vared path). * allows you to defined what a word is (e.g. for using backward-word). Using the vared command makes it nice and simple, just do vared WORDCHARS. * accepts both csh and sh syntax, which is useful if you're used to a tcsh environment at work, or just like some of the csh things like prompt instead of PS1, or using a wordlist $path rather than a colon-separated $PATH. * ability to try out an interactive command with M-x without having to specifically bind it. * the infer next command. (Hmmm, this seems to be broken now; it used to work and was very nice.) (Bash now has something limilar, operate-and-get-next (C-o). I like zsh's approach where you use this command when you want the next command; bash requires you to think ahead and realize before submitting that you will want the next command.) * automatic completion on variables names, e.g. type export DISP and hit tab. (I just checked, in bash you can use Esc-$ to specifically complete a variable name; in zsh the default compctl (completion) has been setup to complete for a variable name if the command is export. While the zsh seemed easier, I guess the bash approach allows you to control it more.) However, bash has some advantages: * better built-in help (zsh has some if you set it up as suggested, but bash seems better and works out-of-the-box) * Ability to interactively define keyboard macros (similar to within emacs) * Bash uses the GNU readline which can be used from any C-program. Actually, I think the last point is probably a very important one. Both shell's line editing is good, but bash's readline can be included in any C program. By putting your preferences in your ~/.inputrc file you can thus customize many programs in one fell swoop. In any case, I would say try them both, and then pick one and read the manual or info and get familiar with it. And every so often read it again to pick some more hints. There are 2 programs that really pay off putting a bit of effort into learning: the shell you use and the editor you use. Picking a simple and easy to use editor is a short sighted approach. Pick a powerful editor and invest some time in learning it. (You don't have to learn it all, and you don't have to learn all that much at first, either.) It will really pack off. And I think the same philosophy applies, perhaps to a lesser degree, to the shell you use. Richard
