On Thu, Jul 22, 2010 at 6:15 PM, Jason McIntyre <j...@kerhand.co.uk> wrote:
> On Thu, Jul 22, 2010 at 05:38:29PM -0400, Daniel Dickman wrote:
>>
>> I think the man page is bit confusing. Note that I sent jmc@ the patch
>> below for the man page to try to clear things up a bit there as well. The
>> main point is that 1-125 is an error range reserved for any errors that
>> happens within env itself.
>>
>> However the entire range of exit codes is _REUSED_ in the case that
>> utility was (1) specified, (2) successfully located and (3) succesfully
>> invoked. In that case, the return code from env is whatever the underlying
>> utility returns.
>>
>> But as I said, any errors in env itself (as opposed to the underlying
>> utility) should be in the range 1-125 (at least that's my reading of
>> posix).
>>
>
> i don;t understand this, but then i don;t know *exactly* what the code
> does. but i don;t see why you find that section confusing.
>
> why do you say that 1-125 is reserved by env and that env is reusing
> them? as documented, you just get the return value from the utility.

sure. let me try. the problem is that right now i think env on OpenBSD
can return 4 ambiguous values: 0, 1, 126, 127. if any of these values
are returned i don't think it's possible to know if the value was
returned from env itself or from the underlying utility. (and in fact
according to what posix specifies, there really isn't any way to
portably determine if *any* return value came from env or from the
underlying utility.)

the second problem, is that according to (my reading of posix)
something that uses env will expect a return value in the range of
1-125 to mean "something went wrong in env" and 126 to mean "something
went wrong with invoking utility". but at the moment there are 2
places in the code where 126 is returned where something went wrong in
env.

i'm hoping to try to make the man pages clearer about what
circumstances lead to what error codes and to spell out the
ambiguities a bit more clearly.

i also understand ingo's complaint about not wanting to introduce a
fifth ambiguous return value (125). maybe the solution is to return 1
instead of 126 which is already an ambiguous value instead of what i
proposed earlier? That way, you limit the ambiguous values and yet
still comply with (again, my reading) of posix.

>
>> In particular, think about the case when utility is not specified at all.
>> I don't think it would make sense to return 126 in that case.
>
> as documented, in that case it returns 0.

that's what's documented but i'm not sure that's what happens. if you
run "env -i", for example and the call to "calloc" on line 56 fails,
it looks to me like env will return 126 at the moment not 0.

>
>>
>> Unfortunately, the exit codes are already ambiguous. What happens when 1
>> is returned? Was this from the underlying utility that exited with return
>> code 1 or did I specify something incorrectly on the command-line? (Note
>> my addition to the BUGS section in my patch below).
>>
>> B  # cat ./test.sh
>> B  #!/bin/sh
>> B  exit 1
>> B  # env ./test.sh
>> B  # echo $?
>> B  1
>
> utility (test.sh) returns 1
>
>> B  # env -t
>> B  env: unknown option -- t
>> B  usage: env [-i] [name=value ...] [utility [argument ...]]
>> B  # echo $?
>> B  1
>>
>
> env returns 1
>
>> In any case, patch to env.1 man page follows as well in case you have some
>> feedback there as well.
>>
>
> i think we should understand why you find the text in env confusing
> first, then see if there really is a problem.
>
> jmc
>
>>
>> Index: env.1
>> ===================================================================
>> RCS file: /usr/cvs/src/usr.bin/env/env.1,v
>> retrieving revision 1.17
>> diff -u -r1.17 env.1
>> --- env.1 B  B  8 Feb 2009 17:15:09 -0000 B  B  B  1.17
>> +++ env.1 B  B  22 Jul 2010 20:30:20 -0000
>> @@ -76,27 +76,25 @@
>> B of the variables in the environment, with one
>> B .Ar name Ns = Ns Ar value
>> B pair per line.
>> -.Sh DIAGNOSTICS
>> +.Pp
>> +If
>> +.Ar utility
>> +is specified and was successfully invoked, the exit code returned by
>> B .Nm
>> -exits with one of the following values:
>> -.Bl -tag -width Ds
>> +is the exit code of
>> +.Ar utility .
>> +.Pp
>> +Otherwise, the
>> +.Nm
>> +utility exits with one of the following values:
>> +.Bl -tag -width Ds -compact -offset indent
>> B .It 0
>> -.Ar utility
>> -was invoked and completed successfully.
>> -In this case the exit code is returned by the utility itself, not
>> -.Nm .
>> -If no utility was specified, then
>> -.Nm
>> -completed successfully and returned the exit code itself.
>> -.It 1
>> -An invalid command line option was passed to
>> -.Nm .
>> +.Nm
>> +completed successfully.
>> B .It 1\(en125
>> -.Ar utility
>> -was invoked but failed in some way;
>> -see its manual page for more information.
>> -In this case the exit code is returned by the utility itself, not
>> -.Nm .
>> +An error occurred in the
>> +.Nm
>> +utility.
>> B .It 126
>> B .Ar utility
>> B was found but could not be invoked.
>> @@ -123,3 +121,8 @@
>> B .Pq Sq =
>> B signs in their
>> B names, for obvious reasons.
>> +.Pp
>> +There is no way to determine whether an exit code was returned by
>> +.Nm
>> +or by the underlying
>> +.Ar utility .

Reply via email to