Stephen Gildea wrote:
> Using the "local" command to do variable assignment should not do word
> splitting.

Please note that this feature was in dash for some time, but was then
removed.

See Changelog.O in the dash source tree:
On Sun, 23 Nov 1997 12:45:15 +1100, ash 0.3.1-14:
  * Disabled word-splitting for assignment builtins.
On Mon, 24 Nov 1997 16:19:10 +1100:
  * Fixed incorrect assignment builtin code.
On Sun, 15 Jul 2001 17:27:03 +1000, ash 0.3.8-15:
  * Removed assignment builtins since it is at best undefined by the SuS and
    also can't be implemented consistently.

Unfortunately, neither the dash git repository nor the dash mailing list
archives I can find go back that old.

When the "treat words that look like assignments specially" behaviour
triggers exactly differs between shells that implement it.

In ksh93 it is fairly consistent: all builtins it applies to are
special, so that when a word looks like such a builtin it is one. (ksh93
doesn't have "local", its "alias" is special, different from what POSIX
requires, and its extension "typeset" is also special.) The command word
may contain quoting but no expansions to be a candidate for this special
treatment.

In bash and mksh, it applies to various non-special builtins that can at
least be overridden with a function. The special behaviour does not
depend on whether the actual builtin is going to be called, or a
user-defined function. The command word must be the literal builtin, no
quoting or expansions are permitted.

Some versions of bash and zsh, configured with certain options, apply
the special casing to all words that look like assignments.

Another effect of the special casing is that tilde expansion is
performed in cases like
  export PATH=foo:~/bin:bar

I agree with the other post that POSIX does not require this behaviour,
and might even prohibit it; the prohibition is probably not intended,
though, and it seems unlikely to me the standard will be changed to
prohibit it -- that would break more than it fixes.

-- 
Jilles Tjoelker



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to