LinuxQuestions.org - [SOLVED] GNU Screen doesn't start shells as a login shell

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - GNU Screen doesn't start shells as a login shell (https://www.linuxquestions.org/questions/linux-software-2/gnu-screen-doesnt-start-shells-as-a-login-shell-796984/)

GNU Screen doesn't start shells as a login shell

I want to have an ls' output colorization in gnu screen. Colorization in my system (Slackware 13) is realized by aliasing of ls in /etc/profile.d/coreutils-dircolors.sh:

Code:

$ alias ls

alias ls='/bin/ls $LS_OPTIONS'

where $LS_OPTIONS is

Code:

$ echo $LS_OPTIONS

-F -T 0 --color=auto

But in screen this alias isn't defined. It seems like /etc/profile script isn't executed at shell starting in screen. I think it happens because screen starts a shell not as a login shell. I tried to correct it by adding

Code:

shell -$SHELL

to ~/.screenrc or to /etc/screenrc. The problem is the same. By the way when I start screen as a root I haven't this problem. What's wrong?

Assuming main shell is bash, I would look at what the setting are for .bashrc and .bash_profile for root.
I believe this should shed some light on the subject. You might also want to google for bashrc bash_profile
differences

Quote:

Originally Posted by Himilhil (Post 3907235)

I want to have an ls' output colorization in gnu screen. Colorization in my system (Slackware 13) is realized by aliasing of ls in /etc/profile.d/coreutils-dircolors.sh:

Code:

$ alias ls

alias ls='/bin/ls $LS_OPTIONS'

where $LS_OPTIONS is

Code:

$ echo $LS_OPTIONS

-F -T 0 --color=auto

Code:

shell -$SHELL

to ~/.screenrc or to /etc/screenrc. The problem is the same. By the way when I start screen as a root I haven't this problem. What's wrong?

Non-login shells are necessarily descendant processes of a login ancestor shell in the normal interactive working environment. Thus they inherit anything exported when the login shell ran /etc/profile (and not unset after then). AFAIK this does not include aliases and is one of the reasons for preferring functions over aliases, because functions can be exported.

The conventional solution to this issue is to define aliases in ~/.bashrc and source ~/.bashrc from within /etc/profile

Code:

if [ -f ~/.bashrc ]; then . ~/.bashrc; fi

Another solution in this particular case would be to source /etc/profile.d/coreutils-dircolors.sh from within ~/.bashrc.

As grail suggested, the root discrepancy may lie in specifics of root's bash startup files or you may be running a login shell when starting a terminal session for root (a very Good Thing for security).

Documentation on bash startup files here.

.bashrc file with ls alias definition is placed in root's home directory indeed. Hmmm... I can't even remember when I placed it there. But if alias definition is commented in this file colorization don't work in root's screen too. I've copied root's .bashrc to my home directory. First it didn't resolve my problem. It was needed to define shell as /bin/bash for my user obviously. Before that default shell (/bin/sh) was used for my user. I have no idea why .bashrc wasn't used in this case because /bin/sh is symlink linked to /bin/bash. Nevertheless after I had defined shell for my user in /etc/passwd colorization came to be worked in screen.