Choice is wonderful

There has been so much arguing about pros and cons of open source, I'm not going to start now. Developers and system architects having choice in selecting programs and having the Linus-given right to modify them and adjust them to their need is all truly great.

It may, however, give the rest of us headaches when trying to adjust our understanding of a command or program behaviour.

Take the login program. Originated quite early in the UNIX evolution. Linux implementation (look at the bottom of man login) refers to:
'BSD login 5.40 (5/9/89) by Michael Glad (glad@daimi.dk) for HP-UX.
Ported to Linux 0.12: Peter Orbaek (poe@daimi.aau.dk)'.

Both SuSE and Red Hat derivatives use this version of the program. However, if you are SuSE user, there is one more credit line you can see there:
'Added new features: ThorstenKukuk (kukuk@suse.de)'.

I have only realised that, when hours of trying and trying to make the /etc/securetty file work consistently failed, and I was reaching that well know to me desparation state.

In manual pages, under SPECIAL ACCESS RESTRICTIONS, where the behaviour of the two standard access files (securetty and usertty) are described, the behaviour of the securetty file is described, but on closer inspection, in the DESCRIPTION section it's stated:
'This login implementation does ignore /etc/nologin and /etc/securetty. You need to configure this in the PAM configuration file for login...' .

Why? Obviously the assumption is made that PAM ought to run at all times - a very sensible advice. But why force people? The worse implication to me is that if administrator decides to leave the PAM configuration out of the equation, the simple system access configuration is then missing altogether...

Apart of anything, it means that I cannot have an exercise in the 'generic' Linux course that can be done on both distributions. How annoying!

I'm not going to throw it out, though. It will act as a reminder for all of us, not to become complacent.

This is the beauty of UNIX and Linux - always keep you on your toes, make you test all solutions on every new platform, force you to test-run every script or program you want to port...

Which shell?

Finding which shell you are currently using is not difficult, the ps command can tell you this easily. However, if you are using several shells, identifying the current one can be rather involving, may require ps -f, to make sure that you are looking at the last one executed. his method has one inherent problem - relies on human ability to deduce the desired result. Approach very much prone to mistakes!

Whenever possible make the system do the hard work for you. We know that the current process ID is stored in the environmental variable $. You can therefore always check what the PID of the current shell is with:

$ echo $$

PID itself does not tell you which shell this is (if you have a mix of ksh, bash or any other you are still nonthewiser which one of them corresponds to the PID). Yyou can find the name of the process name ellegantly by interrogating the /proc filesystem, which stores all process information (in both UNIX and Linux, but on Linux has also all sorts of other hardware information).

Still using a reference to the $ variable, look in the /proc for the name of the corresponding program:

$ ls -l /proc/$$/exe

lrwxrwxrwx . . . /proc/25541/exe -> /bin/bash

If this is something you need to execute regularly, you can always create a little function and place it in one of the environmental files...