Est-il sûr de rediriger stdout et stderr vers le même fichier sans copie de descripteur de fichier?

Je commence dans un répertoire vide.

$ touch aFile
$ ls
aFile

Ensuite, j'ai lsdeux arguments, dont l'un n'est pas dans ce répertoire. Je redirige les deux flux de sortie vers un fichier nommé output. J'utilise >>afin d'éviter d'écrire simultanément.

$ ls aFile not_exist >>output 2>>output
$ cat output
ls: cannot access 'not_exist': No such file or directory
aFile

Ce qui semble fonctionner. Y a-t-il des dangers à cette approche?

Non, ce n'est pas aussi sûr que la norme >>bar 2>&1.

Quand tu écris

foo >>bar 2>>bar

vous ouvrez le barfichier deux fois avec O_APPEND, créant deux objets de fichier complètement indépendants [1], chacun avec son propre état (pointeur, modes ouverts, etc.).

Ceci est très différent de celui 2>&1qui appelle simplement l'appel dup(2)système et crée les alias interchangeables stderr et stdout pour le même objet fichier.

Maintenant, il y a un problème avec ça:

O_APPENDpeut conduire à des fichiers corrompus sur les systèmes de fichiers NFS si plusieurs processus ajoutent des données à un fichier à la fois. Cela est dû au fait que NFS ne prend pas en charge l'ajout à un fichier, le noyau client doit donc le simuler, ce qui ne peut pas être fait sans condition de concurrence critique.

Vous pouvez généralement compter sur la probabilité du fichier comme baren foo >>bar 2>&1cours d' écriture en même temps de deux endroits séparés étant assez faible. Mais par vous, >>bar 2>>barvous venez de l'augmenter d'une douzaine d'ordres de grandeur, sans aucune raison.

[1] "Open File Descriptions" dans le jargon POSIX.

Que se passe-t-il lorsque vous le faites

some_command >>file 2>>file

est que filesera ouvert pour être ajouté deux fois. Ceci est sûr à faire sur un système de fichiers POSIX. Toute écriture qui arrive au fichier lorsqu'il est ouvert pour l'ajout se produira à la fin du fichier, que les données proviennent du flux de sortie standard ou du flux d'erreur standard.

Cela repose sur la prise en charge des opérations d’écriture d’ajout atomique dans le système de fichiers sous-jacent. Certains systèmes de fichiers, tels que NFS, ne prennent pas en charge l'ajout atomique. Voir par exemple la question "Le fichier est-il atomique sous UNIX?" Sur StackOverflow.

En utilisant

some_command >>file 2>&1

fonctionnerait même sur NFS cependant.

Cependant, en utilisant

some_command >file 2>file

n'est pas sûr, car le shell tronquera le fichier de sortie (deux fois) et toute écriture qui se produira sur l'un ou l'autre flux écrasera les données déjà écrites par l'autre flux.

Exemple:

$ { echo hello; echo abc >&2; } >file 2>file
$ cat file
abc
o

La hellochaîne est écrite en premier (avec un retour à la ligne de fin), puis la chaîne abcsuivie d'un retour à la ligne est écrite à partir de l'erreur standard, écrasant le hell. Le résultat est la chaîne abcavec une nouvelle ligne, suivie de ce qui reste de la première echosortie, une oet une nouvelle ligne.

L'échange des deux echoautour de la plaie ne produit que hellodans le fichier de sortie car cette chaîne est écrite en dernier et est plus longue que la abcchaîne. L'ordre dans lequel les redirections se produisent n'a pas d'importance.

Il serait préférable et plus sûr d'utiliser le plus idiomatique

some_command >file 2>&1

Cela dépend de ce que vous voulez réaliser. C'est à vous de décider si vous pouvez avoir des erreurs dans le même fichier que la sortie. Il s'agit simplement d'enregistrer du texte dans un fichier avec les fonctionnalités du shell qui vous permettent de rediriger comme vous le souhaitez. Il n'y a pas de oui ou de non absolu. Comme tout sous Linux, cela peut se faire de plusieurs manières, c'est ma façon de ls notExistingFile existingFile >> output 2>&1 répondre à la question: en termes de redirection elle-même, oui, c'est parfaitement sûr.