Where does the Shell class inherit it's environment?

General
1

I’ve just noticed that the shell’s PATH under OS X and Linux do not include /usr/local/bin. Since that is included in the default PATH for normal users, I can only assume that you’re generating it internally?

Also, if we look at the /usr/libexec/path_helper tool’s output, it includes /usr/local/bin as the first element.

Shouldn’t the back end for the Shell inherit the current user’s environment?

2

my understanding is the shell is basically an “anonymous” user… and inherits nothing
any changes you make to path (via CD etc) do not reflect back when you exit the shell.
about the only lasting effect a shell might have is changes to the file structure (new files, changed or deleted files)
If you change environement variables, those changes revert once the shell is closed.

Shell is NOT an extension of the current process. it is in fact a new independant process

3

The shell inherits the environment of your app.
And that is not the one you get in terminal application as bash there reads the profile configuration file.

4

No
Its a fairly raw shell NOT a Terminal session
As Christian noted you’d have to run all the profile startup scripts etc to get an environment that behaves more like Terminal

5

[quote=358082:@Norman Palardy]No
Its a fairly raw shell NOT a Terminal session
As Christian noted you’d have to run all the profile startup scripts etc to get an environment that behaves more like Terminal[/quote]
Can you share the logic behind that design decision? I’m not interested in the shell being a terminal, but I am having issues with the situation that exists in that “some” path and other environment elements are inherited (such as the user!). For example, this is the environment reported in a new shell:

SHELL=/bin/bash
TMPDIR=/var/folders/c0/1bygvwnd66v4k8ykl0ttn_dw0000gn/T/
Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.WarkvKdmvg/Render
USER=tjones
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.LP7ToqYEIN/Listeners
__CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0
PATH=/usr/bin:/bin:/usr/sbin:/sbin
_=/usr/bin/env
PWD=/
XPC_FLAGS=0x0
XPC_SERVICE_NAME=com.tolisgroup.shellenvironment.39168
SHLVL=2
HOME=/Users/tjones
LOGNAME=tjones

It’s getting everything else about the user’s basic environment - INCLUDING the shell and the user, so why not that user’s PATH and other variables?

6
  • shells inherit environment because their underlying implementation relies on the various EXEC calls
  • however BASH invoked as a NON-login shell will not necessarily run a users bash startup hence you get no user profile set up
    (see https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html)
  • the SHELL object doesn’t have a means for you to invoke it so you get a login shell
  • you can affect this by running your command as “bash --login -c ‘my escaped command’”
7

In searching “creatively” in the forum, I see that I’m not the only one to ask about this (and I’d been involved with a prior discussion a while back - sucks getting old). Is there any specific reasoning behind NOT picking up the current user’s environment when starting a Shell? It seems that this would be something that should be the default since more folks would expect this behavior than the current - especially since SIP has now locked 3rd party tools to /usr/local/bin under Mac OS.

8

Dunno - you’d have to ask the folks that wrote bash :stuck_out_tongue:

9

Please learn that there are two different things.
The OS provides an environment when the app is launched. This may be the one from terminal, if the app is launched from there.
But normally it’s a much smaller one.

The one in terminal is that plus whatever is configured in per user or per computer settings.
There is nothing for Xojo to pickup.

And if you need you can use shell class to run bash to run your tools.

10

Or just run whatever command as “/usr/bin/bash --login -c ‘my escaped command’”
Or use an interactive shell and run “/usr/bin/bash --login” first

There’s not always a login session associated with a shell (ie something run at startup) etc and so us always running “bash --login” could create issues all by itself

This behaviour of shell isn’t new and changing it could easily mess up a lot of software that uses it as it currently exists

11

And to double-check what has been explained:

  1. Launch your .app by double-clicking it in Finder (or by double-clicking Xojo in Finder and doing a Debug-Run)
  2. Launch your .app via Terminal: /path/to/test.app/Contents/MacOS/test
    Do you notice the difference in what you “see” in the PATH environment variable?
12

It’s not a design decision. It’s imposed by the OS. It’s how shell processes work, in any programming environment.

13

Ummm, execvp()? execl()? popen()? It’s only “imposed” by the OS if you call the simplest form of exec, therefore “design decision”.

Needless to say, it’s what we have and I’ll work around it.

[quote=358143:@Jürg Otter]And to double-check what has been explained:

  1. Launch your .app by double-clicking it in Finder (or by double-clicking Xojo in Finder and doing a Debug-Run)
  2. Launch your .app via Terminal: /path/to/test.app/Contents/MacOS/test
    Do you notice the difference in what you “see” in the PATH environment variable?[/quote]
    Very good point. There is a massive difference between the two environment contents.
14

we generally use execlp

but thats not the only issue as Jurgs test pointed out