[Solved] should ~/.profile really be sourcing ~/.ashrc?

[GNUser]

I use the default shell (busybox ash) as my daily driver.

This is in base system's /etc/skel/.profile:

Code: [Select]

if [ -f "$HOME/.ashrc" ]; then
export ENV="$HOME/.ashrc"
. "$HOME/.ashrc"
fi
After I'm logged in and run a GUI terminal emulator, ash runs the commands in .ashrc as expected, but it seems counterintuitive that ash has already inherited everything in .ashrc due to the login shell's sourcing of .ashrc

To see what I mean, here is a little experiment. If I add this to .ashrc:

Code: [Select]

echo "123 $TEST 123"
export TEST="hello world"
echo "123 $TEST 123"
I think the expected output after I reboot and launch a terminal emulator is this:

Code: [Select]

123  123
123 hello world 123
but what I get is this (because login shell already ran .ashrc and passed its environment on to my GUI session):

Code: [Select]

123 hello world 123
123 hello world 123
My understanding of POSIX and ash is that commands in  .profile  are for login shells, while commands in the  ENV  config file (.ashrc in our case) are for interactive shells. I think not sourcing .ashrc in .profile would be clearer, like this:

Code: [Select]

if [ -f "$HOME/.ashrc" ]; then
export ENV="$HOME/.ashrc"
fiAll the different shell configuration files are already confusing enough as it is. I know that a shell can be both "login" and "interactive" at the same time (ugh), but wouldn't it be more conceptually clear if .profile refrained from sourcing .ashrc?

[GNUser]

I did a web search and discovered that it is relatively common for people's .profile to source .bashrc (which is analogous to our .profile sourcing .ashrc).

So it seems this is a matter of preference. Oh, well. To me it makes much more sense for ~/.profile to not source ~/.ashrc, so I removed the offending line from my ~/.profile. No ill effects so far, and the relevant behaviors in interactive shells are exactly what I would expect.

[GNUser]

Juanito, should I create a pull request on github to change this in /etc/skel/.profile:

Code: [Select]

if [ -f "$HOME/.ashrc" ]; then
export ENV="$HOME/.ashrc"
. "$HOME/.ashrc"
fito just this:

Code: [Select]

if [ -f "$HOME/.ashrc" ]; then
export ENV="$HOME/.ashrc"
fi? (for TCL18)

The advantage is that it seems conceptually cleaner. The disadvantage is that the current .profile has been thoroughly tested over many years in many TCL releases.

If you think this is best left alone, I completely understand.

[Juanito]

@Rich?

[GNUser]

Curaga had this to say: ".(b)ashrc is run on every shell, while .profile is run on login" (https://forum.tinycorelinux.net/index.php?topic=24539.msg155731#msg155731)

If I'm interpreting him correctly, curaga was okay giving special treatment only to login shells. I think he would say that our current /etc/skel/.profile is fine as-is. Do you agree, Rich?

[Rich]

Hi GNUser
I would say you want .ashrc to run because that's where aliases
for commands are often placed.

... I think he would say that our current /etc/skel/.profile is fine as-is. ...

I would say  .profile  is fine as-is.
I can't even find where  /etc/skel/.profile  is being used,

[GNUser]

Hi Rich.

I would say  .profile  is fine as-is.

Thanks for confirming

I can't even find where  /etc/skel/.profile  is being used,

The  setupHome  function in /etc/init.d/tc-functions uses the files in /etc/skel.

Thread may be marked as Solved. Sorry for the noise. I thought I had found a problem, but it was a false positive

[Rich]

Hi GNUser
That explains it. I was looking for the tree (/etc/skel/.profile) when
I should have been looking for the forest (/etc/skel).

Marked as solved.