Des scripts dans /etc/profile.d Être ignorés?

50

Je suis nouveau sur Ubuntu. J'utilise le bureau 13.10.

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

lien

Suivant les conseils de cet article, j’ai créé /etc/profiles.d/profile_local.sh. Il appartient à root et possède les autorisations de 644, tout comme les autres scripts de cet emplacement:

[email protected]:/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é. Toutefois, si, après la connexion, je source /etc.profile.d/profile_local.sh, le comportement attendu, mes alias personnalisés et mes invites personnalisées me sont fournis.

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 "3]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}
[email protected]:/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
7"' ;; screen) PROMPT_COMMAND='echo -ne "3_${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}3\"' ;; 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='\[3[01;31m\]\h\[3[01;34m\] \W \$\[3[00m\] ' else PS1='\[3[01;32m\]\[email protected]\h\[3[01;34m\] \w \$\[3[00m\] ' fi alias ls='ls --color=auto' alias grep='grep --colour=auto' else if [[ ${EUID} == 0 ]] ; then # show [email protected] when we don't have colors PS1='\[email protected]\h \W \$ ' else PS1='\[email protected]\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
    
posée Drew 23.03.2014 - 17:55
la source

3 réponses

92

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

  • Lorsque vous ouvrez un émulateur de terminal ( gnome-terminal par exemple), vous exécutez ce que l'on appelle un shell interactif, sans connexion .

  • 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 connexion interactive .

  • 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 vos identifiants. Alors que beaucoup de shells graphiques (y compris la valeur par défaut Ubuntu) liront /etc/profile , ce n’est pas tous.

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

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):

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of /etc/bash.bashrc and ~/.bashrc.

Cela signifie que vous éditez le mauvais fichier. Vous pouvez tester cela en accédant à une console virtuelle à l'aide de Ctrl + Alt + F2 (retournez dans l'interface graphique avec Alt + F7 ou F8 en fonction de votre configuration) et vous y connecter. Vous verrez que votre invite et vos alias sont disponibles.

Ainsi, pour que le paramètre souhaité soit appliqué 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 . Vous pouvez également placer vos alias dans le fichier ~/.bash_aliases (toutefois, il s’agit d’une fonctionnalité Ubuntu et vous ne devriez pas vous attendre à ce qu’elle fonctionne sur d’autres distributions).

Pour plus de détails sur les fichiers à utiliser, voir ici .

REMARQUES:

  • Debian (et par extension Ubuntu) a également la valeur par défaut ~/.profile source ~/.bashrc . Cela signifie que tous les changements que vous apporterez à ~/.bashrc seront également hérités 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 plutôt que ~/.profile ou /etc/profile .

  • De plus, 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. Spécifiquement, pour les shells de connexion, la commande est la suivante:

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

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

réponse donnée terdon 23.03.2014 - 18:39
la source
1

Une autre possibilité, en particulier pour les paramètres tels que les paramètres d’historique HISTSIZE , HISTFILESIZE , HISTCONTROL et 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 coupable le plus probable est ~/.bashrc . (J'ai un ensemble de paramètres par défaut pour nos serveurs, comme une invite rouge pour informer 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 peut-être été judicieux de définir un paramètre 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 ) l’utilisateur modifie son .bashrc , c’est bien de remplacer les paramètres, les fichiers système par défaut sont plus gênants)

    
réponse donnée Gert van den Berg 10.04.2018 - 10:02
la source
-1

VERSION="16.04.3 LTS (Xenial Xerus)"

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

En réalité, comme cela s’est passé avec Ubuntu, si vous utilisez ceci et que vous voulez que cela prenne effet dans votre shell graphique, il vous suffit de définir le fichier, puis de vous déconnecter, puis de revenir. Toutes vos consoles ou tout ce que vous lancez, qu’il s’agisse d’un type xterm ou d’une console (ou en passant au shell), aura désormais ce fichier sous-traité.

Inutile 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é, c’est faux, car tout ce que le gestionnaire de fenêtres lance héritera de ces paramètres. Il suffit donc de vous reconnecter et de résoudre votre problème. Ne vous embêtez pas avec .bashrc, etc. si vous souhaitez l’appliquer à tous les utilisateurs. .

    
réponse donnée Isaac Kane Egglestone 23.01.2018 - 23:21
la source

Lire d'autres questions sur les étiquettes