zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh list <zsh-workers@sunsite.dk>
Subject: Re: treatment of empty strings - why is this not a bug?
Date: Thu, 15 Jan 2009 20:19:12 -0800	[thread overview]
Message-ID: <090115201912.ZM20275@torch.brasslantern.com> (raw)
In-Reply-To: <18796.17298.94642.461735@gargle.gargle.HOWL>

I was hoping to just let this thread go by, but maybe I'm the only one
still on list who's been around long enough to have an inkling of what
is going on here.

On Jan 13,  2:32am, Greg Klanderman wrote:
}
} I just don't understand why there should be any distinction
} between the splitting and dropping of empty strings.

It all goes back to the semantics of $@.

Here's bash:

$ set -- aa "" bb "" cc
$ echo $#
5
$ for x in $@; do echo $x; done
aa
bb
cc
$

Note that the empty elements of $@ are dropped.  Now, you might argue
that the *reason* they're dropped is because $@ has been joined into
a string and then re-split into words on $IFS, but the end result is
that empty elements disappear unless quoted.

Paul Falstad (original author of zsh) made a conscious decision that
a non-empty string, even one containing some or only characters that
appear in $IFS, was a significant item of data and should remain in
the expansion of $@.  However, he was unwilling to deviate from the
standard semantics of $@ to the point of treating empty strings as
significant.  Too many programs that deal with file names, for example,
would begin spewing errors if they received empty strings in their
argument lists when called as e.g. ls -l $@.

The point is to be minimally surprising to the person who just doesn't
want to think very hard about array and $IFS semantics, not to be
entirely logically consistent to someone who analyzes the behavior in
detail.  If you're enough of a geek to care, you're also enough of a
geek to figure out a workaround.

Everything else follows from there.  $a[@] is supposed to have the
same semantics as $@ for any array a; this must be, so that $argv[@]
is exactly equivalent to $@.

As to why things behave seemingly differently when using (s-:-) or
the like, well, in many cases zsh's parameter expansion was developed
looking only at the end results and not by paying close attention to
which "layer" of the implementation performed which operation.  As new
features were built on top of the implementation, particularly some of
the nested expansion tricks, unexpected oddities arose because that
layering became more important.  Some of those oddities became widely
enough relied on in scripts that we're now essentially stuck with them.

(Zsh is not one of "those" open source projects that is willing to
allow every new release to be "improved" by breaking everything that
went before.  For the most part, what has always worked still works,
and if it doesn't it's usually because it was never intended to work,
not because someone decided that the way it was once meant to work is
now philosophically wrong.)

The more literal explantion for your example has to do with multiple
consective separators being treated as a single word break (as happens
with, for example, multiple consecutive spaces when splitting on $IFS
in the shwordsplit case) vs. multiple separators being treated as
multiple word breaks.  However, I've forgotten whether rcexpandparam
was intentionally or accidentally given that side-effect.


  parent reply	other threads:[~2009-01-16  4:19 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-13  7:32 Greg Klanderman
2009-01-13 19:24 ` Peter Stephenson
2009-01-13 22:08   ` Peter Stephenson
2009-01-15 20:11     ` Greg Klanderman
2009-01-15 20:29       ` Peter Stephenson
2009-01-16 10:02         ` Peter Stephenson
2009-01-15 20:28     ` Greg Klanderman
2009-01-15 20:34       ` Peter Stephenson
2009-01-16  4:19 ` Bart Schaefer [this message]
2009-01-16 17:35   ` Greg Klanderman
2009-01-16 17:55     ` Peter Stephenson
2009-01-16 19:40       ` Greg Klanderman
2009-01-16 23:26         ` Richard Hartmann
2009-01-17  3:45         ` Bart Schaefer
2009-01-17  3:35     ` Bart Schaefer
2009-01-17  5:31       ` Greg Klanderman
2009-01-17 17:53         ` Peter Stephenson
2009-05-17  4:55 PATCH: make PROMPT_SP end-of-line marker configurable Greg Klanderman
2009-05-17 17:27 ` Peter Stephenson
2009-05-17 18:04   ` Greg Klanderman
2009-05-17 19:23     ` Peter Stephenson
2009-05-18  1:00       ` Greg Klanderman
2009-05-18 18:27       ` Greg Klanderman
     [not found] <gak@klanderman.net>
2009-06-26 20:40 ` bug in ztrftime(): '%e' and '%f' specifiers swapped Greg Klanderman
2009-06-26 21:23   ` Peter Stephenson
2009-06-26 21:57     ` Greg Klanderman
2010-02-05 17:01 have '&' automatically disown? Greg Klanderman
2010-02-05 17:33 ` Peter Stephenson
2010-02-05 17:36   ` Peter Stephenson
2010-02-06  3:26     ` Greg Klanderman
2010-02-07 18:20       ` Peter Stephenson
2010-02-07 21:06         ` Greg Klanderman
2010-02-07 21:34           ` Peter Stephenson
2010-02-07 22:36             ` Bart Schaefer
2010-09-02 14:57               ` Greg Klanderman
2010-09-05 19:11                 ` Bart Schaefer
2010-09-06  1:50                   ` Greg Klanderman
2010-02-07 21:59           ` Mikael Magnusson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=090115201912.ZM20275@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).