>Why should shell scripts be different than C programs. You don't >need read permission to execute a C program so you shouldn't >need it to execute a shell script.
Clearly it's an implementation artefact which has existed forever and there don't seem to be compelling reasons to fix it. (A fix will also require us to disable the ability to truss such a process or attach a debugger to it) >> (This is compounded by the fact that the kernel may not be able >> to determine how to open execute only scripts; but a set-uid root >> helper program would get into trouble even more quickly as it is >> certain to fail over NFS) >At the kernel level, shouldn't it can bypass ordinary file file >permissions or temporarily do a setuid root to open the file. Unfortunately, that is not guaranteed to work in the case of network filesystems; but generally, such filesystem either do not distinguish between read and execute access as both casue the same over the wire operation or they can be made to do so. >> Could ksh93 use /proc/self/path/$(basename $0) in error messages >> rather than /dev/fd/X? >The shell tried to change $0 when it encounters /dev/fd/X but the >method depends on the system. The link to /proc/self/exe gives >the pathname for the interpreter, not the script. In Solaris 10, the symlink /proc/self/path/$(basename $0) (e.g., /proc/self/fd/3 if the script is opened as /dev/fd/3) will give the script name. >It would be nice of for ps, #! displayed the name of the script >rather than the name of the interpreter. Depends on what you want ps to display; Solaris ps can display 4 things: the command (the name of the executable), the "fname" (name of the script) or the argument list (shell scriptname [arg ...]) Casper
