78 votes

Pourquoi les scripts dans /etc/profile.d/ sont-ils ignorés (alias bash à l'échelle du système) ?

Je suis nouveau sur Ubuntu. J'utilise la version 13.10 Desktop.

Je voulais définir des alias pour l'ensemble du système et une invite personnalisée pour bash. J'ai trouvé cet article :

https://help.ubuntu.com/community/EnvironmentVariables

En suivant les conseils de cet article, j'ai créé /etc/profile.d/profile_local.sh. Il appartient à root et a des permissions de 644 tout comme les autres scripts qui s'y trouvent :

root@ubuntu:/etc/profile.d# ll
total 28
drwxr-xr-x   2 root root  4096 Mar 23 08:56 .
drwxr-xr-x 135 root root 12288 Mar 23 09:15 ..
-rw-r--r--   1 root root   660 Oct 23  2012 bash_completion.sh
-rw-r--r--   1 root root  3317 Mar 23 07:36 profile_local.sh
-rw-r--r--   1 root root  1947 Nov 23 00:57 vte.sh

J'ai également confirmé que /etc/profile appelle /etc/profile.d. Il contient ce bloc de code :

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

Lors de la connexion, il ne semble pas que le script personnalisé, profile_local.sh que j'ai créé soit sourcé. Cependant, si après la connexion je "source /etc.profile.d/profile_local.sh", j'obtiens le comportement attendu, mes alias personnalisés et mon invite personnalisée.

Qu'est-ce que je fais de mal ?

Contenu du script 'profile_local.sh' :

# 3/23/14 - Copied from Gentoo /etc/bash/bashrc
# Placed in /etc/profile.d as described at:
# https://help.ubuntu.com/community/EnvironmentVariables

# This file is sourced by all *interactive* bash shells on startup,
# including some apparently interactive shells such as scp and rcp
# that can't tolerate any output.  So make sure this doesn't display
# anything or bad things will happen !

# Test for an interactive shell.  There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
        # Shell is non-interactive.  Be done now!
        return
fi

# Bash won't get SIGWINCH if another process is in the foreground.
# Enable checkwinsize so that bash will check the terminal size when
# it regains control.  #65623
# http://cnswww.cns.cwru.edu/~chet/bash/FAQ (E11)
shopt -s checkwinsize

# Enable history appending instead of overwriting.  #139609
shopt -s histappend

# Change the window title of X terminals 
case ${TERM} in
        xterm*|rxvt*|Eterm|aterm|kterm|gnome*|interix)
                PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}\007"'
                ;;
        screen)
                PROMPT_COMMAND='echo -ne "\033_${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}\033\\"'
                ;;
esac

use_color=false

# Set colorful PS1 only on colorful terminals.
# dircolors --print-database uses its own built-in database
# instead of using /etc/DIR_COLORS.  Try to use the external file
# first to take advantage of user additions.  Use internal bash
# globbing instead of external grep binary.
safe_term=${TERM//[^[:alnum:]]/?}   # sanitize TERM
match_lhs=""
[[ -f ~/.dir_colors   ]] && match_lhs="${match_lhs}$(<~/.dir_colors)"
[[ -f /etc/DIR_COLORS ]] && match_lhs="${match_lhs}$(</etc/DIR_COLORS)"
[[ -z ${match_lhs}    ]] \
        && type -P dircolors >/dev/null \
        && match_lhs=$(dircolors --print-database)
[[ $'\n'${match_lhs} == *$'\n'"TERM "${safe_term}* ]] && use_color=true

if ${use_color} ; then
        # Enable colors for ls, etc.  Prefer ~/.dir_colors #64489
        if type -P dircolors >/dev/null ; then
                if [[ -f ~/.dir_colors ]] ; then
                        eval $(dircolors -b ~/.dir_colors)
                elif [[ -f /etc/DIR_COLORS ]] ; then
                        eval $(dircolors -b /etc/DIR_COLORS)
                fi
        fi

        if [[ ${EUID} == 0 ]] ; then
                PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] '
        else
                PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] '
        fi

        alias ls='ls --color=auto'
        alias grep='grep --colour=auto'
else
        if [[ ${EUID} == 0 ]] ; then
                # show root@ when we don't have colors
                PS1='\u@\h \W \$ '
        else
                PS1='\u@\h \w \$ '
        fi
fi

# Try to keep environment pollution down, EPA loves us.
unset use_color safe_term match_lhs

TZ="PST8PDT"

alias ll='ls -la'
alias dig='dig +search'
alias dir='ls -ba'

alias edit="ee"
alias ss="ps -aux"
alias dot='ls .[a-zA-Z0-9_]*'
alias news="xterm -g 80x45 -e trn -e -S1 -N &"

alias more="less"
alias c="clear"
alias m="more"
alias j="jobs"

# common misspellings
alias mroe=more
alias pdw=pwd

136voto

Stewart Points 1385

Pour comprendre ce qui se passe ici, vous devez comprendre quelques informations de base sur la façon dont les shells (bash dans ce cas) sont exécutés.

  • Lorsque vous ouvrez un émulateur de terminal ( gnome-terminal par exemple), vous exécutez ce qui est connu sous le nom de interactif, sans connexion Shell.

  • Lorsque vous vous connectez à votre machine à partir de la ligne de commande, via ssh ou exécutez une commande telle que su - username vous exécutez un connexion interactive Shell.

  • Lorsque vous vous connectez graphiquement, vous exécutez quelque chose de complètement différent. Les détails dépendront de votre système et de votre environnement graphique mais, en général, il s'agit de l'élément suivant Shell graphique qui traite de votre connexion. Alors que de nombreux shells graphiques (y compris celui par défaut d'Ubuntu) liront /etc/profile pas tous.

  • Enfin, lorsque vous exécutez un Shell Shell, celui-ci est exécuté dans un fichier non-interactif, non-login Shell .

Maintenant, les fichiers que bash lira lors de son lancement dépendent du type de Shell sous lequel il s'exécute. Ce qui suit est un extrait de la section INVOCATION de la commande man bash (c'est moi qui souligne) :

Lorsque bash est invoqué en tant que connexion interactive Shell ou comme un Shell non interactif avec l'option --login, il lit et exécute d'abord les commandes du fichier /etc/profile si ce fichier existe. Après avoir lu ce fichier, il recherche ~/.bash_profile, ~/.bash_login, et ~/.profile, dans cet ordre et lit et exécute les commandes de la première d'entre elles qui existe et est lisible. L'option --noprofile peut être utilisée lorsque la commande Shell est lancé pour inhiber ce comportement.

Lorsqu'un interactif Shell c'est-à-dire pas un login Shell est lancé, bash lit et exécute les commandes de /etc/bash.bashrc y ~/.bashrc si ces fichiers existent. Ceci peut être empêché en utilisant l'option --norc. L'option --rcfile file forcera Bash à lire et exécuter les commandes à partir du fichier à partir du fichier au lieu de /etc/bash.bashrc et ~/.bashrc.

Ce que tout cela signifie, c'est que vous éditez le mauvais fichier. Vous pouvez tester cela en vous rendant dans une console virtuelle en utilisant Ctrl + Alt + F2 (retour à l'interface graphique avec Alt + F7 または F8 en fonction de votre configuration) et connectez-vous à cet endroit. Vous verrez que votre invite et vos alias sont disponibles.

Ainsi, pour que le paramètre que vous souhaitez appliquer aux shells sans login, le type que vous obtenez chaque fois que vous ouvrez un terminal, vous devez effectuer vos modifications à l'adresse suivante ~/.bashrc à la place. Alternativement, vous pouvez également placer vos alias dans le fichier ~/.bash_aliases (cependant, notez que c'est une fonctionnalité d'Ubuntu et que vous ne devez pas vous attendre à ce qu'elle fonctionne sur d'autres distributions).

Pour plus de détails sur quel fichier doit être utilisé pour quoi, voir aquí .


NOTES :

  • Debian (et par extension Ubuntu) possède également le paramètre par défaut ~/.profile source ~/.bashrc . Cela signifie que toute modification apportée à ~/.bashrc sera également hérité par les shells de connexion mais i) ce n'est pas le cas sur toutes les machines Linux/Unix et ii) l'inverse n'est pas vrai, c'est pourquoi vous devriez généralement toujours travailler avec ~/.bashrc &co plutôt que ~/.profile o /etc/profile .

  • De plus, une note générale sur l'utilisation, les changements apportés aux fichiers de configuration dans le dossier /etc affectera tous utilisateurs. Ce n'est généralement pas ce que vous voulez faire et il faut l'éviter. Vous devriez toujours utiliser les fichiers équivalents dans votre répertoire personnel ( ~/ ).

  • Les différents fichiers de configuration sont lus séquentiellement. Plus précisément, pour les shells de connexion, l'ordre est le suivant :

    /etc/profile -> /etc/profile.d/* (in alphabetical order) -> ~/.bash_profile -> ~/.bash_login -> ~/.profile

    Cela signifie que tout paramètre dans ~/.profile écrasera tout ce qui a été défini dans les fichiers précédents.

10voto

Nikolay Baranenko Points 275

Dans Debian pour la session Terminal j'ai résolu ce problème pour tous les utilisateurs ainsi :

ajouté à

sudo nano /etc/bash.bashrc

bloc

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

de

/etc/profile

3voto

Mac Points 31

Suivez ce chemin :

  • Ouvrez Edit -> Preferences
  • Dans le premier onglet "Général", sous l'étiquette "Commande", activez "Exécuter la commande comme login Shell".

2voto

JustJeff Points 6070

Une autre possibilité, surtout pour des paramètres comme ceux de l'historique HISTSIZE , HISTFILESIZE , HISTCONTROL et PS1 est que les fichiers sont chargés, mais que les paramètres sont écrasés dans un autre fichier qui est source plus tard, le coupable le plus probable étant ~/.bashrc . (J'ai un ensemble de paramètres par défaut pour nos serveurs, comme une invite qui est rouge pour la racine pour avertir l'utilisateur et de grands historiques avec des horodatages).

La version par défaut d'Ubuntu .bashrc de /etc/skel définit plusieurs paramètres, qu'il aurait pu être judicieux de définir à partir d'un endroit où il ne remplacerait pas les paramètres définis par le propriétaire du système à partir de /etc/profile.d (Comme /etc/bash.bashrc ) (Si un utilisateur modifie son .bashrc il est possible d'écraser les paramètres, les fichiers par défaut du système sont plus gênants).

-1voto

VERSION="16.04.3 LTS (Xenial Xerus)"

Bon, tout le monde a supposé que la personne ici présente ne voulait pas de /etc/profile.d/somefile.sh pour tous les utilisateurs, mais dans mon cas, c'est exactement ce que je voulais.

Donc en fait, il s'avère qu'avec Ubuntu, si vous utilisez ceci et que vous voulez que cela prenne effet dans votre Shell graphique, tout ce que vous avez à faire est de définir le fichier, puis de vous déconnecter et de vous reconnecter. Toutes vos consoles ou tout ce que vous lancez que ce soit de type xterm ou de type console (ou en tombant sur le Shell) aura maintenant ce fichier sourcé.

Il n'est pas nécessaire d'utiliser .bashrc etc. pour tous les utilisateurs. Désolé, ce n'était pas clair dans la réponse ci-dessus. Tout ce qu'ils ont dit est vrai mais en réalité, ce n'est pas vrai car tout ce que le gestionnaire Windows lance hérite de ces paramètres. Il suffit donc de se reconnecter et de résoudre votre problème et de ne pas s'embêter avec .bashrc etc. si votre intention est de l'appliquer à tous les utilisateurs.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X