Should I put complex functionality in the shell login script or separate programs?

Question

I have quite a few simple functions that I had previously kept in my .profile but I decided to put them in Perl scripts and add aliases to the Perl scripts. I feel like this is a bad idea, but the functionality looks/is better in Perl than bash since it is fairly complex (involving floating point math etc.).

Are there any best practices for login scripts and/or functions that are being put in the PATH variable (concerning both security and system stability issues)? Do you distribute functionality outside of the login script for complex tasks, or do you have a monolithic login script?

I guess this can be distilled to just a question about the validity of login script refactoring, and if it's valid how it's usually done.

Answer 1

I have a complex structured profile - with a load of scripts being used. The main issue is boot-strapping the system across all the different environments where it is used - Solaris, Linux (misc h/w), HP-UX, AIX...

I use Korn shell - but the principles apply to bash (and it works fine with bash):

#!/bin/ksh
#
#   @(#)$Id: profile,v 6.8 2007/09/24 18:20:26 jleffler Exp $
#
#   Generic profile for Jonathan Leffler (JL)
#
#   Copyright (C) JLSS 1989-93,1995-99,2002,2005,2007

#TABSTOP=4

# Set machine-specific environment
mc=`uname -n`
if [ -r $HOME/.$mc ]
then
    . $HOME/.$mc
fi
unset mc

# Set basic environment
: ${INFORMIXDIR:=/usr/informix}         ; export INFORMIXDIR
: ${REAL_HOME:=$HOME}                   ; export REAL_HOME

# Machine-configurable PATH setting
for mcsetpath in ${REAL_HOME}/bin/mcsetpath ${HOME}/bin/mcsetpath
do
    if [ -r $mcsetpath ]
    then
        . $mcsetpath                    # Set PATH
        break;
    fi
done
unset mcsetpath

. libpath                               # Set LD_LIBRARY_PATH
. ttyset                                # Set STTY values
. kshrc                                 # Set KSH environment
. cdpath                                # Set CDPATH
. exinit                                # Set EXINIT
. termset                               # Set TERM type
. ixenviron                             # Set INFORMIX environment
. ccenviron                             # Set ClearCase environment
. setprompt                             # Set prompt
. manpath                               # Set MANPATH

umask 022

# Set group-specific environment
group=`id | sed 's/.* gid=[0-9]*(\([^)]*\)).*/\1/'`
if [ -f "$REAL_HOME/.$group" ]
then
    . $REAL_HOME/.$group
fi

# Set user-specific environment -- assume LOGNAME or USER set OK
# Beware Linux: by default, username = group name so things get done twice!
: ${LOGNAME:=${USER:-jleffler}}
export LOGNAME
if [ "$group" != "$LOGNAME" ] && [ -f "$REAL_HOME/.$LOGNAME" ]
then
    . $REAL_HOME/.$LOGNAME
else
    cd
    case "$-" in
    *c*)    : OK;;
    *)      echo "User $LOGNAME logged in to `pwd` at `date`";;
    esac
    trap "clear; exit 0" 0
fi
unset group

Answer 2

It depends entirely on the scope you intent these functions to have, and how you want them to interact with the rest of the system. You could go as far as putting them in /usr/local/bin (making them available to everyone) or as putting them in a special start-up script that you only invoke (explicitly) when you want them.

There is no "right answer" until you determine how you want to scope them, and then the right answer is "put them in the place that gives you the scope you want."

Answer 3

I personally have a scripts directory ~/.bin, add it to PATH in ~/.profile, and keep all my personal scripts in there. I have bashlib in there which is sourced by all my other scripts and by ~/.bashrc which contains all my convenience functions.

My ~/.profile contains only environment variables that I need defined (like PATH), and my ~/.bashrc contains shell initialization and a few functions/aliases that are too simplistic to put in the form of a script.

The links show you how I set up those files.

By the way, refer to http://mywiki.wooledge.org/DotFiles for a description of how exactly the shell initialization happens; and which types of things go in which files.