Date: Mon, 4 Jun 2001 00:52:57 +0100 (BST) From: Mark Valentine <mark@thuvia.demon.co.uk> To: seebs@plethora.net (Peter Seebach), hackers@freebsd.org Subject: Re: Fixing documented bug in env(1) Message-ID: <200106032352.f53Nqvn47341@dotar-sojat.thuvia.org> In-Reply-To: Peter Seebach's message of Jun 3, 10:46pm
next in thread | raw e-mail | index | archive | help
> From: seebs@plethora.net (Peter Seebach)
> Date: Sun 3 Jun, 2001
> Subject: Re: Fixing documented bug in env(1)
> >> However, what Dima proposes doesn't seem to be harmful, just slightly
> >> confusing, and less surprising than inventing a new delimieter such as
> >> ``==''.
>
> == is very confusing, and it's not the way anything else has ever done
> delimiters. "--" already means "change the way you process words". It's
> only marginally surprising to use it for another change.
Yes, I was (sort of) supporting ``--'' as an "end of assignment" delimiter
here; however, one more compatibility issue throws a spanner in the works...
Both ``--'' and ``=='' are valid commands, and currently only the former is
handled by env(1):
$ env foo=bar -- args
executes the command ``--''.
Dima's proposal would require this to change:
$ env foo=bar -- -- args
David's proposal would not break this, and would allow
$ env foo=bar == == args
to execute the command ``==''.
David's proposal only seems to break even more obscure (erroneous?) stuff
like:
$ env foo=bar == bar=foo command args
(Tell me that no script anywhere relies on this long-standing behaviour!)
Actually I don't like either solution much (if the documented bug were this
easy to fix, it would have been fixed decades ago...). Commands starting
with ``-'' already cause grief (e.g. in make(1)), and commands with ``=''
in their names almost certainly break in all sorts of other contexts
(e.g. when used unquoted in a Bourne shell).
(Do any shells still treat ``foo=bar'' as an assigment anywhere on the
command line?)
I'd leave the "bug" alone, pending real enlightenment...
By the way, who uses env(1) anyway? In the past twenty years, I've only
ever used it as shorthand for printenv(1). What's this csh(1) thing? :-)
Hmm, would a new csh(1) builtin help any?
/bin/sh:
$ foo=bar bar=foo echo hello
hello
$ foo=bar 'bar=foo' echo hello
bar=foo: not found
/bin/csh:
% env foo=bar bar=foo echo hello
hello
% env foo=bar 'bar=foo' echo hello
hello
% withenv foo=bar 'bar=foo' echo hello # new withenv(1) builtin
bar=foo: not found
(I'm not up on csh(1)'s foibles sufficiently to tell whether this would be
a done thing, but its syntax already seems fairly, erm, what's the polite
word?)
Cheers,
Mark.
--
Mark Valentine, Thuvia Labs <mark@thuvia.co.uk> <http://www.thuvia.co.uk>;
"Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses
"We're kind of stupid that way." *munch* *munch* and endorses FreeBSD
-- <http://www.calvinandhobbes.com>; <http://www.freebsd.org>;
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106032352.f53Nqvn47341>