Hey Tim, thanks for helping out. I commented inline to your response below but I'll sum up and ask the outstanding questions more directly here as well.

I think you might have misread what I was doing - I had 3 different variables set in 3 different places precisely because I want to dissect things and figure out which profile/rc scripts were run.

Yes, this is emacs running in GUI mode so yes, it doesn't have a shell as a parent. But that only explains why these environment variables aren't in emacs itself, not the spawned bash or zsh processes

So to sum up the specific questions. My ~shell-file-name~ is ~/bin/zsh~ which seems to be what ~ob-shell~ is passing down to be run. So why on earth does my ~GIM_ZSHRC~ variable not show up here?

#+begin_src shell
env
#+end_src

When I actually directly call bash

#+begin_src shell
bash -c env
#+end_src

Why would the output not include ~GIM_BASHRC~ - it should have been run, right?

What about when I call this? Even with explicitly selecting the rc file to run, it seems to not

#+begin_src shell
bash --rcfile ~/.bashrc -c env
#+end_src

Finally, the outstanding question about ~ob-shell~ is if there is any way to force it to run the shell processes' rc-script? I really would have expected it to be run in the above situations already...

-----------

Is this perhaps on a Mac where Emacs is started from the dock?

Yup like I said, its in GUI mode so I understand why those environment variables aren't within emads itself

If so, it
could be because on the mac, applications started from the dock are not
executed inside a login shell. Do you get different results if you start
emacs from within a terminal?

Yup I do, but thats why I move on to the test where I run `bash` directly

I am also a little confused by your examples. Some of them are
attempting to source .bash_profile, others .bashrc and others .zshrc.

I created the three environment variables I indicated and placed one in each file so that I could test which profile file ran

Which shell are you using and which files do you have? I get the feeling
that in your frustration, you have taken a 'shotgun' approach and added
the variable everywhere.

That's exactly what I'm trying to avoid here. I *did* add variables everywhere, but I added *different* variables everywhere so that I can see exactly which profile ran.

For some reason, there seems to be some confusion these days about the
difference between .profile, .bash_profile, .bashrc, .zsh_profile and
.zshrc. In particular, I frequently see incorrect/wrong advice regarding
the use of 'profile' and 'rc' files. Most of it can
be blamed on wrong advice in forums like stack overflow!

It is certainly confusing but I think I got a handle on it mostly. If it's a login shell you'll run a profile, if it's not you'll run the default rc file unless one of the options were specified. I think each is named specific to each shell name but oftentimes you chain them together in practice.

I would also experiment with just dumping out the output of 'env' and
not run it through grep so that you can see what is being defined.

I did, that just isn't conducive to posting on an email list ;)

iI also think it is a good dea to be explicit about the shell so that you have more
control/understanding over what is being run e.g. put the line

Yeah, I suppose I could do a prologue with a hashbang, but I debugged into the source and it's just ~shell-file-name~ which in my case is ~/bin/zsh~

In very broad terms (glossing over some of the subtleties, which is
likely the cause of some of your issues), the 'profile' files are only
sourced for login shells and the 'rc' files are sourced whenever a new
shell process is run. Note that these processes run in a hierarchy i.e.
shell processes have a parent process. Some things have to be set in
your 'profile' (or are better set there) while other things must be set
in your 'rc' file. For example, setting PATH in your 'profile' is normal
because you typically just want that set once and then 'exported' to all
child processes. Setting a dynamic prompt which changes depending on the
directory your in (or because it has some other dynamic data, like the
time) need to be set in your 'rc' file because these are sourced before
each shell process is executed. I the 'old days' it was important to get
these distinctions correct because sourcing the files could have a
performance impact - not as big an issue these days.

Great history, thanks, that's mostly what I was thinking but gives me useful background

These days, things seem to have become even more confusing in an attempt
to make things easier. I often see people with a .profile, a
.bash_profile, a .bashrc, a .zsh_profile and a .zshrc with variables set
and exported mixed in across all these files.

Don't forget that many tools from homebrew to pyenv install scripts to ansible will start modifying these for you

This is a source of
terrible confusion and unexpected results. Some 'canned' shell
configurations, like 'oh-my-zsh' also try to be extra helpful by
sourcing files which are not normally sourced by that shell (to make
smoother migration from bash shells for example). Sometimes, it can be
helpful to put a line like the following into each of these files

echo "Executing <filename> at `date`" >> ~/profile.log

just to see what is getting executed when (you won't want to leave this
there - just for diagnostic and experimentation to help understand when
things are being sourced. You could even dump out the output of 'env' so
that you can see how the environment is being changed as each of these
files executes.

Yup, thanks.

George Mauer <gmauer@gmail.com> writes:

> I am confused why no matter how I try to run shell commands they seem to be missing variables exported in profiles.
>
> I have added 3 variables to various startup scripts
>
> - ~./bash-profile~ :: ~export GIM_BASH_PROFILE="yes"~
> - ~./bashrc~ :: ~export GIM_BASHRC="yes"~
> - ~./zshrc~ :: ~export GIM_ZSHRC="yes"~
>
> I am running emacs in GUI mode so I get why none of these are available *directly* in emacs, so then I try
>
> #+begin_src shell :results list
> env | grep GIM
> #+end_src
>
> #+RESULTS:
>
> Ok that's kinda surprising, but I suppose it could be running ~/bin/zsh~ (that's my ~shell-file-name~) directly
>
> what about
>
> #+begin_src shell :results list
> bash -c env | grep GIM
> #+end_src
>
> #+RESULTS:
>
> That's pretty surprising. I would have expected running it directly to actually run my profile.
>
> Shockingly
>
> #+begin_src shell :results list
> bash --rcfile ~/.bashrc -c env | grep GIM
> #+end_src
>
> #+RESULTS:
>
> That is *still* nothing!
>
> Sanity is restored slightly when I run
>
> #+begin_src shell :results list
> bash --login -c env | grep GIM
> #+end_src
>
> which *does* indeed visit ~.bash_profile~ but only slightly.
>
> What is going on, and is there a straightforward way in which I can get shell block to read from a profile?

--
Tim Cross