Nicolas Neuss writes:
> Richard M Kreuter <kreuter@...> writes:
> > Does anybody have a special fondness for FIND-EXECUTABLE-IN-SEARCH-PATH?
> > It replicates the behavior of the standard function execvp(3), has some
> > #+/-win32 scars, implements an executable search that's subtly unlike
> > Unix's PATH searching behavior , and using it as we do causes us to
> > invoke different programs than the analogous routines in other languages
> > do .
> I have something like the following in my code:
> (defun find-executable (name)
> "Finds an executable in the current path."
> #-(or allegro cmu sbcl)
> (portability-warning 'find-executable name)
> #+allegro (excl.osi:find-in-path name)
> #+cmu (probe-file (pathname (concatenate 'string "path:" name)))
> #+sbcl (sb-ext:find-executable-in-search-path name)
> Is there a good alternative to F-E-I-S-P?
You could use the version of F-E-I-S-P in SBCL now, if you need it. I'm
somewhat doubtful that a program that relies on F-E-I-S-P doing
something entirely sensible, though .
However, if folks agree that we will use execvp/execv, I'm reluctant to
keep F-E-I-S-P in SBCL. Right now, F-E-I-S-P actually controls which
file we execute, but once we use execvp/execv, F-E-I-S-P won't control
anything, and so its result will amount to an educated but irrelevant
guess. So keeping it around will probably introduce subtler bugs than
the error people will get trying to call F-E-I-S-P.
Additionally, note that under my proposal to use execvp/execv, the
executable search will be done using the child process's PATH, rather
than SBCL's, and so calling F-E-I-S-P will one argument as you do above
won't work in all cases.
So I think it would be better to break SBCL's F-E-I-S-P once and for
all, if we use execvp/execv. If somebody still needs F-E-I-S-P, he can
get it from CVS, but then I hope it will be obvious that that F-E-I-S-P
has no real influence over anything.
(I hope it's uncontentious that using a system library routine itself is
preferable to emulating it in cases where the emulation is supposed to
do precisely what the library routine does, which is, I think, what
we're trying to do in RUN-PROGRAM.)
 Out of curiosity, what do your programs do with the result of
probing for an executable?
I've been spending a lot of time examining exceptional circumstances, so
my perspective is almost certainly warped, but ISTM that nothing other
than trying to run a program can truly tell you whether the program will
execute when you need it: the file system containing the executable
might be mounted noexec, or the executable might be busy, or corrupted,
or in the wrong format, or be for the wrong kind of machine, or an
interpreter might not be found, or the executable or its interpreter
might be dynamically linked and some of its dependencies aren't
loadable, or the calling process can't open any more files, or the user
is not permitted to create any more processes, or the operating system
is out of processes or memory, and so on. And in principle the file
system might be changing while your program runs (for all I know, your
programs run for weeks or months), with the consequence that the result
of an old probe no longer describes the operating system state
So if the reason you probe for an executable is that you want to ensure
that some external programs are present and in working order before
doing some expensive or destructive thing, ISTM that it would be more
effective to do your checking by running external programs with a
"--help" or "--usage" option. Doing so gives you more information --
whether the program actually runs -- and as a bonus affords the
opportunity to parse the help output, in case your program is sensitive
to, dependent on, or able to take advantage of the features of
particular variants of some external commands.
But even then, userland process can do nothing to completely ensure that
any particular exec call will succeed.