[SOLVED] Sourcing dotfiles.

Lockywolf · 04-30-2014, 04:38 PM

I am sorry for a newbie question, but googling didn't bring me enlightenment.

I use a console runlevel.

When I log in in console, /etc/profile is sourced, and everything works fine.

However, afterwards I sometimes start X by executing startx. (XFCE)

I expect the system to inherit the environment from the console.

However, it seems that some of the environment is lost. As when I run xterm, it just prints:

Code:

bash-4.2$

instead of a proper prompt.

env attached

saulgoode · 04-30-2014, 05:07 PM

Your current BASH process has access to both its "shell" variables and its "environment" variables. The shell variables are not passed on to any child processes (i.e., programs) started by the shell, environment variables are. (You can see a list of environment variables with the BASH 'printenv' command; whereas the 'set' command will display a list of all variables, both shell and environment.)

Sourcing a file does not result in a new, separate process being created -- instead the input of the current process (the BASH shell) is replaced by the contents of the file. Thus all of the shell variables are still available.

When you invoke a program from BASH, the current process (the shell) creates a brand new process and initializes this new process's environment by copying over the environment variables of the shell process (but the shell variables are not copied).

You can promote a shell variable to be an environment variable with the 'export' command.

Didier Spaier · 04-30-2014, 05:10 PM

Just set PS1 and PS2 as you like in ~/.bashrc, or copy/paste there settings found in /etc/profile if you like them:

Code:

PS1='\u@\h:\w\$ '
PS2='> ' # this is bash's default anyway
export PS1 PS2

perbh · 04-30-2014, 05:14 PM

may be a better idea to use ~/.bashrc ?

in your ~/.bash_profile (or ~/.profile) you should then have the following (infact, it could be the only thing)

Code:

test -f ~/.bashrc && . ~/.bashrc

imho - that is the best way of dealing with all the env-variables cuz' its on a person-to-person basis, not global

Lockywolf · 04-30-2014, 05:33 PM

Quote:

Originally Posted by perbh

may be a better idea to use ~/.bashrc ?

in your ~/.bash_profile (or ~/.profile) you should then have the following (infact, it could be the only thing)

Code:

test -f ~/.bashrc && . ~/.bashrc

imho - that is the best way of dealing with all the env-variables cuz' its on a person-to-person basis, not global

I do not think it is a good option.

Basically, .bashrc is a place where a user can override a (reasonable) default behaviour with his own preferences.

However, having no shell variables cannot be called a reasonable default behaviour.
Namely, there is a whole fine-tuned environment in /etc/profile.d/ (not mentioning the cosmetic stuff like PS1 present directly in /etc/profile)

But even if this logic does not convince you, all users already have the same (non-empty) profile in text console by default.

Didier Spaier · 04-30-2014, 05:52 PM

Quote:

Originally Posted by Lockywolf

However, having no shell variables cannot be called a reasonable default behaviour.

That's not accurate. When not explicitly set PS1 and PS2 take default values as says "man bash":

Code:

       PS1    The value of this parameter is expanded (see PROMPTING below) and used as the  primary  prompt
              string.  The default value is ``\s-\v\$ ''.
       PS2    The  value  of this parameter is expanded as with PS1 and used as the secondary prompt string.
              The default is ``> ''.

The fact that the "env" command doesn't display a shell variable only means that it has not been explicitly set, not that it has no value at all. Otherwise you wouldn't get any prompt instead of e.g.

Code:

bash-4.2$

Lockywolf · 04-30-2014, 06:12 PM

Quote:

Originally Posted by Didier Spaier

That's not accurate. When not explicitly set PS1 and PS2 take default values as says "man bash":

Code:

       PS1    The value of this parameter is expanded (see PROMPTING below) and used as the  primary  prompt
              string.  The default value is ``\s-\v\$ ''.
       PS2    The  value  of this parameter is expanded as with PS1 and used as the secondary prompt string.
              The default is ``> ''.

The fact that the "env" command doesn't display a shell variable only means that it has not been explicitly set, not that it has no value at all. Otherwise you wouldn't get any prompt instead of e.g.

Code:

bash-4.2$

Okay, strictly speaking you are right.

What about solving the question reasonably?

TracyTiger · 04-30-2014, 06:56 PM

Quote:

Originally Posted by Lockywolf

I expect the system to inherit the environment from the console.
However, it seems that some of the environment is lost. As when I run xterm, it just prints:

Code:

bash-4.2$

instead of a proper prompt.
env attached

Quote:

Originally Posted by Lockywolf

Okay, strictly speaking you are right.
What about solving the question reasonably?

You didn't actually ask a question but instead described behavior unexpected by you. Several LQ members inferred what you wanted and gave responses that I thought tried to be helpful and were appropriate.

Please clearly restate your question in case we misunderstood.

moisespedro · 04-30-2014, 08:13 PM

You can add " . /etc/profile" to your .bashrc

Edit: sorry, I totally misunderstood the question

aaditya · 04-30-2014, 09:53 PM

I had a similar question, and the folks at the Slackware IRC channel had pointed me to a possible solution (for xfce-terminal):

xfce4-terminal -> Preferences -> General -> Run Command as Login Shell -> Yes

Since then I have switched to .bashrc though.

TommyC7 · 04-30-2014, 11:21 PM

The reason this is occurring is because bash is not being invoked as if it were a login shell. Simply from the first few lines of the man page:

Code:

--noprofile
Do  not  read either the system-wide startup file /etc/profile or any of the
personal initialization files ~/.bash_profile, ~/.bash_login, or ~/.profile.  By default,
bash reads these files when it is invoked as a login shell (see INVOCATION below).

Other people before me in this thread have explained why you see "bash-4.2" instead of "me@hostname" or what have you.

Also, I don't understand your reasoning against using "$HOME"/.bash_{profile,login} or "$HOME"/.profile. You state:

Quote:

Lockywolf:
Basically, .bashrc is a place where a user can override a (reasonable) default behaviour with his own preferences.

Right, but it's there so that if someone doesn't like the system's defaults, they can change it. Just like "$HOME"/.{vimrc,muttrc,etc.}. If someone doesn't know how to use bash and they set something they shouldn't have in one of the files that bash reads, that's usually fixable.

It doesn't override all of the ones set by the other files read by bash (like /etc/profile), just the ones the user sets. I forget the order in which it goes, but it goes in a certain order and I believe /etc/profile is one of, if not the first.

You seem to have a security concern about the files that bash reads when invoked as a login shell or something. So I guess I should ask, is having those files read by bash your actual primary concern, because if it isn't you seem to have an X-Y problem. That is, you want to do "X" but you're asking how to do "Y".

If reading those files really is your primary concern, then bash has two options documented in the first few lines of its man page that may be helpful for you:

Code:

--norc
--noprofile

555 · 04-30-2014, 11:54 PM

I make the default shell /bin/sh not /bin/bash, which starts bash in Posix mode.

Shells can be called interactively (for example, by starting xterm) or noninteractively (by running a sh script). Also, shells are either login shells or not (is there a name for nonlogin shells?). A login shell will read the ~/.profile file while nonlogin shells do not. You can set environment variables in .profile, but Bash might overwrite these. However, the Posix standard says that the environment variable ENV must be respected by conforming shells. This variable if set gives a path name to a file of sh commands. The file need not be executable. Every time an interactive Posix-conforming bourne shell starts up it will run the commands in the file given by ENV. And furthermore it will not run these commands for noninteractive shells, which is good.

So I make the files

-----------~/.profile-----------------
ENV=~/.shrc
export ENV
--------------------------------------

and say

-----------------~/.shrc----------------------------------
export PS1='[$USER@$(echo $PWD|sed -e s*$HOME*~*)/]: '
----------------------------------------------------------

GazL · 05-01-2014, 04:29 AM

Here's a link to an old discussion myself, tronayne and a few other had on this subject:
http://www.linuxquestions.org/questi...ts-4175472234/

I still prefer to do it this way on my box.

Lockywolf · 05-02-2014, 06:29 AM

Quote:

Please clearly restate your question in case we misunderstood.

Okay, sorry for being unclear.

Let me state the question and misunderstanding more clearly.

When I login in console, my (system-wide) /etc/profile gets sourced, thus executing the commands:

Code:

export PATH DISPLAY LESS TERM PS1 PS2

and

Code:

for profile_script in /etc/profile.d/*.sh ; do
  if [ -x $profile_script ]; then
    . $profile_script
  fi
done

This sets up the environment and shell variables accordingly.

Moreover, AFAIU, it promotes PS1 and PS2 to the environmental variables.

Then I execute startx (which I expect to inherit all environmental variables).

Then I execute xterm(which I also expect to inherit all environmental variables), which in turn, starts an interactive, non-login bash ((which I also expect to inherit all environmental variables)).

However, it seems that not all environmental variables are inherited. (for example, PS1, PS2, and HUSHLOGIN )

I want to understand, why.

This is my first question.

The second question is, how do I make my XTERM-interactive non-login shells have the same friendliness as login shells, without modifying any per-user properties (like editing dotfiles in the user dir or making terminal emulators start login shells). Basically, the system must be resilient enough so that if a user wipes out all his homedir (due to stupidity or malware), he still would receive a fine-tuned shell with bash-completion and stuff. (thus editing skel-files is also not a very good option)

I googled out and found a file called /etc/bash.bashrc, which seems to be "global" .bashrc

But it seems that this file is absent from Slackware, and moreover, it's bash-specific, and would prefer a shell-independent solution.

Didier Spaier · 05-02-2014, 07:09 AM

Well, simply put, each shell has its own environment with specific defaults value for the variables it includes and different files it considers for setting them to other values, as stated in the man page of that shell. You can check easily for instance that default value of PS1 vary upon shell used. Let's show an example (I have set /usr/bin/bash as my default shell). Here is what I see when I launch an xterm, then type commands in it:

Code:

bash-4.2$ ash
$ csh
% zsh
ici% ksh
$ bash
bash-4.2$

Bear in mind that Pat's policy for Slackware (if I understand it) is to ship every software "as is" as much as possible, not making any assumption on use cases or user's preferences. This doesn't please everyone, but seems to please most Slackers (otherwise they'd probably not adopt it :-) and that contributes to make Slackware Linux a very versatile distribution.

For instance Pat doesn't assume anything about how each user wants to have his or her environments set up.

Any user can get the same prompt on the console than in an xterm, and also the same for ash, bash, zsh, csh, ksh, whatever, if so inclined – but setting the system accordingly is that person's job, not Pat's, IMHO.

PS. You might want to convince their respective developers that every shell should use the same environment variables, with the same default values and the same method to set them using the same files. Good luck, then.