PATH for system calls in scripts? about praat HOT 3 CLOSED

I can confirm that this is the same in Linux: if run from the GUI, appendInfoLine: environment$("PATH") prints a different string than the PATH available outside. Running that script with Praat from the CLI, the result is the same PATH available to the user who called it.

Where is this change taking place? And is this intentional? If so, why?

from praat.

"the PATH available outside"? I think there exists no such concept on Unix. Environment variables are local to processes, and they are inherited from parent to child processes. Thus, if a Terminal window has a long PATH variable, and you start up Praat from that Terminal window, Praat will report a long PATH variable (please try). If you do "setenv BLIBLA hkfghdfjg" in one Terminal window, another Terminal will not know about it, because environment variables are not sent to sister processes; this is true even when you start the second Terminal window after creating the environment variable in the first Terminal window, because environment variables are not sent from child to parent processes. The same behavior happens with working directories: they as well stay local within their process (thank God) and are inherited by child processes (thank God). In a Praat script, the command "runSystem" starts up a child process that inherits its environment variables from Praat and also inherits its working directory from Praat, and any setenv or cd that you do inside the system command that you're running stays within that scope (thank God). By contrast, if you start up Praat not from a Terminal window but from the Finder, the PATH variable that you get is inherited from the Finder. Why is that PATH variable different? Because Terminal windows run the .cshrc shell script file when they start up (see man tcsh for a complete list), and the Finder only runs the .login shell script (if it does; I did not test this). My .cshrc, for instance, was modified by the Python installer and therefore contains "set path=(/Library/Frameworks/Python.framework/Versions/2.7/bin $path)". Also, MacPorts did "setenv PATH /opt/local/bin:/opt/local/sbin:$PATH". All of this happens only within .cshrc, and the Finder does not run that at start-up. To move the longer PATH into Praat, you would like to start up Praat with a shell that does read .cshrc, e.g. with "tcsh praat". If you know of programs that do have the longer PATH, please tell me about it (e.g. R, when started from the Finder, has a PATH that doesn't include Python on my Mac).

from praat.

if a Terminal window has a long PATH variable, and you start up Praat from that Terminal window, Praat will report a long PATH variable (please try)

Yup, that is correct. Thanks for clearing that up.

I guess "[preserving] cross-platform portability" in this case means using executables that are in the system PATH. Which makes sense.

from praat.