emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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 08:51:57 +1100	[thread overview]
Message-ID: <87a6r5l5bh.fsf@gmail.com> (raw)
In-Reply-To: <CA+pajWKvSL2-+NZ5HEM+Bej1PsDEuj1=GPuK8TLj3gWsf8bxVg@mail.gmail.com>


Is this perhaps on a Mac where Emacs is started from the dock? 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? If so, this is almost certainly the source
of your issue/difference.

I am also a little confused by your examples. Some of them are
attempting to source .bash_profile, others .bashrc and others .zshrc.
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. It might be time to go back and look at all
your shell environment files and rationalise them a bit. Things can
become a little confusing when running zsh as so many things
assume/expect a bash shell. While zsh is pretty compatible with bash, so
few problems arise, it can lead to confusion regarding where to set
variables and understand what is being sourced and when.

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!

The 'profile' and the 'rc' files fulfil different purposes and are
sourced at different times. Have a careful read of the bash man page
(even if your running zsh as they all tend to follow the same pattern).
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. This
can help you understand what is being sourced. I also think it is a good
idea to be explicit about the shell so that you have more
control/understanding over what is being run e.g. put the line

#!/bin/bash

or

#!/bin/zsh

or

#!/bin/sh

as the first line.

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.

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


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


  reply	other threads:[~2021-03-14 22:49 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 [this message]
2021-03-15  2:35   ` George Mauer
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=87a6r5l5bh.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).