Puis-je exporter une variable vers l'environnement à partir d'un script Bash sans le sourcer ?

Question

Supposons que j'ai ce script :

export.bash :

#! /usr/bin/env bash
export VAR="HELLO, VARIABLE"

Lorsque j'exécute le script et que j'essaie d'accéder à l'application $VAR je n'en tire aucune valeur !

echo $VAR

Existe-t-il un moyen d'accéder à la $VAR en exécutant simplement export.bash sans le sourcer ?

Answer 1

Vous pouvez peut-être ajouter une fonction dans ~/.zshrc o ~/.bashrc .

# set my env
[ -s ~/.env ] && export MYENV=`cat ~/.env`
function myenv() { [[ -s ~/.env ]] && echo $argv > ~/.env && export MYENV=$argv }

Grâce à l'utilisation d'une variable extérieure, vous pouvez éviter l'utilisation d'un fichier script.

Answer 2

La réponse est non, mais pour moi, j'ai fait ce qui suit

Le script :

monExport

#! \bin\bash
export $1

Un alias dans mon fichier .bashrc :

alias myExport='source myExport'

Toujours vous source mais peut-être que de cette façon, c'est plus utilisable et intéressant pour quelqu'un d'autre.

Answer 3

Je ne pense pas que cela puisse être fait, mais j'ai trouvé une solution de contournement en utilisant alias . Il ne fonctionnera que si vous placez votre script dans votre répertoire script. Sinon, votre alias aura un nom invalide.

Le seul intérêt de cette solution de contournement est de pouvoir avoir une fonction dans un fichier portant le même nom et de ne pas avoir à prendre la peine de la sourcer avant de l'utiliser. Ajoutez le code suivant au fichier ~/.bashrc :

alias myFunction='unalias myFunction && . myFunction && myFunction "$@"'

Vous pouvez maintenant appeler myFunction sans sourcing le premier.

Answer 4

Cette solution de contournement est évoquée ailleurs, mais peut-être pas aussi clairement :

Dans votre script, après avoir défini la variable, démarrer une nouvelle coquille plutôt que de revenir.

Dans mon cas, j'ai un certain nombre de terminaux ouverts et dans certains d'entre eux, je veux des valeurs pour certaines variables, tandis que dans d'autres, je veux d'autres valeurs.

En utilisant source peut être plus difficile à mémoriser, un petit avantage de cette approche est qu'il faut un certain temps pour se rendre compte que l'on a oublié d'utiliser source et vous devez recommencer à zéro.

(Pour moi, il est plus logique d'utiliser source script car on remarque immédiatement les variables manquantes).

Answer 5

J'ai eu un problème similaire en appelant ssh-agent -s dans un script appelé par l'option -e dans rsync.

Dans le script eval $(ssh-agent -s) ne préservent pas les variables d'environnement pour le prochain appel.

rsync -e 'source ssh-check-agent.sh -p 8022' ne fonctionne pas, donc j'ai fait une solution de rechange. Dans le script j'ai sauvegardé les variables dans un fichier temporel après avoir appelé ssh-agent comme :

echo "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK;" > /tmp/ssh-check-agent.vars
echo "export SSH_AGENT_PID=$SSH_AGENT_PID;" >> /tmp/ssh-check-agent.vars

et après dans le script qui appelle rsync (backup.sh) j'appelle :

source /tmp/ssh-check-agent.vars

Le problème est que le script qui appelle rsync doit être appelé par source (source backup.sh).

Je sais que ce n'est pas la question (j'utilise deux fois la source), mais je mets ici si quelqu'un a un problème similaire avec rsync.