From: George Mauer <gmauer@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: How to get shell source blocks to read my profile?
Date: Sun, 14 Mar 2021 21:35:12 -0500 [thread overview]
Message-ID: <CA+pajWLTB44878DngzCsp=FwVfiAvgLZDCKv=m-sxS6TK+zZDA@mail.gmail.com> (raw)
In-Reply-To: <87a6r5l5bh.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7284 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 10025 bytes --]
next prev parent reply other threads:[~2021-03-15 2:36 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 [this message]
2021-03-15 3:02 ` Tim Cross
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='CA+pajWLTB44878DngzCsp=FwVfiAvgLZDCKv=m-sxS6TK+zZDA@mail.gmail.com' \
--to=gmauer@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).