I'd like to share some thoughts I have on /etc/profile in the hopes that I can interest the devs in a little bit of a clean-up. I know Robby has already taken an interest in my idea about enumerating the files within profile.d/ but this is more about the contents of the profile file itself. Anyway, enough of the preamble... Lets start at the top and work our way down...

READLINE INPUTRC:

Code:

# If the user doesn't have a .inputrc, use the one in /etc.
if [ ! -r "$HOME/.inputrc" ]; then
  export INPUTRC=/etc/inputrc
fi

... according to the readline(3) manpage, that is default behaviour when the environment variable is unset, so this section is redundant and can safely go.

DEFAULT PATH:

Code:

# Set the default system $PATH:
PATH="/usr/local/bin:/usr/bin:/bin:/usr/games"

# For root users, ensure that /usr/local/sbin, /usr/sbin, and /sbin are in
# the $PATH.  Some means of connection don't add these by default (sshd comes
# to mind).
if [ "`id -u`" = "0" ]; then
  echo $PATH | grep /usr/local/sbin 1> /dev/null 2> /dev/null
  if [ ! $? = 0 ]; then
    PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH
  fi
fi

... why are we bothering to 'grep /usr/local/sbin' when we know that PATH won't contain it because we've just explicitly set it on the statement above?
So, instead how about a simple:

Code:

# Set the default system $PATH:
PATH="/usr/local/bin:/usr/bin:/bin:/usr/games"
if [ "$(id -u)" = "0" ]; then
  PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH
fi

TERMINAL TYPE $TERM:

Code:

# I had problems with the backspace key using 'eval tset' instead of 'TERM=',
# but you might want to try it anyway instead of the section below it.  I
# think with the right /etc/termcap it would work.
# eval `tset -sQ "$TERM"`

# Set TERM to linux for unknown type or unset variable:
if [ "$TERM" = "" -o "$TERM" = "unknown" ]; then
 TERM=linux
fi

... I'm not sure forcing $TERM to 'linux' is the best idea when it is unset or unknown ('dumb' maybe, but not 'linux'). Anyway, TERM is set by the getty process controlling the tty or passed from the client end of a ssh connection, so this section is unlikely to ever run. I'd suggest removing this section completely.

KSH93 $VISUAL:

Code:

# Set ksh93 visual editing mode:
if [ "$SHELL" = "/bin/ksh" ]; then
  VISUAL=emacs
#  VISUAL=gmacs
#  VISUAL=vi
fi

... firstly, $SHELL is a poor indicator of which shell is actually running /etc/profile. A fix for the inaccurate $SHELL issue would be something like

Code:

case "$0" in
  -ksh|ksh|*/ksh )  VISUAL=emacs ;;  
esac

... but IMO this would be better left to a set -o emacs in the users ~/.kshrc so again, I suggest this section is removed.

SHELL PROMPTS (PS1/PS2):

Code:

# Set a default shell prompt:
#PS1='`hostname`:`pwd`# '
if [ "$SHELL" = "/bin/pdksh" ]; then
 PS1='! $ '
elif [ "$SHELL" = "/bin/ksh" ]; then
 PS1='! ${PWD/#$HOME/~}$ '
elif [ "$SHELL" = "/bin/zsh" ]; then
 PS1='n@%m:%~%# '
elif [ "$SHELL" = "/bin/ash" ]; then
 PS1='$ '
else
 PS1='\u@\h:\w\$ '
fi
PS2='> '
export PATH DISPLAY LESS TERM PS1 PS2

... Ok, a number of issues on this one. Firstly, as with KSH VISUAL above, it's relying on $SHELL. That's easy enough to fix with a similar case statement arrangement as used above, however, exporting of PS1 and PS2 is problematic as it can result in garbled prompt strings when a user starts one type of shell from within another, so, I'd suggest not exporting at all and just having:

Code:

# Set a default shell prompt:
case "$0" in
  -bash|bash|*/bash )     PS1='\u@\h:\w\$ '  ;;
  -pdksh|pdksh|*/pdksh )  PS1='! $ '  ;;
  -ksh|ksh|*/ksh )        PS1='! ${PWD/#$HOME/~}$ '  ;;
  -zsh|zsh|*/zsh )        PS1='%n@%m:%~%# '  ;;
  *)                      PS1='$ '  ;;
esac

While were talking about the 'export', PATH, DISPLAY and TERM will already be in the environment, and LESS is exported higher up in profile, so there's no reason to export them again and that entire export line can be removed.

My personal preferences would be to leave prompt setting entirely to the likes of ~/.bashrc, but that's probably going to be a step too far, so I won't go as far as suggesting that section be removed completely.

Ok, last one...
BIFF:

Code:

# Notify user of incoming mail.  This can be overridden in the user's
# local startup file (~/.bash.login or whatever, depending on the shell)
if [ -x /usr/bin/biff ]; then
 biff y 2> /dev/null
fi

biff user fd2 to determine what tty it is on, so by redirecting 2>/dev/null, it breaks it, as can be seen here:

Code:

test:~$ biff
is n
test:~$ biff y 2>/dev/null
test:~$ biff
is n
test:~$ biff y
test:~$ biff
is y
test:~$

... As modern shells have their own mail notifications built-in, and no one really uses biff/comsat these days, rather than fixing it, I'll propose that this section also be removed from profile.

And that's it. I'm done... I hope you've enjoyed this episode of "A walk through etc/profile with GazL".

Quite enjoyable indeed good sir! Motion for sticky, and applied today. The shell fixes cleared up a few issues actually as described. Good job as always GazL.

Awesome

@Gazl: while you are at it, could you have a look at /etc/profile in Slackware-current's installer as of today (attached)?

The only change from version 14.1 is that now the user can set the default TERM entry by specifying TERM=<name> as a kernel command line parameter.

FYI I also attach /etc/inittab from -current as of today (used by busybox' init), that adds killing the dropbear server when shutting down the installer.

What puzzles me are all these paths beginning with /mnt: they are supposed to ease running binaries from the target system (the target root partition is usually mounted during installation as /mnt), but that often fails for a lack the dependencies, for instance if I run nano that tells me it can't find libmagic.so.1 (indeed it is not shipped in the installer). So I prefer to chroot /mnt, at least to fiddle with the target system. What do you think?

Attached Files

	profile.txt (1.0 KB, 31 views)
	inittab.txt (1.3 KB, 32 views)

I see what you mean about the paths: It's all well and good having the commands in the path, but as you say, without the libraries and other bits they depend on not everything is going to run that way. Presumably its been done like that for a specific purpose, but I don't know what it is.

As for setting TERM, I think the key difference is that the install system starts /bin/sh directly on the tty, without using a getty, so there's nothing to pre-set $TERM. I'm not sure what parsing the kernel cmdline buys you over just asking the user for it at the tty when profile runs, but there's probably a reason they've done it like that. Possibly in order to support a non-interactive but still ncurses based install process, but who knows, I'm just guessing.

The installer environment is not really something I'm all that familiar with though, so I'm probably not the best person to be asking.

1 members found this post helpful.

It seems to me this is intended to make future maintenance simpler; the initial default PATH can be modified without concern about shortsheeting root's PATH. Also, while the default appears immediately before this test of its value currently, in the future there might be code inserted which separates them.


Wouldn't that cause problems should /etc/profile be sourced from a script (e.g., /etc/kde/kdm/Xsession) as $0 would be the script's name?

Would that be to allow for install-time dependencies of one package on another? For example, if the doinst.sh of package 'bar' needs to invoke a command that was installed by package 'foo'.

1 members found this post helpful.

IMO it's unlikely that they'd be separated. I'd take your side if PATH was set in /etc/environment or the code to add the 'sbin' dirs was in a member of profile.d/ but as it is, it seems kind of unnecessary.

/etc/profile was never intended to be sourced, so neither "$SHELL" or "$0" are entirely trustworthy in that situation, and it's probably best to remove any shell variant specific stuff from /etc/profile entirely and just stick with basic bourne shell stuff in there.

This specific example won't cause any problems as leaving VISUAL unset will have no impact on X at all. If it bothered you though you could remove the conditional completely and just have VISUAL=emacs up near the other miscellaneous environment variables like MINICOM=... and LESS=...

Personally, I'd remove both the setting of VISUAL and of the prompt strings to the likes of .bashrc, .kshrc and so on, where they belong.


BTW, while we're on the subject. I've also replaced my Xsession as I didn't like the shipped one.

Take a quick look at Xsession with me:
... so first it sources /etc/profile and ~/.profile

... and then it invokes the shell again with the --login option which will run through /etc/profile a second time just to echo and capture the $PATH, which we should already have because we just sourced profile! That's not a clean and efficient way to start X.

Rather than source /etc/profile, my Xsession will source only the X specific variants /etc/xprofile and ~/.xprofile. I find this much cleaner and more efficient than the stock one. Of course, this does mean creating and maintaining an /etc/xprofile, but I'd rather do that than the stuff I mentioned above.

Well, I don't know. However if there are few missing dependencies one can just make symlinks after all. For instance I just did from the installer That worked.

I think that can come handy, as that allows to directly set TERM in the command line when launching the installer, and also maybe in some cases of headless installation (in the latter case modifying e.g. /isolinux/isolinux.cfg then rebuilding the ISO).

By the way I just noticed that now in Slackware-current's installer some terminfo definitions have been added, e.g. for screen, and even xterm. We don't have the screen binary nor an X server in the installer yet, though

PS instead of checking the presence of "TERM=" in the command line, one could just check that TERM be not already set, as parameters set in the command line are already available everywhere, IOW exported system-wide.

Maybe you are right. Removing all paths that begin with /mnt and see what happens would be a way to check. Anyhow having these additional paths doesn't hurt, I was just curious.

I don't have the ability to pull the installer apart right now but you guys might want to think about the way the libs are pulled in instead of ripping out the /mnt/* from the path

I don't get well what you mean writing "the way the libs are pulled in" (blame my bad command of English). Anyway in the installer all libraries are in /lib, just cherry-picked from their respective packages in a stock Slackware I guess.

Anyway I think that the /mnt/* parts of the path don't hurt at all and can come handy, but if one would want to get rid of them after booting the installer and once logged in as root that's easy:Do that at your own risks.

I could have put it better ....

What I mean is the way libraries are linked in at runtime, normally there is a cache file that the loader uses to work out where things are but your not going to have access to that on the installer.

This man page might help :-
http://man7.org/linux/man-pages/man8/ld.so.8.html

Setting LD_LIBRARY_PATH might be a way to help things on the install disks but Pat may already be using it it some fashion and even if he isn't it would be a good idea to clear it again within the install scripts as unwanted interactions could occur.

1 members found this post helpful.

I don't know how the original topic of dissecting the user profile configuration deranged into a discussion to change how the Slackware installer works?
Also, what makes the topic so pertinent that it deserves to be stickied? And if this needs to be a sticky, I think at least the topic should be respected.

2 members found this post helpful.

I'm inclined to agree. I was somewhat surprised to find it stickied. I'm glad some folk have found it interesting/useful, but it was just supposed to be a bit of transient feedback for Pat and team.

I'll report myself and ask for it to be de-stickied. The thread seems to have been hijacked anyway.

The thread has now returned to being a normal LQ thread Complete with thread jack to make it completely authentic.