Dans l'exemple ci-dessous:commande bash XOR^anothercommand
w^ls
quel est le comportement attendu de l'opérateur XOR en coquille?
Alors, quand nous entrons dans
command^anothercommand
ce qui déclenche anothercommand pour exécuter (si elle exécutera du tout)?
Si vous entrez command^anothercommand, vous fournissez simplement command avec deux arguments, ^ et anothercommand. Il n'y a pas d'opérateur ici. anothercommand ne s'exécutera que si command décide de traiter cet argument comme un nom de commande et tente de l'exécuter.
pouvez-vous fournir un exemple d'une commande qui accepte^comme argument? –
Comme vous pouvez le voir dans man bash, ^ n'est pas utilisé pour séparer les commandes, il est utilisé dans les expressions arithmétiques.
$ echo $((5^9))
12
C'est parce que
dec bin
5 0101
9 1001
-----------
12 1100
Je pensais honnêtement, cela fonctionnera en fonction du code de sortie des commandes (XOR des valeurs de retour de chaque commande), basé sur les intentions de OP, idiot moi! – Inian
ok mais pourquoi bash ne s'en plaint pas quand je l'utilise sur les commandes? –
Il fait pour moi: 'id $^ls id: opérandes 'ls supplémentaire Try 'id de --help' pour plus d'informations. ' – choroba
Si elle * étaient * un opérateur comme '' && ou '' ||, il serait nécessairement exécuter les deux commandes parce que la valeur de XOR est déterminée par ses deux opérandes (il ne fait pas de court-circuit). Le statut de sortie résultant serait 0 si une commande échouait et l'autre réussissait, ou 1 sinon. Je ne peux pas vraiment imaginer un scénario où cela serait utile. – chepner