status codes on Dec OSF

status codes on Dec OSF

[Brian Harvell]

The following script produces different results when run on a dec machine vs
a solaris machine. It seems the dec doesn't see the status code of the command
if your setting the output to a varible.

%cat foo
FOO=`jfkljfs`
echo $?
FOO=`pwd`
echo $?

jfkljfs
echo $?
pwd
echo $?


>From the dec 4.0F machine
% /opt/bcs/packages/zsh-4.0.1/bin/zsh -x foo
+foo:1> FOO=+foo:1> jfkljfs
foo:1: command not found: jfkljfs
+foo:1> FOO=
+foo:2> echo 0
0
+foo:3> FOO=+foo:3> pwd
+foo:3> FOO=/usr/users/harvell/zsh-4.0.1
+foo:4> echo 0
0
+foo:6> jfkljfs
foo:6: command not found: jfkljfs
+foo:7> echo 1
1
+foo:8> pwd
/usr/users/harvell/zsh-4.0.1
+foo:9> echo 0
0

>From the solaris 2.7 machine
% /opt/bcs/packages/zsh-4.0.1/bin/zsh -x foo
+foo:1> FOO=+foo:1> jfkljfs
foo:1: command not found: jfkljfs
+foo:1> FOO=
+foo:2> echo 1
1
+foo:3> FOO=+foo:3> pwd
+foo:3> FOO=/data/cvs/bcs/SOURCES/zsh-4.0.1
+foo:4> echo 0
0
+foo:6> jfkljfs
foo:6: command not found: jfkljfs
+foo:7> echo 1
1
+foo:8> pwd
/data/cvs/web-inf/bcs/SOURCES/zsh-4.0.1
+foo:9> echo 0
0



-- 

Brian Harvell                harvell@aol.net             http://ToolBoy.com/
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

RE: status codes on Dec OSF

[Andrej Borsenkow]

>
> The following script produces different results when run on a dec
> machine vs
> a solaris machine. It seems the dec doesn't see the status code
> of the command
> if your setting the output to a varible.
>
> %cat foo
> FOO=`jfkljfs`
> echo $?
> FOO=`pwd`
> echo $?
>
> jfkljfs
> echo $?
> pwd
> echo $?
>
>
> >From the dec 4.0F machine
> % /opt/bcs/packages/zsh-4.0.1/bin/zsh -x foo
> +foo:1> FOO=+foo:1> jfkljfs
> foo:1: command not found: jfkljfs
> +foo:1> FOO=
> +foo:2> echo 0
> 0


Sigh, this is a bug :-(

If there is a command name, execution will continue as described in Command
Search and Execution . If there is no command name, but the command
contained a command substitution, the command will complete with the exit
status of the last command substitution performed. Otherwise, the command
will complete with a zero exit status.


 Actually, zsh has long standing POSIX incompatibility w.r.t. exit codes; I
am not sure how diffecult it is to change it:

If a command is not found, the exit status will be 127. If the command name
is found, but it is not an executable utility, the exit status will be 126.
Applications that invoke utilities without using the shell should use these
exit status values to report similar errors.

-andrej

PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)

[Bart Schaefer]

On Jun 22, 10:01am, Andrej Borsenkow wrote:
} Subject: RE: status codes on Dec OSF
}
} > >From the dec 4.0F machine
} > % /opt/bcs/packages/zsh-4.0.1/bin/zsh -x foo
} > +foo:1> FOO=+foo:1> jfkljfs
} > foo:1: command not found: jfkljfs
} > +foo:1> FOO=
} > +foo:2> echo 0
} > 0
} 
} 
} Sigh, this is a bug :-(

It's a bug on a particular operating system, and one which Sven was not
able to reproduce.

I'm made suspicious by "/opt/bcs/" in the command name.  That smells of
"binary compatibility standard" to me -- which could mean that zsh was
not compiled for the operating system under which it is executing.

Apparently quoting from the POSIX standard, Andrej goes on:
 
} If there is a command name, execution will continue as described in Command
} Search and Execution . If there is no command name, but the command
} contained a command substitution, the command will complete with the exit
} status of the last command substitution performed. Otherwise, the command
} will complete with a zero exit status.
} 
} If a command is not found, the exit status will be 127. If the command name
} is found, but it is not an executable utility, the exit status will be 126.
} Applications that invoke utilities without using the shell should use these
} exit status values to report similar errors.

Zsh already conforms to the first paragraph (or at least attempts to); the
patch below deals with the second paragraph.  Sample output:

zagzig% foo=`stamp-h`
zsh: command not found: stamp-h
zagzig% echo $?
127
zagzig% foo=`./stamp-h`
zsh: permission denied: ./stamp-h
zagzig% echo $?        
126
zagzig% echo foo=`./stamp-h`
zsh: permission denied: ./stamp-h
foo=
zagzig% echo $?
0

Is there any possibility that anyone is relying explicitly upon (($? == 1))
as was formerly the case for both command-not-found and permission-denied?

--- zsh-forge/current/Src/exec.c	Wed Jun 20 08:57:01 2001
+++ zsh-4.0/Src/exec.c	Fri Jun 22 20:04:31 2001
@@ -502,7 +502,7 @@
 		(arg0[0] == '.' && (arg0 + 1 == s ||
 				    (arg0[1] == '.' && arg0 + 2 == s)))) {
 		zerr("%e: %s", arg0, errno);
-		_exit(1);
+		_exit(errno == EACCES ? 126 : 127);
 	    }
 	    break;
 	}
@@ -556,7 +556,7 @@
 	zerr("%e: %s", arg0, eno);
     else
 	zerr("command not found: %s", arg0, 0);
-    _exit(1);
+    _exit(eno == EACCES ? 126 : 127);
 }
 
 #define RET_IF_COM(X) { if (iscom(X)) return docopy ? dupstring(X) : arg0; }

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)

[Bart Schaefer]

On Jun 23,  3:49am, Bart Schaefer wrote:
}
} Apparently quoting from the POSIX standard, Andrej goes on:
}  
} } If a command is not found, the exit status will be 127. If the command name
} } is found, but it is not an executable utility, the exit status will be 126.
} } Applications that invoke utilities without using the shell should use these
} } exit status values to report similar errors.
} 
} +		_exit(errno == EACCES ? 126 : 127);

Upon reflection, I think that should test ENOEXEC as well; bash behaves
that way.  I'll make that change when I commit the patch.

However, in comparing with bash I found a discrepancy, and I'm not sure
which interpretation is the correct one.  Consider a shell script that
begins with:

	#! /this/does/not/exist

Attempting to execute such a script in bash gives a 126 exit status.  In
zsh with my patch applied, the status is 127 -- because the command in
the #! line is, in fact, not found.

If the script is executed directly by its full path, both shells print
"no such file".  If the script is executed via a path search, however,
zsh actually does print "command not found", while bash still says "no
such file".

This is because zsh believes execve() when it sets errno to ENOENT,
whereas bash explicitly stat()s the file before attempting to execute it
and returns 126 if it exists, regardless of the errno set by execve(),
even though the error message it prints is the one from execve().

There is another effect of this:  If there are two files in the path with
the same name, bash will always attempt to execute the first one and fail
with 126/"no such file", but zsh will keep searching and either execute
the second one or report 127/"command not found".

It would be somewhat convoluted to retain that path-search behavior yet
still manage to exit with 126 when there is at least one file in the path
that *might* have been executable.  It would be possible to get the bash
behavior for direct execution by addition of a single stat(), but then
the same script fails with different values depending on how you invoke
it -- and this gets even more confusing if PATH_DIRS is set.

Does anyone think that (a) zsh's path search behavior is a problem, or
(b) that it's important to return 126 in this circumstance?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)

[Andrej Borsenkow]

>
> This is because zsh believes execve() when it sets errno to ENOENT,
> whereas bash explicitly stat()s the file before attempting to execute it
> and returns 126 if it exists, regardless of the errno set by execve(),
> even though the error message it prints is the one from execve().
>

Well, quoting standards again:

Otherwise, the shell will execute the utility in a separate utility
environment (see Shell Execution Environment ) with actions equivalent to
calling the XSH specification execve() function with the path argument set
to the pathname resulting from the search, arg0 set to the command name, and
the remaining arguments set to the operands, if any.
If the execve() function fails due to an error equivalent to the XSH
specification error [ENOEXEC], the shell will execute a command equivalent
to having a shell invoked with the command name as its first operand, along
with any remaining arguments passed along. If the executable file is not a
text file, the shell may bypass this command execution, write an error
message, and return an exit status of 126.

Which means, that strictly speaking both sh and zsh are conform. Shell may
believe execve or may try to directly execute the command. So, it is a
matter of bash/zsh compatibility. I would ignore it.

> There is another effect of this:  If there are two files in the path with
> the same name, bash will always attempt to execute the first one and fail
> with 126/"no such file", but zsh will keep searching and either execute
> the second one or report 127/"command not found".
>

I guess, zsh's behaviour is more appropriate:

[PATH search]
The list is searched from beginning to end, applying the filename to each
prefix, until an executable file with the specified name and appropriate
execution permissions is found.

> It would be somewhat convoluted to retain that path-search behavior yet
> still manage to exit with 126 when there is at least one file in the path
> that *might* have been executable.  It would be possible to get the bash
> behavior for direct execution by addition of a single stat(), but then
> the same script fails with different values depending on how you invoke
> it -- and this gets even more confusing if PATH_DIRS is set.
>
> Does anyone think that (a) zsh's path search behavior is a problem, or
> (b) that it's important to return 126 in this circumstance?
>

No in both cases. I would presume, that in case of path search 126 is not
possible at all.

-andrej

RE: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)

[Andrej Borsenkow]

>
> > There is another effect of this:  If there are two files in the
> path with
> > the same name, bash will always attempt to execute the first
> one and fail
> > with 126/"no such file", but zsh will keep searching and either execute
> > the second one or report 127/"command not found".
> >
>
> I guess, zsh's behaviour is more appropriate:
>
> [PATH search]
> The list is searched from beginning to end, applying the filename to each
> prefix, until an executable file with the specified name and appropriate
> execution permissions is found.
>

On the second thought, may be zsh is wrong here. It depends on the
definition of "appropriate execution permissions".  It may be understood as
"if file can be executed" (what zsh does currently). But I suspect, that it
actually meant "stat.st_mode & (S_IXUSR|S_IXGRP|S_IXOTHR)". I.e. file with
any executable bit set.

Current zsh behaviour may lead to unexpected (inappropriate) command
execution. Consider:

bor@itsrm2% ll /usr/sbin/pkgadd
-rwx------   1 root     sys       397793 Nov 18  1998 /usr/sbin/pkgadd*
bor@itsrm2% pkgadd
zsh: permission denied: pkgadd
bor@itsrm2% cat > ~/bin/pkgadd
#! /bin/sh

echo Pkgadd here!
bor@itsrm2% chmod +x ~/bin/pkgadd
bor@itsrm2% pkgadd
Pkgadd here!
bor@itsrm2% print $path
/tools/override/bin /usr/bin /usr/sbin /opt/bin /usr/ccs/bin /usr/ucb
/tools/bin /opt/nsr /usr/dt/bin /usr/bin/X11 /opt/xms/bin /opt/xms-menu/bin
/opt/Xprint/cmd /opt/Xprint/mercator/cmd /opt/lib/tele/bin /u1/nerv/bin
/home/bor/bin
bor@itsrm2% ll =pkgadd
-rwxr-xr-x   1 bor      sinix         30 Jun 27 11:11 /home/bor/bin/pkgadd*

Any real reasons to retain current zsh exaustive path search?

-andrej

Re: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)

[Bart Schaefer]

On Jun 27, 11:15am, Andrej Borsenkow wrote:
}
} Any real reasons to retain current zsh exaustive path search?

Aside from the fact that I happen to find that behavior useful, one of
the reasons that zsh works that way is because it's presumably more
efficient to simply let the kernel decide whether it can execve() any
given path than it is for the shell to stat() it first; no need to
waste time copying all that inode data into user space, etc.

} It depends on the definition of "appropriate execution permissions".
} It may be understood as "if file can be executed" (what zsh does
} currently). But I suspect, that it actually meant "stat.st_mode &
} (S_IXUSR|S_IXGRP|S_IXOTHR)". I.e. file with any executable bit set.

Or it may mean a file with execute bits set such that it's executable
by the current user.  Is there no way to tell?

I think the question should always be "Any real reason to change the
current behavior?"  So far I think not.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)

[Brian Harvell]

On Wed, 27 Jun 2001, Bart Schaefer wrote:

>
> I think the question should always be "Any real reason to change the
> current behavior?"  So far I think not.
>

You could make the security argument since it's like having '.' at the front
of your path. If there was some bug found that would let a user change the
inode data of a file but not overwrite the file they could remove execute bits
to something like ls and put their own somewhere else.

I know that's far fetched but it might be nice to make it an option if it's not
that difficult.

Brian



-- 

Brian Harvell                harvell@aol.net             http://ToolBoy.com/
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

Re: status codes on Dec OSF

[Sven Wischnowsky]

Brian Harvell wrote:

> The following script produces different results when run on a dec machine vs
> a solaris machine. It seems the dec doesn't see the status code of the command
> if your setting the output to a varible.

Hrm.  I have a DEC Alpha with OSF 4.0f, too, but it works for me
(with the current cvs version, but I don't think any of the recent
changes would have any effect on this):

+foo:1> FOO=+foo:1> jfkljfs
foo:1: command not found: jfkljfs
+foo:1> FOO=
+foo:2> echo 1
1
+foo:3> FOO=+foo:3> pwd
+foo:3> FOO=/home/wischnow/zsh/z/Src/ff
+foo:4> echo 0
0
+foo:6> jfkljfs
foo:6: command not found: jfkljfs
+foo:7> echo 1
1
+foo:8> pwd
/home/wischnow/zsh/z/Src/ff
+foo:9> echo 0
0


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de