From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: How to get shell source blocks to read my profile?
Date: Mon, 15 Mar 2021 14:02:04 +1100 [thread overview]
Message-ID: <87ft0x2hbe.fsf@gmail.com> (raw)
In-Reply-To: <CA+pajWLTB44878DngzCsp=FwVfiAvgLZDCKv=m-sxS6TK+zZDA@mail.gmail.com>
comments in-line ...
George Mauer <gmauer@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
next prev parent reply other threads:[~2021-03-15 4:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-14 21:30 How to get shell source blocks to read my profile? George Mauer
2021-03-14 21:51 ` Tim Cross
2021-03-15 2:35 ` George Mauer
2021-03-15 3:02 ` Tim Cross [this message]
2021-03-15 17:49 ` George Mauer
2021-03-15 19:53 ` Tim Cross
2021-03-16 0:52 ` Steven Harris
2021-03-16 12:20 ` Maxim Nikulin
2021-03-16 13:21 ` George Mauer
2021-03-16 16:49 ` Nick Dokos
2021-03-16 20:32 ` Tim Cross
2021-03-18 14:59 ` Maxim Nikulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ft0x2hbe.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).