Re: Fixing documented bug in env(1)
On Sat, Jun 02, 2001 at 02:03:38AM -0400, Garance A Drosihn wrote: It also strikes me that this might be another topic to send thru [EMAIL PROTECTED], as Posix might have something to say about what's appropriate. How much traffic does this list produce and how many people are on it? The first I heard of it's existance was a few days ago on one of the lists. May I propose that we make this an offical list so that it can be utilised by the wider community? Joe PGP signature
Re: Fixing documented bug in env(1)
On Tue, Jun 05, 2001 at 07:04:47PM +0100, Josef Karthauser wrote: On Sat, Jun 02, 2001 at 02:03:38AM -0400, Garance A Drosihn wrote: It also strikes me that this might be another topic to send thru [EMAIL PROTECTED], as Posix might have something to say about what's appropriate. How much traffic does this list produce and how many people are on it? The first I heard of it's existance was a few days ago on one of the lists. Not too much, wish it'd be higher. May I propose that we make this an offical list so that it can be utilised by the wider community? Bug wollman. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
At 7:04 PM +0100 6/5/01, Josef Karthauser wrote: On Sat, Jun 02, 2001, Garance A Drosihn wrote: It also strikes me that this might be another topic to send thru [EMAIL PROTECTED], as Posix might have something to say about what's appropriate. How much traffic does this list produce and how many people are on it? The first I heard of it's existance was a few days ago on one of the lists. May I propose that we make this an offical list so that it can be utilised by the wider community? Not much traffic. Not many people. It can be used by anyone who wants to join. I think Garrett originally proposed it as a @freebsd.org list, but it was felt that it wouldn't see enough traffic (and indeed, it has been very low-traffic). My only fear is that I might be encouraging its use for things it wasn't really meant for. It was mainly meant to talk about efforts to update freebsd to follow the various Posix standards, such as the latest Posix draft on how /usr/include libraries should be laid out. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
From: [EMAIL PROTECTED] (Mike Meyer) Date: Mon 4 Jun, 2001 Subject: Re: Fixing documented bug in env(1) #!/usr/bin/env foobar will work just fine. At the mercy of the user's path... Cheers, Mark. -- Mark Valentine, Thuvia Labs [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
Mark Valentine [EMAIL PROTECTED] types: From: [EMAIL PROTECTED] (Mike Meyer) Date: Mon 4 Jun, 2001 Subject: Re: Fixing documented bug in env(1) #!/usr/bin/env foobar will work just fine. At the mercy of the user's path... If you're really worried about that, do #!/usr/bin/env /usr/local/bin/foobar. That will also work where #!/usr/local/bin/foobar won't. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
Garance A Drosihn wrote: | At 9:12 PM -0700 6/1/01, Dima Dorfman wrote: | Honestly, I don't care about this all that much. I'll | let you and David debate this to your liking. If no | consensus develops in the next few days, I'll just | commit what I have now. | | For whatever it's worth, it seems more reasonable to me | to use '--' instead of '=='. Since '--' has NO equals | sign in it, it clearly can't be the setting of an | environment variable. If we're voting on this, I'm very strongly in favour of `--'. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Mon, Jun 04, 2001 at 12:49:43AM +1000, Greg Black wrote: | For whatever it's worth, it seems more reasonable to me | to use '--' instead of '=='. Since '--' has NO equals | sign in it, it clearly can't be the setting of an | environment variable. If we're voting on this, I'm very strongly in favour of `--'. Why? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
Mark you've given the justification and logic behind `==' much, much better than I did. Thanks! :-) -- -- David ([EMAIL PROTECTED]) P.S. typically I don't quote a whole message like this, but I think it is important that at least read this one and honestly consider it. On Sat, Jun 02, 2001 at 05:18:45PM +0100, Mark Valentine wrote: people use -- to end subsequences of arguments all the time. No, they use ``--'' to indicate to getopt(3) the end of the _options_ and the _start_ of the arguments. Since env(1) uses getopt(3), ``--'' already has meaning to env(1); it allows environment variables and commands which start with ``-'' (the former is obviously invalid). $ env -i -- -t args currently allows execution of command ``-t''. However, what Dima proposes doesn't seem to be harmful, just slightly confusing, and less surprising than inventing a new delimieter such as ``==''. $ env -i -- foo=bar -- 4=4 args has two distinct uses of `--'' as per Dima's proposal, the first tells getopt(3) to stop processing options, and the second tells the argument processing code to stop looking for variable assignments (i.e. ``4=4'' is a command). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
In message [EMAIL PROTECTED], David O'Brien writes: Mark you've given the justification and logic behind `==' much, much better than I did. Thanks! :-) And yet, he says: 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. $ env -i -- foo=bar -- 4=4 args has two distinct uses of `--'' as per Dima's proposal, the first tells getopt(3) to stop processing options, and the second tells the argument processing code to stop looking for variable assignments (i.e. ``4=4'' is a command). And this is fairly consistent. e.g., I used to have a utility which used '--' to indicate each *set* of options, so you could have many of them, as each set of options went to a different program. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
David O'Brien wrote: | On Mon, Jun 04, 2001 at 12:49:43AM +1000, Greg Black wrote: | | For whatever it's worth, it seems more reasonable to me | | to use '--' instead of '=='. Since '--' has NO equals | | sign in it, it clearly can't be the setting of an | | environment variable. | | If we're voting on this, I'm very strongly in favour of `--'. | | Why? The reasons have already been articulated. In brief, there is prior experience with using `--' as an indicator that argument processing is to change at this point; using it twice for the same purpose conflicts less with POLA than inventing the `==' thing, which has never been used for anything. The real reason for my post was that there was an indication that responses in favour of one or the other of the proposed mechanisms would be taken into account in the decision. I don't want to see this `==' idea get up. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
From: [EMAIL PROTECTED] (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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
In message [EMAIL PROTECTED], Mark Valentine w rites: 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): I doubt that anyone's using either, but it's a good point. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Sun, Jun 03, 2001 at 06:56:51PM -0500, Peter Seebach wrote: I doubt that anyone's using either, but it's a good point. '==' was/is part of the Bourne shell command line history stuff (*) a few people at UofSydney hacked together in the very early '80s, But you're right, very few people, if any, use it. -- Andy Newman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Mon, Jun 04, 2001 at 12:52:57AM +0100, Mark Valentine wrote: I'd leave the bug alone, pending real enlightenment... Me too. I've never met a command name with an = in it. 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? :-) How else do you throw away your environment, to make sure that daemons that you start with sudo don't do anything silly? I'm pretty sure that I copied this /etc/start_if.ed0 from somewhere, rather than making it up: env - PATH=$PATH dhclient ed0 It's also quite commonly used in /usr/local/etc/rc.d scripts, including qmail and courier-imap. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
From: Andrew Reilly [EMAIL PROTECTED]
Date: Mon 4 Jun, 2001
Subject: Re: Fixing documented bug in env(1)
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? :-)
How else do you throw away your environment, to make sure that
daemons that you start with sudo don't do anything silly?
env - PATH=$PATH dhclient ed0
Using env(1) without any assumtion about command line assignment parsing
purely as an illustration:
$ env - sh -c PATH=$PATH dhclient ed0
I'd probably wrap thus up in a script (or external program for ease of
use by various shells) - the semantics are subtly different from env(1):
$ clearenv() { env - sh -c $*; } # cheap and nasty to illustrate
$ clearenv PATH=$PATH dhclient ed0
Making clearenv(1) an external program (which doesn't itself parse command
line variable assignments) may simplify quoting, and if ``dhclient'' were
instead a shell builtin such as echo(1), you'd need to avoid the shortcut
above, as in:
$ clearenv PATH=$PATH; export PATH; dhclient ed0
Cheers,
Mark.
--
Mark Valentine, Thuvia Labs [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
$ clearenv() { env - sh -c $*; }# cheap and nasty to illustrate
Hmm, my point was as clear as mud there. I was trying to show that env -
performs a useful function, but a program which performs this function has
no need to duplicate the shell's ability to _assign_ environment variables.
Cheers,
Mark.
--
Mark Valentine, Thuvia Labs [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
Andrew Reilly [EMAIL PROTECTED] types: On Mon, Jun 04, 2001 at 12:52:57AM +0100, Mark Valentine wrote: 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? :-) How else do you throw away your environment, to make sure that daemons that you start with sudo don't do anything silly? I think it's more commonly used in scripts, so you don't have to worry about where the interpreter is installed. The python folks are recommending the user of #!/usr/bin/env python instead of #!/usr/local/bin/python for scripts, since the former works no matter where python is installed. I understand that some of the perl installation scripts use the same trick. Even cooler - at least as far as I'm concerned - is that you can do this if your interpreter is a script. That is, where #!/usr/local/bin/foobar won't work because foobar is a Perl script, #!/usr/bin/env foobar will work just fine. This is documented on the env man page, though I don't think it's been MFC'ed yet. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Sat, Jun 02, 2001 at 02:03:38AM -0400, Garance A Drosihn wrote:
At 9:12 PM -0700 6/1/01, Dima Dorfman wrote:
Honestly, I don't care about this all that much. I'll
let you and David debate this to your liking. If no
consensus develops in the next few days, I'll just
commit what I have now.
For whatever it's worth, it seems more reasonable to me
to use '--' instead of '=='. Since '--' has NO equals
sign in it, it clearly can't be the setting of an
environment variable.
It also strikes me that this might be another topic to
send thru [EMAIL PROTECTED], as Posix
might have something to say about what's appropriate.
..or at the very least to -arch.
FWIW, I, too, think that '--' would be a POLA-friendly choice.
However, if '==' were chosen, the patch to env.c would have to be
slightly modified, as attached.
G'luck,
Peter
--
This would easier understand fewer had omitted.
Index: env/env.c
===
RCS file: /home/ncvs/src/usr.bin/env/env.c,v
retrieving revision 1.5
diff -u -r1.5 env.c
--- env/env.c 1999/08/27 08:59:31 1.5
+++ env/env.c 2001/06/02 08:47:31
@@ -71,8 +71,13 @@
default:
usage();
}
- for (argv += optind; *argv (p = strchr(*argv, '=')); ++argv)
+ for (argv += optind; *argv (p = strchr(*argv, '=')); ++argv) {
+ if (!strcmp(*argv, ==)) {
+ argv++;
+ break;
+ }
(void)setenv(*argv, ++p, 1);
+ }
if (*argv) {
execvp(*argv, argv);
err(1, %s, *argv);
@@ -86,6 +91,6 @@
usage()
{
(void)fprintf(stderr,
- usage: env [-] [-i] [name=value ...] [command]\n);
+ usage: env [-] [-i] [name=value ...] [==] [command]\n);
exit(1);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Sat, 2 Jun 2001, Peter Pentchev wrote: FWIW, I, too, think that '--' would be a POLA-friendly choice. However, if '==' were chosen, the patch to env.c would have to be slightly modified, as attached. Yes, using '--' seems like a reasonable thing to do. Consistency with other uses of an 'argument that separates parts of the command line', etc. is one reason that I can easily come up with. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Thu, May 31, 2001 at 09:29:38PM -0700, Dima Dorfman wrote: Although this is a documented shortcoming, it's quite unnecessary given how easy it is to fix it. Any objections to allowing '--' to mean end of env. variable assignments? The orthoginal way (with grep, mv, et. al.) would be to use '==', not '--' as that is the problematic character. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
In message [EMAIL PROTECTED], David O'Brien writes: On Thu, May 31, 2001 at 09:29:38PM -0700, Dima Dorfman wrote: Although this is a documented shortcoming, it's quite unnecessary given how easy it is to fix it. Any objections to allowing '--' to mean end of env. variable assignments? The orthoginal way (with grep, mv, et. al.) would be to use '==', not '--' as that is the problematic character. Principle of least astonishment says that, sinec everyone else uses -- to indicate the end of a series of options, that's what env should do too. If you told users that there was a way to indicate the end of the option series, that's what they'd expect, because it's how all the other commands do it. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
[EMAIL PROTECTED] (Peter Seebach) writes: In message [EMAIL PROTECTED], David O'Brien writes: On Thu, May 31, 2001 at 09:29:38PM -0700, Dima Dorfman wrote: Although this is a documented shortcoming, it's quite unnecessary given how easy it is to fix it. Any objections to allowing '--' to mean end of env. variable assignments? The orthoginal way (with grep, mv, et. al.) would be to use '==', not '--' as that is the problematic character. Principle of least astonishment says that, sinec everyone else uses -- to indicate the end of a series of options, that's what env should do too. But this isn't terminating the end of a series of options; it's terminating a series of assignments, and since env(1) detemines whether an argument is an assignment or not by whether it has a '=' in it, it makes sense to use '==' as David suggests. It's different from the others because it signifies the end of a different kind of series. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
In message [EMAIL PROTECTED], Dima Dorfman write s: But this isn't terminating the end of a series of options; it's terminating a series of assignments, and since env(1) detemines whether an argument is an assignment or not by whether it has a '=' in it, it makes sense to use '==' as David suggests. No. The reason for -- is that it's two of the *START* of an option. env assignments don't *start* with =. The most consistent thing here is -- to separate parts of a command line. It's different from the others because it signifies the end of a different kind of series. Sure, but the user doesn't necessarily care. Certainly, no one has ever tried to use == to end any sequence of arguments anywhere; people use -- to end subsequences of arguments all the time. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
Honestly, I don't care about this all that much. I'll let you and David debate this to your liking. If no consensus develops in the next few days, I'll just commit what I have now. (Obviously, if consensus does develop I'll go along with it.) Thanks, Dima Dorfman [EMAIL PROTECTED] [EMAIL PROTECTED] (Peter Seebach) writes: In message [EMAIL PROTECTED], Dima Dorfman writes: But this isn't terminating the end of a series of options; it's terminating a series of assignments, and since env(1) detemines whether an argument is an assignment or not by whether it has a '=' in it, it makes sense to use '==' as David suggests. No. The reason for -- is that it's two of the *START* of an option. env assignments don't *start* with =. The most consistent thing here is -- to separate parts of a command line. It's different from the others because it signifies the end of a different kind of series. Sure, but the user doesn't necessarily care. Certainly, no one has ever tried to use == to end any sequence of arguments anywhere; people use -- to end subsequences of arguments all the time. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
At 9:12 PM -0700 6/1/01, Dima Dorfman wrote: Honestly, I don't care about this all that much. I'll let you and David debate this to your liking. If no consensus develops in the next few days, I'll just commit what I have now. For whatever it's worth, it seems more reasonable to me to use '--' instead of '=='. Since '--' has NO equals sign in it, it clearly can't be the setting of an environment variable. It also strikes me that this might be another topic to send thru [EMAIL PROTECTED], as Posix might have something to say about what's appropriate. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Fixing documented bug in env(1)
Hi folks,
Right now, env(1) can't be used to run programs with an equals sign in
them for obvious reasons (if it isn't obvious, read the man page :-).
Although this is a documented shortcoming, it's quite unnecessary
given how easy it is to fix it. Any objections to allowing '--' to
mean end of env. variable assignments?
Patch attached below.
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: env/env.c
===
RCS file: /stl/src/FreeBSD/src/usr.bin/env/env.c,v
retrieving revision 1.5
diff -u -r1.5 env.c
--- env/env.c 1999/08/27 08:59:31 1.5
+++ env/env.c 2001/06/01 04:27:41
@@ -73,6 +73,8 @@
}
for (argv += optind; *argv (p = strchr(*argv, '=')); ++argv)
(void)setenv(*argv, ++p, 1);
+ if (*argv strcmp(*argv, --) == 0)
+ ++argv;
if (*argv) {
execvp(*argv, argv);
err(1, %s, *argv);
@@ -86,6 +88,6 @@
usage()
{
(void)fprintf(stderr,
- usage: env [-] [-i] [name=value ...] [command]\n);
+ usage: env [-] [-i] [name=value ...] [--] [command]\n);
exit(1);
}
Index: printenv/printenv.1
===
RCS file: /stl/src/FreeBSD/src/usr.bin/printenv/printenv.1,v
retrieving revision 1.10
diff -u -r1.10 printenv.1
--- printenv/printenv.1 2001/05/30 03:15:39 1.10
+++ printenv/printenv.1 2001/06/01 04:27:41
@@ -34,7 +34,7 @@
.\@(#)printenv.1 8.1 (Berkeley) 6/6/93
.\ $FreeBSD: src/usr.bin/printenv/printenv.1,v 1.10 2001/05/30 03:15:39 dd Exp $
.\
-.Dd June 6, 1993
+.Dd May 29, 2001
.Dt PRINTENV 1
.Os BSD 3
.Sh NAME
@@ -47,6 +47,7 @@
.Op Fl
.Op Fl i
.Op Ar name=value ...\
+.Op --
.Op Ar command
.Sh DESCRIPTION
.Nm Printenv
@@ -80,6 +81,18 @@
.Ar name ,
with a value of
.Ar value .
+If the argument
+.Ql --
+is found,
+.Nm env
+will assume that the argument(s) following it are part of
+.Ar command ,
+instead of
+.Ar name=value
+pairs,
+even if they have the
+.Ql =
+symbol in them.
.Pp
The options are as follows:
.Bl -tag -width indent
@@ -130,7 +143,3 @@
.Nm
command appeared in
.Bx 3.0 .
-.Sh BUGS
-.Nm Env
-doesn't handle commands with equal (``='') signs in their
-names, for obvious reasons.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
