Où dois-je exporter une variable d'environnement pour que toutes les combinaisons de bash / dash, interactif / non interactif, connecté / non connecté, la récupèrent?

Voici la motivation de la question:

J'utilise Ubuntu 12.04 LTS 2 avec le bureau Unity. Dans mon fichier .bashrc, j'ajoute plusieurs répertoires à ma variable PATH et je définis quelques variables d'environnement, telles que JAVA_HOME. Lorsque je lance des applications à partir d'un terminal (exécutant bash, mon shell par défaut), cela fonctionne très bien, mais pour plusieurs des raccourcis qui utilisent le lanceur Unity, ils exécutent des applications qui semblent définies pour utiliser #! / Bin / sh, qui est aliasé vers / bin / dash, et ils ne récupèrent pas le contenu de ~ / .bashrc ou ~ / .profile.

Je suppose que je pourrais changer tous ces raccourcis pour utiliser / bin / bash au lieu de / bin / sh pour le forcer à reprendre les modifications de .bashrc, mais cela semble vraiment hacky.

Étant donné qu'Ubuntu 12.04 (par défaut) alias / bin / sh vers / bin / dash et que mon shell par défaut est / bin / bash, existe-t-il un seul endroit où je peux choisir de modifier le CHEMIN et définir des variables d'environnement si je les veux être présent dans toutes ces circonstances:

1. Chaque fois que je crée un shell bash sans connexion (en utilisant le terminal dans l'unité)
2. Chaque fois que je crée un shell bash de connexion (par exemple, connexion à distance via ssh)
3. Chaque fois que j'utilise un lanceur d'application Unity (étant donné que le lanceur utilise / bin / sh).
4. Chaque fois qu'un travail cron s'exécute (étant donné que SHELL = / bin / sh dans / etc / crontab).

Si je comprends bien, je suppose que:

• (1) / (2) et (3) / (4) sont différents car (1) / (2) sont bash et (3) / (4) sont tirets.
• (1) et (2) sont différents car les fichiers que bash choisit de charger diffèrent selon qu'il s'agit ou non d'un shell de connexion.
• (3) et (4) sont différents parce que (3) viendra à un moment donné après que je me suis connecté (et donc ~ / .profile aura été trouvé par l'un de ses processus parents, tandis que (4) viendra à un moment donné quand je ne suis pas connecté, et donc ~ / .profile n'aura pas été lu.

(Je ne serais pas surpris si d'autres facteurs importaient aussi, comme le fait que le shell soit interactif ou non, donc il y a probablement plus de combinaisons que je n'avais même pas anticipées ... Je suis heureux d'avoir ma question "améliorée" " dans ce cas.)

Je m'attendrais à ce qu'à un moment donné, quelqu'un ait créé une sorte de guide qui vous indique comment / où modifier les variables d'environnement de manière indépendante du shell (ou au moins d'une manière compatible avec les tirets / bash) ... Je peux juste ' t semble trouver les bons termes de recherche pour trouver un tel guide.

Des solutions ou des pointeurs vers des solutions très appréciés!

Actualisé:

• Clarification: Il s'agit de l'utilisateur Ubuntu par défaut créé par le processus d'installation 12.04, donc rien de spécial. Il ne dispose d' un ~ / .profile (qui explicitement les sources ~ / .bashrc), et le seul ~ / .bash * fichiers présents sont .bashrc, .bash_history et .bash_logout ... donc pas qu'il n'y a pas .bash_profile.
• Accent sur la portée: je ne me soucie pas vraiment des shells autres que le shell interactif par défaut (bash) et de tout script qui utilise / bin / sh (aliasé en tiret), donc il n'y a pas besoin de compliquer cela avec quelque chose de plus pour tcsh / ksh / zsh / etc. soutien.

L'invocation de shell est un peu compliqué. Les pages de manuel bash et dash contiennent des INVOCATIONsections à ce sujet.

En résumé, ils disent (il y a plus de détails dans la page de manuel, vous devriez le lire):

When bash is                   | it reads
-------------------------------|----------
login shell                    | /etc/profile and then the first of ~/.bash_profile, ~/.bash_login or ~/.profile that exists.
                               |
interactive non-login shell    | /etc/bash.bashrc then ~/.bashrc
                               |
non-interactive shell          | The contents of $BASH_ENV (if it exists)
                               |
interactive (as "sh")          | The contents of $ENV (if it exists)

-

When dash is                   | it reads
-------------------------------|---------
login shell                    | /etc/profile then .profile
                               |
interactive shell              | The contents of ENV (it it exists, can be set in .profile as well as in initial environment)

Je ne connais pas les autres coquilles à la légère car je n'en utilise jamais. Votre meilleur pari pourrait être de définir quelques variables d'environnement pour pointer vers le script d'emplacement commun et de les récupérer manuellement (le cas échéant) dans les deux cas non couverts.

Il y a donc plusieurs façons d'aborder cela. Beaucoup de gens:

une. Avoir un fichier qui a des choses communes à toutes vos coquilles de style sh, disons .shcommonet dans chacun des .profile .bashrc .kshrcet cetra, sourcez-le simplement avec. .shcommon

b. Mettez tout .profileet sourcez-le à partir des autres fichiers.

Les éléments nécessaires pour des shells spécifiques ou pour des shells interactifs ou non interactifs peuvent ensuite être placés dans le fichier approprié avant de s'approvisionner. .shcommon

Personnellement, je n'aime pas gérer plusieurs fichiers. Donc, j'utilise l'approche suivante:

Tout d'abord, tout ce dont j'ai besoin va dans .profile Comme j'ai des choses spécifiques à bash et ksh, je détermine le nom du shell actuel en utilisant ce qui suit:

# get name of current shell
# strip leading - from login shell
export SHELLNAME="${0#-}"

puis avoir des commandes pour des shells spécifiques dans quelque chose comme ce qui suit (certains préféreraient une déclaration de cas).

if [ "$SHELLNAME" = 'bash' ]
then
    shopt -s checkwinsize

elif [ "$SHELLNAME" = 'ksh' ]
then
    stty erase ^?
fi

Si j'ai des commandes qui ne doivent s'exécuter que dans des shells interactifs, j'utilise ce qui suit:

# check for interactive flag i in shell options $-
# in bash and ksh you could use the following, but breaks in dash
# if [[ $- == *i* ]]
if [ "$(echo $- | grep i)" != "" ]
then
  fortune
fi

Les choses qui sont courantes dans toutes les coquilles de style sh, par exemple, PATHpeuvent simplement aller en haut.

Ensuite, j'utilise des liens symboliques pour charger ce même fichier dans tous les shells de style sh:

ln -s .profile .bashrc
ln -s .profile .kshrc

Quelques notes annexes, si vous en avez un .bash_profile, alors bash le chargera au lieu de .profilemais dash et ksh continueront de se charger .profile Cela peut faire partie de votre problème.

En outre, vous voudrez peut-être envisager d'utiliser #!/bin/bashdans vos scripts au lieu de, #!/bin/dashsauf si vous voulez vraiment des scripts compatibles POSIX. bash a beaucoup de fonctionnalités supplémentaires qui sont très agréables et dash ou bash invoquées car sh désactivera beaucoup de ces fonctionnalités.

De plus, la page de manuel bash explique bien quand .profileversus .bashrcest chargé. Des règles similaires s'appliquent à ksh. le tableau de bord se charge .profileà la connexion et vous permet de charger un fichier au démarrage des shells interactifs qui est spécifié à l'aide de la ENVvariable d'environnement dans .profile(consultez également la page de manuel du tableau de bord et recherchez .profile).

Étant donné que les cas (1) et (2) sont résolus en recherchant mes variables d'environnement dans .bashrc et .profile, la vraie question est "quel est le nom du fichier où je source ces mêmes variables pour (3) et (4).

Il semble qu'il y ait une réponse à la partie (3) de la question (comment puis-je obtenir la variable d'environnement à importer dans le bureau Unity) sur askubuntu . La suggestion consiste à créer un fichier ~ / .xsessionrc qui proviendra de / etc / X11 / Xsession. (J'ai essayé cela, et cela semble fonctionner ... yay!)

Je suis toujours perplexe par quoi faire pour (4). Certes, si je crée un travail cron (ou démon), je peux remplacer '/ bin / foo' par quelque chose comme 'bash -i -c / bin / foo' pour le forcer à utiliser bash pour charger les bonnes variables d'environnement, mais cela signifie également que je devrai bricoler avec des outils tiers qui pourraient installer des tâches démon ou un travail cron en mon nom. Yuk.