Espaces dans les commandes avec redirection
program 2> error.log
program &> filename
program >> filename 2>&1
program 2>&1
J'ai pu comprendre ce que signifient ces lignes.
Cependant, je ne comprends pas très bien où je devrais mettre les espaces. Je crains aussi que le fait de ne pas mettre d’espace importe peu. Merci d'avoir lu.
Oui, l'espacement entre les mots et les redirections n'a pas d'importance. C'est la réponse courte.
Les détails résident dans le fait que Shell (pour simplifier, appelons simplement bash uniquement) traite certains caractères et groupes de caractères comme des "mots" et des "métacaractères". De bash 4.3 manuel:
métacaractère
Un caractère qui, lorsqu'il est non cité, sépare les mots. L'un des suivants:
| & ; ( ) < > space tab
Et
Word Séquence de caractères considérée comme une seule unité par le shell. Aussi appelé jeton.
Alors quand on fait:
$ echo "hello world">/dev/null
ou
$ echo "hello world" > /dev/null
cela reste 3 mots ("hello world" peut être considéré comme un seul mot Shell parce qu'il est cité), avec un > méta caractère et deux espaces. Shell le verra et effectuera d’abord la redirection (il recherchera d’abord les méta-caractères), puis exécutera les commandes conformément à son comportement standard.
L'ordre des redirections, cependant, est très important, en particulier lorsque vous dupliquez des descripteurs de fichier avec quelque chose comme 2>&1. Supposons que vous souhaitiez envoyer les deux fichiers stderr et stdin au même endroit. Voici une mauvaise façon de le faire:
$ stat ./non-existent file 2>&1 > /dev/null
stat: cannot stat './non-existent': No such file or directory
stat: cannot stat 'file': No such file or directory
Vous créez le descripteur de fichier 2 au même emplacement que 1, qui est votre terminal, mais il le faisait déjà. C'est pourquoi stderr se montre.
Si vous redirigez d'abord stdout, puis que vous modifiez où 2 pointe - alors cela fonctionnera:
$ stat ./non-existent file > /dev/null 2>&1