A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1161 ====================================================================== Reported By: steffen Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1161 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: steffen Organization: User Reference: Section: command Page Number: 2596 Line Number: 84274 ff. Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2017-09-04 13:09 UTC Last Modified: 2017-09-05 12:47 UTC ====================================================================== Summary: command -v must find something executable ======================================================================
---------------------------------------------------------------------- (0003827) kre (reporter) - 2017-09-05 12:47 http://austingroupbugs.net/view.php?id=1161#c3827 ---------------------------------------------------------------------- I understand that setuid for a shell is not common, and is usually a poor idea (the NetBSD sh also requires -p to allow it) but we have to give sane and consistent results in all cases, not just the common case. I am not trying to justify the behaviour of dash (and other *BSD derived shells, Chet gave me access to an original ash source, and I see it attempts to implement an executable check - but does it incorrectly - the changes to delete it must have been made as part of the integration into BSD when the incorrect executable tests were discovered. The NetBSD CVS repo shows several different methods attempted to make it work properly. eventually all simply removed.) My point is that it is very hard to do an executable test in any way other than by doing an exec() sys call - the kernel does all the correct tests (whatever is correct for it) attempting to duplicate that is difficult. If all you need is the 'x' bit in the flags, that is easy, but that does not make a file executable. Eg: some systems have extra ACLs that modify permission lookups, is the shell supposed to duplicate those tests as well? Of if you copy an executable file from an a.out sparc system to an ELF alpha, is that file executable on the alpha (it has the 'x' flag set, but exec() would fail, both because it is the wrong format, and the wrong architecture.) So, once again, if you are going to demand that "command -v" return only executable files, you need to define what it means to be "executable" for that purpose - and justify that definition. Ideally the result would be the name of the file that actually ends up being run when the shell executes the same command name, but without actually attempting the exec, or copying the local kernel's tests (all of them) into the shell, I see no way to achieve that. Are you suggesting that the shell do a fork/exec sequence for each potential name found from the PATH search, and then print the one that succeeds? If it does that, how does it reliably prevent the command run from doing anything, or does it also have to arrange to run it in ptrace() mode so it halts before executing any real code? This all just sounds too complicated to me - probably better to just leave it unspecified what happens to "command -v name" if "name" exists in a directory in $PATH but is not executable. Issue History Date Modified Username Field Change ====================================================================== 2017-09-04 13:09 steffen New Issue 2017-09-04 13:09 steffen Name => steffen 2017-09-04 13:09 steffen Section => command 2017-09-04 13:09 steffen Page Number => 2596 2017-09-04 13:09 steffen Line Number => 84274 ff. 2017-09-04 15:49 kre Note Added: 0003821 2017-09-05 06:58 stephane Note Added: 0003823 2017-09-05 08:30 stephane Note Added: 0003824 2017-09-05 12:34 steffen Note Added: 0003825 2017-09-05 12:39 steffen Note Added: 0003826 2017-09-05 12:47 kre Note Added: 0003827 ======================================================================
