web-dev-qa-db-fra.com

Les scripts dans /etc/profile.d sont ignorés?

Je suis nouveau sur Ubuntu. J'exécute 13.10 Desktop.

Je voulais définir des alias 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/profiles.d/profile_local.sh. Il est la propriété de root et possède les autorisations de 644, tout comme les autres scripts de cet emplacement:

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 identifié. Cependant, si, après la connexion, je source /etc.profile.d/profile_local.sh, je reçois le comportement attendu, mes alias personnalisés et mon invite personnalisé.

Qu'est-ce que je fais 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
56
Drew

Pour comprendre ce qui se passe ici, vous devez comprendre un peu d'informations de base sur la manière dont les commandes (bash dans ce cas) sont exécutées.

  • Lorsque vous ouvrez un émulateur de terminal (gnome-terminal par exemple), vous exécutez un shell interactif, non connecté .

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

  • Lorsque vous vous connectez graphiquement, vous utilisez 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, c'est le shell graphique qui gère votre identifiant. De nombreux shells graphiques (y compris la configuration par défaut d’Ubuntu) liront /etc/profile, mais pas tous.

  • Enfin, lorsque vous exécutez un script Shell, celui-ci est exécuté dans un shell non interactif et non connecté .

Désormais, les fichiers que bash lira au lancement dépendent du type de shell sous lequel il est exécuté. Ce qui suit est un extrait de la section INVOCATION de man bash (l'emphase mienne):

Lorsque bash est appelé en tant que shell de connexion interactif , ou en tant que shell non interactif avec l'option --login, il commence par lire et exécuter les commandes du file /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 commandes du premier qui existe et est lisible. L'option --noprofile peut être utilisée au démarrage de Shell pour empêcher ce comportement.

Lorsqu'un shell interactif qui est n'est pas un shell de connexion est lancé, bash lit et exécute les commandes de /etc/bash.bashrc et de ~/.bashrc , si ces fichiers existent. Cela peut être inhibé en utilisant l'option --norc. L'option de fichier --rcfile forcera bash à lire et à exécuter des commandes à partir du fichier au lieu de /etc/bash.bashrc et ~/.bashrc.

Tout ce que cela signifie, c'est que vous éditez le mauvais fichier. Vous pouvez tester cela en passant à une console virtuelle en utilisant Ctrl+Alt+F2 (retournez à l'interface graphique avec Alt+F7, ou F8 selon votre configuration) et vous y connecter. Vous verrez que votre invite et vos alias sont disponibles.

Par conséquent, afin d'appliquer le paramètre souhaité aux shells ne se connectant pas, le type que vous obtenez à chaque fois que vous ouvrez un terminal, vous devez plutôt apporter vos modifications à ~/.bashrc. Alternativement, vous pouvez également placer vos alias dans le fichier ~/.bash_aliases (notez toutefois qu'il s'agit d'une fonctionnalité Ubuntu et que vous ne devriez pas vous attendre à ce qu'il fonctionne sur d'autres distributions).

Pour plus de détails sur le fichier à utiliser pour quoi, voir ici .


REMARQUES:

  • Debian (et par extension Ubuntu) a également la valeur par défaut ~/.profile source ~/.bashrc. Cela signifie que toutes les modifications que vous apportez à ~/.bashrc seront également héritées par les shells de login, mais i) ce n'est pas le cas sur toutes les machines Linux/Unix et ii) l'inverse n'est pas vrai, raison pour laquelle vous devriez généralement toujours travailler avec ~/.bashrc & co que ~/.profile ou /etc/profile.

  • En outre, une remarque générale sur l'utilisation, les modifications apportées aux fichiers de configuration dans /etc affectera tous les utilisateurs . Ce n'est généralement pas ce que vous voulez faire et devrait être évité. Vous devez toujours utiliser les fichiers équivalents dans votre répertoire personnel (~/).

  • Les différents fichiers de configuration sont lus de manière séquentielle. Plus précisément, pour les shells de connexion, la commande est la suivante:

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

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

102
terdon

Suivez ce chemin:

  • Ouvrez Édition -> Préférences
  • Dans le premier onglet "Général", sous le libellé "Commande", activez "Exécuter la commande en tant que login Shell".
1
Mac

Une autre possibilité, en particulier pour les paramètres tels que les paramètres d'historique HISTSIZEname__, HISTFILESIZEname__, HISTCONTROLet PS1 est que les fichiers sont en cours de chargement, mais les paramètres sont écrasés dans un autre fichier source ultérieurement, avec le code source le plus probable, ~/.bashrc. (J'ai un ensemble de paramètres par défaut pour nos serveurs, comme une invite rouge pour la racine afin d'avertir l'utilisateur et des historiques volumineux avec horodatage)

La valeur par défaut Ubuntu .bashrc de /etc/skel définit plusieurs paramètres, ce qui aurait pu-être judicieux de définir un emplacement 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 correct de remplacer les paramètres). , les fichiers système par défaut sont plus agaçants)

1
Gert van den Berg

dans Debian pour Terminal Session, j’ai résolu ce problème pour tous les utilisateurs:

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
0
Nikolay Baranenko