Re: zsh vs bash
Bob Clark <rlclark@jane.penn.com> 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-path<Enter> 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 <*> c.evans@clear.net.nz
"Linux and Linux-like systems such as UNIX(R) and FreeBSD..."
- Yggdrasil Computing, <pgpmoose.199702180607.14425@liw.clinet.fi>
Reply to: