La définition d'une variable d'environnement avant une commande en Bash ne fonctionne pas pour la deuxième commande dans un pipe

Question

Dans un shell donné, je dois normalement définir une ou plusieurs variables, puis exécuter une commande. Récemment, j'ai découvert le concept de l'ajout d'une définition de variable à une commande :

FOO=bar somecommand someargs

Cela fonctionne... en quelque sorte. Cela ne fonctionne pas lorsque vous changez une variable LC_* (ce qui semble affecter la commande, mais...). no ses arguments, par exemple, les plages de caractères '[a-z]') ou lorsqu'on envoie la sortie vers une autre commande de cette manière :

FOO=bar somecommand someargs | somecommand2  # somecommand2 is unaware of FOO

Je peux également faire précéder somecommand2 de "FOO=bar", ce qui fonctionne, mais ajoute une duplication indésirable, et n'aide pas avec les arguments qui sont interprétés en fonction de la variable (par exemple, '[a-z]').

Alors, quel est le meilleur moyen de faire cela sur une seule ligne ?

Je pense à quelque chose de l'ordre de :

FOO=bar (somecommand someargs | somecommand2)  # Doesn't actually work

---

J'ai eu beaucoup de bonnes réponses ! L'objectif est de faire en sorte que cela reste une ligne simple, de préférence sans utiliser "export". La méthode utilisant un appel à Bash était la meilleure dans l'ensemble, bien que la version entre parenthèses avec "export" était un peu plus compacte. La méthode consistant à utiliser une redirection plutôt qu'un pipe est également intéressante.

Answer 1

FOO=bar bash -c 'somecommand someargs | somecommand2'

Answer 2

Comment exporter la variable, mais seulement à l'intérieur du sous-shell ?

(export FOO=bar && somecommand someargs | somecommand2)

Keith a raison, pour exécuter inconditionnellement les commandes, faites ceci :

(export FOO=bar; somecommand someargs | somecommand2)

Answer 3

Utilice env .

Par exemple, env FOO=BAR command . Notez que les variables d'environnement seront à nouveau restaurées/changées lorsque command finit de s'exécuter.

Faites juste attention aux substitutions de l'interpréteur de commandes, c'est-à-dire que si vous voulez faire référence à $FOO explicitement sur la même ligne de commande, vous devrez peut-être l'échapper pour que votre interpréteur de shell n'effectue pas la substitution avant il fonctionne env .

$ export FOO=BAR
$ env FOO=FUBAR bash -c 'echo $FOO'
FUBAR
$ echo $FOO
BAR

Answer 4

Vous pouvez également utiliser eval :

FOO=bar eval 'somecommand someargs | somecommand2'

---

Puisque cette réponse avec eval ne semble pas plaire à tout le monde, laissez-moi clarifier quelque chose : lorsqu'il est utilisé tel qu'il est écrit, avec les guillemets simples il est parfaitement sûr. Il est bon car il ne lancera pas un processus externe (comme la réponse acceptée) et n'exécutera pas les commandes dans un sous-shell supplémentaire (comme l'autre réponse).

Comme nous avons quelques vues régulières, il est probablement bon de donner une alternative à eval qui plaira à tout le monde, et qui présente tous les avantages (et peut-être même plus !) de ce système rapide. eval "truc". Il suffit d'utiliser une fonction ! Définissez une fonction avec toutes vos commandes :

mypipe() {
    somecommand someargs | somecommand2
}

et l'exécuter avec vos variables d'environnement comme ceci :

FOO=bar mypipe

Answer 5

Une approche simple consiste à utiliser ;

Par exemple :

ENV=prod; ansible-playbook -i inventories/$ENV --extra-vars "env=$ENV"  deauthorize_users.yml --check

command1; command2 exécute la commande 2 après l'exécution de la commande 1, de manière séquentielle. Il importe peu que les commandes aient réussi ou non.