Thanks a lot! The interactive/non-interactive was indeed the core issue. Extra frustrating because it seems like supplying `--rcfile` does nothing if you *do* use `-c` but *don't* use `-i`...ah ad-hoc cli design.
As a general solution, I've found that adding this block in my org buffer will make shell (which is zsh in my case) run in interactive mode for all of these * Local Variables :noexport: :PROPERTIES: :VISIBILITY: folded :END: local variables: shell-file-name: "/bin/zsh -i" end: On Sun, Mar 14, 2021 at 11:04 PM Tim Cross <theophil...@gmail.com> wrote: > > comments in-line ... > > George Mauer <gma...@gmail.com> writes: > > > 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 > > > > To clarify, the GUI mode is unrelated. You can run in GUI mode from a > terminal and the emacs process will inherit the environment in the > terminal. If that terminal is a login terminal (i.e. terminal shell was > run as a login shell), the 'profile' file will be sourced and the 'rc' > file will have been sourced. If not a login shell, only the rc file will > have been sourced. > > If on the other hand, Emacs is started from the dock, it is started in a > completely different process chain and is not a child of a login > process. This is why, if you want your emacs to have /usr/local/bin in > the path, you have to add it to /etc/paths or /etc/path.d whereas if you > start emacs from within a terminal (GUI or text mode), you only need to > add /usr/local/bin to your PATH setting in .profile (just an example to > highlight the difference between running from in a terminal and running > from the dock). > > > 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 > > > > Have a closer look on the section in the bash manual on the difference > between interactive and non-interactive shells. (also holds for zsh). > Basically, the 'rc' files are not sourced for non-interactive shells. > > > Why would the output not include ~GIM_BASHRC~ - it should have been run, > right? > > > > No. Adding the -c means it is a non-interactive shell, so no .bashrc > sourcing. > > > > 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 > > > > Same issue here. --rcfile only has effect in interactive shells. > > > 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... > > > > You could try sourcing it e.g. > > #+begin_src shell > source ~/.bashrc > env > #+end_src > > or use 'shorthand' dot > > #+begin_src shell > . ~/.bashrc > env > #+end_src > > there are also some options you can add at the 'shebang' line i.e. > > #!/bin/bash -l > > or > > #!/bin/bash -i > > which will change the behaviour. > > There is a lot of 'meat' in the bash man page and there is a lot of > additional information in the bash info pages. However, both can be a > bit terse and because the info is very 'dense', it is very easy to miss > key points. > > In order to have environment variables available inside your org source > blocks, you really need to > > - have them in the environment inherited by emacs when it starts. This > will depend how you start Emacs (i.e from within an interactive shell > vs from the dock). Note that you typically don't see this issue under > Linux because in most Linux setups, the X environment is started > inside a login shell. So everything started as part of the X session, > like a dock, is a child of the login process and therefore inherits > the login environment. On a mac, the dock is not part of the login > shell, so it only inherits what is in the system wide bash profile > file. > > - Ensure your source block run as interactive and/or login shells using > shebang options like -i or -l > > - explicitly source the .profile or .bashrc file using a source call > > - pass the environment variable in on the command line e.g. > > #+begin_src shell > FRED=barney env > #+end_src > > will result in > > FRED=barney > > being in the output from 'env'. > > > > ----------- > > > > 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 > > > > It is actually a little more subtle. It isn't because your running in > GUI mode those variables are not there. It is because your running from > the dock. Run it in GUI mode from within a login terminal and all those > variables will be 'in' emacs. > > <snip> > > > 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. > > > > There is also a difference between interactive and non-interactive > shells. I suspect this is the root cause of your issue. The source block > being run are non-interactive. > > -- > Tim Cross > >
