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]
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]
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]
[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]
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: /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]
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]
> > 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 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
/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: 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... > >
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
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
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 "/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
- 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
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
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
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/
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 -H, zsh fills in UP. Next, I type sys, 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 dir, I also have alt-z mapped to ../ (making zsh go to parent directory). I have alt-l mapped to list. 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
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:" 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-path 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 Comp
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:" 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
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
