[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: