bug-bash
[Top][All Lists]
Advanced

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

[OT] Re: Syntax Question...


From: Stephane CHAZELAS
Subject: [OT] Re: Syntax Question...
Date: Mon, 3 Oct 2011 19:48:25 +0000 (UTC)
User-agent: slrn/pre1.0.0-18 (Linux)

2011-10-3, 09:12(-04), Greg Wooledge:
> On Mon, Oct 03, 2011 at 12:56:43PM +0000, Stephane CHAZELAS wrote:
>> If zsh is not compatible with any other shell, then bash isn't
>> either. What do you mean?
>
> http://zsh.sourceforge.net/FAQ/zshfaq02.html#l10
>
> "because of all the options it is not safe to assume a general zsh run
> by a user will behave as if sh or ksh compatible"

Not really the best place to discuss zsh but as you insist... :)

> Actually, this is a trend I wasn't previously aware of:
>
> "invoking zsh as sh or ksh (or if either is a symbolic link to zsh) sets
> appropriate options and improves compatibility (from within zsh itself,
> calling ARGV0=sh zsh will also work)"

Strange that you would say that. zsh is about the same age as
bash and has always been a few steps ahead of bash in terms of
interactive use functionality. It probably dethroned tcsh as
best interactive shells around the mid-90s (I started using it
around 97). bash and ksh93 both borrowed features from zsh. It
is more compatible with ksh than bash is (implements many of ksh
builtins like typeset, print, supports floating point
arithmetics, recursive globbing (actually, ksh borrowed that
from zsh)) 

> "The classic difference is word splitting, discussed in question 3.1;
> this catches out very many beginning zsh users. As explained there, this
> is actually a bug in every other shell."
>
> Um, no.  Word splitting is well defined, and changing how your shell
> handles it and declaring it "a bug in every other shell" is unacceptable.
[...]

The bug is the "implicit word splitting and filename generation
done upon variable expansion in list contexts".

You may not want to call it a bug, but I don't think anyone here
wouldn't agree to at least call it a "very unfortunate
misfeature responsible for 80% of shell script bugs, 90% of
exploitable shell script vulnerabilities, and a lot of
confusions in beginners"

While that feature made sense in the Bourne shell that didn't
have arrays, it's just a burden in all modern shells. That is
why several times a week you'll see comments on comp.unix.shell
such as: "don't leave a variable unquoted unless you have a very
good reason to (and know what you're doing (and taken
appropriate action to limit its side-effects))"

I'm not saying zsh is perfect, nor would I recommend it to
interpret POSIX scripts. There are misfeatures of Bourne/ksh it
didn't fix like removal of arguments that expand to an empty
string, command substitution that removes *every* trailing
newline character, some would argue it suffers a bit from
"feature creeping".

I don't write zsh script, not any more than I write bash or ksh
scripts. I don't care what shell interprets the scripts I write
(the main reason why I follow gnu.bash.bug is for the discussion
about portability) though I would rather have them interpreted
by the leaner and faster ash or pdksh derivatives.

But zsh cleaner and safer yntax, amazing completion system, and
globbing are amongst the main reasons why I wouldn't use any
other shell interactively.

If you want a shell with a very clean syntax, you can have a
look at plan9 "rc" shell (that has been ported to Unix).

-- 
Stephane




reply via email to

[Prev in Thread] Current Thread [Next in Thread]