LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 05-05-2010, 04:50 AM   #1
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Rep: Reputation: 35
How are variables set for interactive shells?


I am trying to figure out where variables are set for interactive shells?

In particular, I am trying to have LS_OPTIONS inherited by interactive shells as it is by login shells.

I understand LS_OPTIONS is set in /etc/profile, and this may not be processed by interactive shells but by login shells.

However, I also note other variables such as PATH and INPUTRC are set correctly in interactive shells, and these are also set in /etc/profile from what I understand.

So how is it determined which variables are inherited by all shells, and which are just for login shells?
 
Old 05-05-2010, 05:18 AM   #2
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,546
Blog Entries: 28

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
You are right -- /etc/profile is used by login shells but not by non-login shells -- but any environment variables set in /etc/profile (by export varname=value) are inherited by all processes that are descendants of the login shell (including non-shell processes) unless they are explicitly removed, for example by bash' unset command.

Can you give us more detail about LS_OPTIONS? How do you know it is set for login shells? How do you know it is not set for non-login shells? What are the lines that set it in /etc/profile (is it terminal-type dependent)? Is it unset in the non-login bash startup files.
 
Old 05-05-2010, 05:26 AM   #3
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Original Poster
Rep: Reputation: 35
Well, I am actually using zsh, and I know that I have not set LS_OPTIONS myself at all in any zsh specific files.

Code:
josh@pts/1:~#  zsh -l
josh@pts/1:~#  echo $LS_OPTIONS                                         
-F -b -T 0 --color=auto
josh@pts/1:~#  zsh -i                                                   
josh@pts/1:~#  echo $LS_OPTIONS

josh@pts/1:~#
It is the same for bash.

LS_OPTIONS is set in /etc/profile.d/coreutils-dircolors.sh which is sourced by /etc/profile

I just don't get why it is sourced only for login shells. I can't see anything in /etc/profile that would make this so.
 
Old 05-05-2010, 05:43 AM   #4
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,546
Blog Entries: 28

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
Quote:
Originally Posted by Josh000 View Post
I just don't get why it is sourced only for login shells. I can't see anything in /etc/profile that would make this so.
The idea is that the login shell sets up the environment variables and the non-login shells inherit them. Is $LS_OPTIONS an environment variable? env | grep LS_OPTIONS would show.
 
Old 05-05-2010, 05:46 AM   #5
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Original Poster
Rep: Reputation: 35
Quote:
Originally Posted by catkin View Post
The idea is that the login shell sets up the environment variables and the non-login shells inherit them. Is $LS_OPTIONS an environment variable? env | grep LS_OPTIONS would show.
Yes, LS_OPTIONS is an environment variable

Have a look at /etc/profile

Near the end, there is a section that iterates through all the scripts in /etc/profile.d and adds them.

Since the rest of what is set in /etc/profile is set then I don't understand why LS_OPTIONS is not set.

It is even stranger because LS_COLORS is set correctly.

There is nothing that I can see that would unset LS_OPTIONS for interactive shells.

Last edited by Josh000; 05-05-2010 at 05:47 AM.
 
Old 05-05-2010, 06:38 AM   #6
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,546
Blog Entries: 28

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
Quote:
Originally Posted by Josh000 View Post
There is nothing that I can see that would unset LS_OPTIONS for interactive shells.
Same mechanism on Slackware (but I don't use it). Was not able to reproduce your problem
Code:
c@CW8:/etc/profile.d$ . coreutils-dircolors.sh
c@CW8:/etc/profile.d$ echo $LS_OPTIONS
-F -b -T 0 --color=auto
c@CW8:/etc/profile.d$ bash -i
c@CW8:/etc/profile.d$ echo $LS_OPTIONS
-F -b -T 0 --color=auto
I could not find anything about interactive shells in the GNU Bash Reference that explains the reported behaviour.

According to the same reference on startup files the only action taken while starting an interactive shell is the read ~/.bashrc and you have already written that it contains nothing to explain the behaviour. Just to rule it out, it might be worth trying
Code:
bash -i --norc
 
Old 05-05-2010, 06:46 AM   #7
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Original Poster
Rep: Reputation: 35
Interesting

When you start a terminal, do you have the terminal start a login shell or an interactive shell?

Although I don't think even that would make a difference. Here if I use "xterm -ls" LS_OPTIONS is set correctly, although if I start an interactive shell from that instance it is not.

It seems quite odd...
 
Old 05-05-2010, 06:55 AM   #8
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,546
Blog Entries: 28

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
Quote:
Originally Posted by Josh000 View Post
When you start a terminal, do you have the terminal start a login shell or an interactive shell?

Although I don't think even that would make a difference. Here if I use "xterm -ls" LS_OPTIONS is set correctly, although if I start an interactive shell from that instance it is not.
Desktop lanucher command is /usr/bin/mrxvt -name c -ic /usr/share/pixmaps/mrxvt.xpm which doesn't help you much! The mrxvt configuration dictates what to do for user "c".

For simplicity, I opened a virtual terminal (Ctrl+Alt+F2) and necessarily logged on then did exactly as in the last post with exactly the same results.
 
Old 05-05-2010, 06:57 AM   #9
GazL
Senior Member
 
Registered: May 2008
Posts: 3,392

Rep: Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917
profile.d/coreutils-dircolors.sh is broken in slackware. I changed it to fix the syntax errors it generates in ash, but it'll also resolve your issue.

The problem is that as written LS_OPTIONS is set as an Array when used with zsh and you can't export an array.

Replace it with the script in the attachment and you'll be fine.


I sent this fix along with a couple of other shell related ones to Pat a month or so back.


edit: This has been adopted by Pat in official Slackware now, so I'm removing the attachment to save space.

Last edited by GazL; 06-18-2010 at 09:56 AM.
 
1 members found this post helpful.
Old 05-05-2010, 07:02 AM   #10
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,546
Blog Entries: 28

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
Quote:
Originally Posted by GazL View Post
profile.d/coreutils-dircolors.sh is broken in slackware. I changed it to fix the syntax errors it generates in ash, but it'll also resolve your issue.

The problem is that as written LS_OPTIONS is set as an Array when used with zsh and you can't export an array.
Thanks GazL -- I was getting confuzzled by this one; Josh000 can you re-test "It is the same for bash"?
 
Old 05-05-2010, 09:20 AM   #11
GazL
Senior Member
 
Registered: May 2008
Posts: 3,392

Rep: Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917
Quote:
Originally Posted by catkin View Post
Thanks GazL -- I was getting confuzzled by this one; Josh000 can you re-test "It is the same for bash"?
No problem. It's a sneaky one isn't it.

While we're on the subject of running shells with the '-l' option to simulate a login shell, you need to be wary, because if you run a shell of a different type to that of your default login shell then the. $SHELL can't be relied on to contain the correct value. Subsequently, the wrong parts of /etc/profile or one of its sub-scripts can easily be run.

I came up with the following alteration for /etc/profile to work around that issue:
Code:
case $0 in
  -* )  # If $0 starts with a '-' then we're being run by a real login shell
        # started by 'login', 'su', 'ssh', 'telnet' and the like.
        # We can trust the value of $SHELL
        case $SHELL in
          /bin/bash )  PS1='\u@\h:\w\$ '
                       ;;
          /bin/ksh )   PS1='! ${PWD/#$HOME/~}$ '
                       VISUAL=vi
                       ;;
          /bin/zsh )   PS1='%n@%m:%~%# '
                       ;; 
          * )          PS1='$ '  
                       ;;
        esac
        ;;
  * )   # Otherwise, we've probably been invoked from a shell that 
        # has a command line switch which simulates a login shell: such as 
        # 'bash -l' or 'dash -l'.  In which case, $SHELL cannot be
        # relied upon and we have to use alternative means where available.
        test -n "$BASH_VERSION" && PS1='\u@\h:\w\$ ' || \
        PS1='$ '
        ;;
esac
You'll notice my "fixed" version of coreutils-dircolor.sh still checks against $SHELL as I hadn't gotten around to fixing this second issue in that yet, but it's not going to be any worse than the original in that respect.

I think the moral of the story is don't use '-l 'unless you really need to.

Last edited by GazL; 05-05-2010 at 09:22 AM.
 
Old 05-05-2010, 09:38 AM   #12
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,546
Blog Entries: 28

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
Quote:
Originally Posted by GazL View Post
No problem. It's a sneaky one isn't it.

While we're on the subject of running shells with the '-l' option to simulate a login shell, you need to be wary, because if you run a shell of a different type to that of your default login shell then the. $SHELL can't be relied on to contain the correct value.
[snip]
I think the moral of the story is don't use '-l 'unless you really need to.
Thanks for the heads up. From the bash man page
Code:
       SHELL  The full pathname to the shell is kept in this environment variable.  If it is not set when the shell starts, bash assigns  to
              it the full pathname of the current user's login shell.
I only have bash and ash so can't explore much. Presumably "the current user's login shell" is the one in /etc/passwd. Here's exploring at the command line with bash
Code:
c@CW8:~$ export SHELL=foo
c@CW8:~$ bash -l
localhost being added to access control list
c@CW8:~$ echo $SHELL
foo
I was vaguely aware that $SHELL is not robust. Is there no way to ask the current shell "what are you?"?
 
Old 05-05-2010, 09:57 AM   #13
GazL
Senior Member
 
Registered: May 2008
Posts: 3,392

Rep: Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917
bash sets it if it's unset, but unless you manually unset it before running bash, that's not likely to be the case.

zsh doesn't set it whether it's unset or not, so for most cases it's just going to contain the value that you inherited from the parent's environment.

In the example I posted above, you'll see that I check for $BASH_VERSION as a way to identify it's being run by bash. zsh has a $ZSH_VERSION that you can use to the same ends, but not all shells have anything like that that gives the game away.
 
Old 05-05-2010, 02:05 PM   #14
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Original Poster
Rep: Reputation: 35
Quote:
Originally Posted by GazL View Post
profile.d/coreutils-dircolors.sh is broken in slackware. I changed it to fix the syntax errors it generates in ash, but it'll also resolve your issue.

The problem is that as written LS_OPTIONS is set as an Array when used with zsh and you can't export an array.

Replace it with the script in the attachment and you'll be fine.


I sent this fix along with a couple of other shell related ones to Pat a month or so back.
Hi Gazl,

I'm about to try your fix now.

I just have a question though, because my problem does not seem zsh specific.

For my user account zsh is the default shell, while bash is the default shell for root.

Logged in as my user, if I start a login shell with either xterm -ls, or zsh -l from within then $LS_OPTIONS is set correctly.

In an interactive shell, LS_OPTIONS is just blank.

It's the same as root..., if I use su -, then LS_OPTIONS is set correctly.

If I use bash in interactive mode, then it is the same as with zsh in interactive mode under a user account, LS_OPTIONS is just blank.

However, if I start a bash interactive shell from with zsh as a user, then LS_OPTIONS is set to just "-F". That seems like an array issue certainly,

But with zsh and bash behaving the same way is it really an issue specific to zsh?
 
Old 05-05-2010, 02:17 PM   #15
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Original Poster
Rep: Reputation: 35
OK, I just tried with the new coreutils-dircolors.sh

This is the result

Code:
%n@%m:%~%# bash --login
%n@%m:%~%# ls
bash: ${=LS_OPTIONS}: bad substitution
%n@%m:%~%# echo $LS_OPTIONS
-F -b -T 0 --color=auto
%n@%m:%~%# bash
%n@%m:%~%# ls
-files are listed without color
%n@%m:%~%# echo $LS_OPTIONS
-F -b -T 0 --color=auto
%n@%m:%~%# zsh -l
josh@pts/0:~#  echo $LS_OPTIONS                                                            
-F -b -T 0 --color=auto
josh@pts/0:~#  ls                                                                        
-files are listed with color
josh@pts/0:~#  zsh -i      
josh@pts/0:~# ls
-files are listed without color                                                                
josh@pts/0:~#  echo $LS_OPTIONS
-F -b -T 0 --color=auto
josh@pts/0:~#
So at the moment, it does not work with a bash login shell, and while both interactive shells have LS_OPTIONS set correctly, neither of them output color by default when running ls
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Login and Interactive shells Josh000 Slackware 7 04-23-2010 09:02 AM
Interactive and non-interactive shells? Tim356 Linux - Newbie 7 11-05-2008 10:32 PM
Cannot set LD_LIBRARY_PATH in .cshrc (able to set other env variables) senthilpr_in Linux - Newbie 4 02-26-2007 12:46 PM
Need to set up online interactive spreadsheets. sdolin Linux - Newbie 1 04-13-2006 03:33 PM
Help with the currently set environment variables!! apoc013 Linux - Newbie 6 01-21-2004 01:28 AM


All times are GMT -5. The time now is 05:35 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration