Dois-je mettre des fonctionnalités complexes dans le script de connexion du shell ou dans des programmes séparés?

Question

J'ai quelques fonctions simples que j'avais précédemment conservées dans mon .profile mais j'ai décidé de les mettre dans des scripts Perl et d'ajouter des alias aux scripts Perl. Je pense que c'est une mauvaise idée, mais la fonctionnalité semble/est meilleure en Perl que bash car elle est assez complexe (impliquant des calculs en virgule flottante, etc.).

Existe-t-il des bonnes pratiques pour les scripts de connexion et/ou les fonctions qui sont placés dans la variable PATH (concernant à la fois la sécurité et les problèmes de stabilité du système)? Distribuez-vous des fonctionnalités en dehors du script de connexion pour les tâches complexes ou disposez-vous d'un script de connexion monolithique? Je suppose que cela peut être distillé à une question sur la validité du refactoring de script de connexion, et si c'est valide comment c'est généralement fait.

Answer 1

J'ai personnellement un répertoire de scripts ~/.bin, je l'ajoute à PATH au ~/.profile, et je garde tous mes scripts personnels dedans. J'ai bashlib là qui provient de tous mes autres scripts et par ~/.bashrc qui contient toutes mes fonctions de commodité. Mon ~/.profile contient uniquement les variables d'environnement que j'ai besoin de définir (comme PATH), et mon ~/.bashrc contient l'initialisation du shell et quelques fonctions/alias qui sont trop simplistes à mettre sous la forme d'un script.

Les liens vous montrent comment configurer ces fichiers. Soit dit en passant, référez-vous à http://mywiki.wooledge.org/DotFiles pour une description de comment exactement l'initialisation du shell arrive; et quels types de choses vont dans quels fichiers.

Answer 2

J'ai un profil structuré complexe - avec une charge de scripts utilisés. Le problème principal est le démarrage du système dans tous les différents environnements où il est utilisé - Solaris, Linux (divers h/w), HP-UX, AIX ...

J'utilise le shell Korn - mais les principes s'appliquent bash (et il fonctionne très bien avec 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 3

cela dépend entièrement de la portée vous avez l'intention de ces fonctions d'avoir, et comment vous les voulez interagir avec le reste du système. Vous pouvez aller aussi loin que les placer dans/usr/local/bin (en les mettant à la disposition de tous) ou les placer dans un script de démarrage spécial que vous invoquez uniquement (explicitement) quand vous le voulez.

Il n'y a pas de "bonne réponse" tant que vous n'avez pas déterminé comment vous voulez les définir, et la bonne réponse est "placez-les à l'endroit qui vous donne la portée souhaitée".