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