Re: Default PATH for executing external programs

[Philip Nienhuis]

John W. Eaton wrote
> Currently, Octave sets the PATH for searching for executable programs
> to be the user's PATH followed by Other directories under OCTAVE_HOME
> that may also contain programs to execute.  By setting things this
> way, we may end up executing the wrong version of mkoctfile (for
> example).  Octave's mkoctfile function takes care of this by
> explicitly executing the copy of the external mkoctfile program found
> in Octave's $bindir, but that is not done when executing the external
> mkoctfile program using "pkg install" because "pkg install" just
> executes Make, and there is no way to know how the package Makefiles
> will execute mkoctfile.
> 
> There was a bug report about this issue for Windows:
> 
>    https://savannah.gnu.org/bugs/?func=detailitem&item_id=43164
> 
> The solution was to prepend Octave's $bindir to the user's PATH before
> starting Octave.  That works, but shouldn't Octave be doing this
> itself?

(Actually, you stirr up two separate but related issues: polluted PATHs and
"pkg" command robustness)

At least on Windows, I think Octave rather shouldn't put its bin subdir
after the current PATH. On my local 3.8.0 (MinGW) installation, started with
this shortcut:

X:\Octave\Octave-3.8.0\bin\octave-gui.exe

...Octave gets to work in an environment with this PATH:

>> strsplit (getenv ("PATH"), pathsep)
ans =
{
  [1,1] = C:\Programs\Python33\
  [1,2] = C:\WINDOWS\system32
  [1,3] = C:\WINDOWS
  [1,4] = C:\WINDOWS\System32\Wbem
  [1,5] = C:\Programs\TortoiseSVN\bin
  [1,6] = C:\Programs\gs\gs9.04\bin
  [1,7] = C:\Programs\QuickTime\QTSystem\
  [1,8] = C:\Programs\Mercurial
  [1,9] = C:\Programs\VMware\VMware View\Client\bin
  [1,10] = X:\Octave\Octave-3.8.0\bin
  [1,11] = X:\Octave\Octave-3.8.0\notepad++
  [1,12] =
X:\Octave\Octave-3.8.0\libexec\octave\3.8.0\site\exec\i686-pc-mingw32
  [1,13] =
X:\Octave\Octave-3.8.0\libexec\octave\api-v49+\site\exec\i686-pc-mingw32
  [1,14] = X:\Octave\Octave-3.8.0\libexec\octave\site\exec\i686-pc-mingw32
  [1,15] = X:\Octave\Octave-3.8.0\libexec\octave\3.8.0\exec\i686-pc-mingw32
  [1,16] = X:\Octave\Octave-3.8.0\bin
}
>>

from where one can see that Octave's bindir has been added twice to the
PATH.

Now I'm usually quite careful on my own systems, but especially unsuspecting
if not ignorant Windows users can have PATHs badly polluted by sloppily
written Windows applications. 
("sloppily written" = my judgement of programs that silently put their own
path-to-executables into the "static" Windows system PATH without further
ado). 
On the one hand, luckily those PATH entries are usually but not always
appended rather than prepended; on the other hand, from the example PATH
above one can see that -say- "trustworthy" and even well-known programs like
Python, Mercurial, Quicktime and SVN behave this way as well. Some even
leave a trailing backslash in their PATH entry (whose only harm is
witnessing of some lack of attention to detail of their developers :-) ).

For example, Microsoft's own MS-Office doesn't need system PATH entries, so
clearly there are (IMO superior) alternatives.

Octave started with a .bat file that puts Octave's bindir in front of all
other PATH entries has this PATH:

>> strsplit (getenv ("PATH"), pathsep)
ans =
{
  [1,1] = X:\Octave\Octave-3.8.2\bin\
  [1,2] = C:\WINDOWS\system32
  [1,3] = C:\WINDOWS
  [1,4] = C:\WINDOWS\system32\wbem
  [1,5] = X:\Octave\Octave-3.8.2\bin
  [1,6] = X:\Octave\Octave-3.8.2\notepad++
  [1,7] =
X:\Octave\Octave-3.8.2\libexec\octave\3.8.2\site\exec\i686-w64-mingw32
  [1,8] =
X:\Octave\Octave-3.8.2\libexec\octave\api-v49+\site\exec\i686-w64-mingw32
  [1,9] = X:\Octave\Octave-3.8.2\libexec\octave\site\exec\i686-w64-mingw32
  [1,10] = X:\Octave\Octave-3.8.2\libexec\octave\3.8.2\exec\i686-w64-mingw32
  [1,11] = X:\Octave\Octave-3.8.2\bin
}
>>

...featuring Octave's bin dir even three times.


> Or perhaps it should not be doing this at all, because it doesn't
> allow the user to easily override that choice.
> 
> Another option is to have Octave export MKOCTFILE (with a default
> setting, but not overriding the value found in the environment, if
> any) and require package Makefiles to use this variable if they want
> to behave properly.

First off, I think the whole issue is primarily a Windows one. I have never
encountered it on my Linux systems.
Furthermore, mkoctfile is just one example; but Octave's bindir on MinGW
also contains many MSYS utilities (less, gzip, etc.) that probably work
better with the Octave binary they came with, than other MSYS utilities that
may happen to be elsewhere on the system but appear earlier in the PATH. Not
to mention equally named executables that serve different purposes; not all
Windows developers know about *nix utilities.

I think that it doesn't harm at all to have the bin dir of a program
appearing first in the PATH search order;  at least on Windows (but I
wouldn't know why it wouldn't work the same way on other OS-es).
After all, it is reasonable to expect that a program (say, Octave) would
need its own dependencies (associated executables, its own libraries) much
more often than other executables and libraries elsewhere on the host
system. 
AFAIK programs generally run in their own "bubble" (RAM slot, "local" copy
of environment, "local" state of system driver data, etc.) where other
programs have no access to. So it can be argued that other program's PATH
entries have no use in a program's state space unless those other programs
are invoked by the first program (in wich case they inherit their own
environment settings incl. PATH from the first program).

A batch file as shown in  bug #3164
<https://savannah.gnu.org/bugs/?func=detailitem&item_id=43164>   may not be
"superior", but it is effective and IMO even somewhat elegant. 
The only side-effect I can imagine is that it creates another "state space"
with environment settings (i.e., the one owned by the cmd32.exe invocation
that executes the batch file) but as Octave is "started" (= detached) that
"state space" is soon left and erased by the final "exit" command in the
batch file while Octave is starting.

So yes, I think it would be reasonable for Octave to prepend its own $bindir
to the PATH.
But of course that doesn't preclude making the "pkg" command more robust.

But note, I'm not very familiar with the nitty-gritty of how executables
etc. are searched, loaded in memory and launched in today's operating
systems. My own experience dates back from the late 1980-ies when I did my
CS minor and things have become much more complicated since.

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Default-PATH-for-executing-external-programs-tp4667239p4667253.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.