* status codes on Dec OSF [not found] <1000304181244.ZM24879@candle.brasslantern.com> @ 2001-06-21 21:46 ` Brian Harvell 2001-06-22 6:01 ` Andrej Borsenkow 2001-06-22 7:03 ` status codes on Dec OSF Sven Wischnowsky 0 siblings, 2 replies; 9+ messages in thread From: Brian Harvell @ 2001-06-21 21:46 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: status codes on Dec OSF 2001-06-21 21:46 ` status codes on Dec OSF Brian Harvell @ 2001-06-22 6:01 ` Andrej Borsenkow 2001-06-23 3:49 ` PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF) Bart Schaefer 2001-06-22 7:03 ` status codes on Dec OSF Sven Wischnowsky 1 sibling, 1 reply; 9+ messages in thread From: Andrej Borsenkow @ 2001-06-22 6:01 UTC (permalink / raw) To: Brian Harvell, zsh-workers > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF) 2001-06-22 6:01 ` Andrej Borsenkow @ 2001-06-23 3:49 ` Bart Schaefer 2001-06-23 18:22 ` Bart Schaefer 0 siblings, 1 reply; 9+ messages in thread From: Bart Schaefer @ 2001-06-23 3:49 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF) 2001-06-23 3:49 ` PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF) Bart Schaefer @ 2001-06-23 18:22 ` Bart Schaefer 2001-06-25 5:57 ` Andrej Borsenkow 0 siblings, 1 reply; 9+ messages in thread From: Bart Schaefer @ 2001-06-23 18:22 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF) 2001-06-23 18:22 ` Bart Schaefer @ 2001-06-25 5:57 ` Andrej Borsenkow 2001-06-27 7:15 ` Andrej Borsenkow 0 siblings, 1 reply; 9+ messages in thread From: Andrej Borsenkow @ 2001-06-25 5:57 UTC (permalink / raw) To: zsh-workers > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF) 2001-06-25 5:57 ` Andrej Borsenkow @ 2001-06-27 7:15 ` Andrej Borsenkow 2001-06-27 7:46 ` Bart Schaefer 0 siblings, 1 reply; 9+ messages in thread From: Andrej Borsenkow @ 2001-06-27 7:15 UTC (permalink / raw) To: Andrej Borsenkow, zsh-workers > > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF) 2001-06-27 7:15 ` Andrej Borsenkow @ 2001-06-27 7:46 ` Bart Schaefer 2001-06-27 13:02 ` Brian Harvell 0 siblings, 1 reply; 9+ messages in thread From: Bart Schaefer @ 2001-06-27 7:46 UTC (permalink / raw) To: Andrej Borsenkow, zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF) 2001-06-27 7:46 ` Bart Schaefer @ 2001-06-27 13:02 ` Brian Harvell 0 siblings, 0 replies; 9+ messages in thread From: Brian Harvell @ 2001-06-27 13:02 UTC (permalink / raw) To: Bart Schaefer; +Cc: Andrej Borsenkow, zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: status codes on Dec OSF 2001-06-21 21:46 ` status codes on Dec OSF Brian Harvell 2001-06-22 6:01 ` Andrej Borsenkow @ 2001-06-22 7:03 ` Sven Wischnowsky 1 sibling, 0 replies; 9+ messages in thread From: Sven Wischnowsky @ 2001-06-22 7:03 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2001-06-27 13:03 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1000304181244.ZM24879@candle.brasslantern.com> 2001-06-21 21:46 ` status codes on Dec OSF Brian Harvell 2001-06-22 6:01 ` Andrej Borsenkow 2001-06-23 3:49 ` PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF) Bart Schaefer 2001-06-23 18:22 ` Bart Schaefer 2001-06-25 5:57 ` Andrej Borsenkow 2001-06-27 7:15 ` Andrej Borsenkow 2001-06-27 7:46 ` Bart Schaefer 2001-06-27 13:02 ` Brian Harvell 2001-06-22 7:03 ` status codes on Dec OSF Sven Wischnowsky
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).