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
>
>