0 votes

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

J'ai plusieurs fonctions simples que j'avais précédemment conservées dans mon .profil, mais j'ai décidé de les mettre dans des scripts Perl et d'ajouter des alias aux scripts Perl. J'ai l'impression que c'est une mauvaise idée, mais la fonctionnalité semble être meilleure en Perl qu'en bash car elle est assez complexe (impliquant des opérations mathématiques en virgule flottante, etc.).

Y a-t-il des bonnes pratiques pour les scripts de connexion et/ou les fonctions qui sont ajoutées 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 avez-vous un script de connexion monolithique ?

Je suppose que cela peut être résumé à une question sur la validité de la refonte du script de connexion, et si c'est valide, comment cela est généralement fait.

2voto

lhunath Points 27045

Personnellement, j'ai un répertoire de scripts ~/.bin, je l'ajoute à PATH dans ~/.profile, et j'y garde tous mes scripts personnels. J'ai bashlib dedans qui est sourcé par tous mes autres scripts et par ~/.bashrc qui contient toutes mes fonctions de commodité.

Mon ~/.profile contient uniquement des variables d'environnement dont j'ai besoin définies (comme PATH), et mon ~/.bashrc contient l'initialisation de l'interpréteur de commandes et quelques fonctions/alias trop simplistes pour être mis sous forme de script.

Les liens vous montrent comment j'ai configuré ces fichiers.

Par ailleurs, référez-vous à http://mywiki.wooledge.org/DotFiles pour une description de la façon dont se déroule exactement l'initialisation de l'interpréteur de commandes; et quels types de choses vont dans quels fichiers.

1voto

Jonathan Leffler Points 299946

Je possède un profil structurel complexe - avec une foule de scripts en cours d'utilisation. Le principal problème est de démarrer le système sur tous les environnements différents où il est utilisé - Solaris, Linux (matériel divers), HP-UX, AIX...

J'utilise le shell Korn - mais les principes s'appliquent à bash (et fonctionnent bien avec bash) :

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

#TABSTOP=4

# Définir l'environnement spécifique à la machine
mc=`uname -n`
if [ -r $HOME/.$mc ]
then
    . $HOME/.$mc
fi
unset mc

# Définir l'environnement de base
: ${INFORMIXDIR:=/usr/informix}         ; export INFORMIXDIR
: ${REAL_HOME:=$HOME}                   ; export REAL_HOME

# Réglage du chemin d'accès configurable par machine
for mcsetpath in ${REAL_HOME}/bin/mcsetpath ${HOME}/bin/mcsetpath
do
    if [ -r $mcsetpath ]
    then
        . $mcsetpath                    # Définir le chemin d'accès
        break;
    fi
done
unset mcsetpath

. libpath                               # Définir LD_LIBRARY_PATH
. ttyset                                # Définir les valeurs STTY
. kshrc                                 # Définir l'environnement KSH
. cdpath                                # Définir CDPATH
. exinit                                # Définir EXINIT
. termset                               # Définir le type TERM
. ixenviron                             # Définir l'environnement INFORMIX
. ccenviron                             # Définir l'environnement ClearCase
. setprompt                             # Définir l'invite
. manpath                               # Définir MANPATH

umask 022

# Définir l'environnement spécifique au groupe
group=`id | sed 's/.* gid=[0-9]*(\([^)]*\)).*/\1/'`
if [ -f "$REAL_HOME/.$group" ]
then
    . $REAL_HOME/.$group
fi

# Définir l'environnement spécifique à l'utilisateur -- supposer que LOGNAME ou USER est correctement défini
# Attention Linux : par défaut, le nom d'utilisateur = nom de groupe donc les tâches sont effectuées deux fois !
: ${LOGNAME:=${USER:-jleffler}}
export LOGNAME
if [ "$group" != "$LOGNAME" ] && [ -f "$REAL_HOME/.$LOGNAME" ]
then
    . $REAL_HOME/.$LOGNAME
else
    cd
    case "$-" in
    *c*)    : OK;;
    *)      echo "Utilisateur $LOGNAME connecté à `pwd` à `date`";;
    esac
    trap "clear; exit 0" 0
fi
unset group

1voto

MarkusQ Points 15612

Cela dépend entièrement de la portée que vous voulez donner à ces fonctions et de la manière dont vous voulez qu'elles interagissent avec le reste du système. Vous pourriez aller jusqu'à les placer dans /usr/local/bin (les rendant ainsi disponibles à tous) ou les placer dans un script de démarrage spécial que vous n'invoquez que (explicitement) lorsque vous en avez besoin.

Il n'y a pas de "bonne réponse" tant que vous n'avez pas déterminé la portée que vous voulez leur donner, et alors la bonne réponse est "placez-les là où vous obtiendrez la portée souhaitée".

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X