Pseudo-fichiers pour données temporaires

Je veux souvent alimenter des données en chaîne relativement courtes (éventuellement plusieurs lignes) à des programmes en ligne de commande n'acceptant que les entrées de fichiers (par exemple, wdiff) de manière répétée. Bien sûr, je peux créer un ou plusieurs fichiers temporaires, enregistrer la chaîne à cet emplacement et exécuter la commande avec le nom du fichier en tant que paramètre. Mais il me semble que cette procédure serait très inefficace si les données sont réellement écrites sur le disque et que cela pourrait également endommager le disque plus que nécessaire si je répète cette procédure plusieurs fois, par exemple si je veux alimenter des lignes simples de texte long fichiers à wdiff. Existe-t-il un moyen recommandé de contourner ce problème, par exemple en utilisant des pseudo-fichiers tels que des tubes pour stocker temporairement les données sans les écrire sur le disque (ou en les écrivant uniquement si elles dépassent une longueur critique). Notez que wdiff prend deux arguments et,wdiff <"text".

Utilisez un tuyau nommé . À titre d'illustration:

mkfifo fifo
echo -e "hello world\nnext line\nline 3" > fifo

Le -edit à l'écho d'interpréter correctement la nouvelle ligne d'échappement ( \n). Cela bloquera, c'est-à-dire que votre shell sera suspendu jusqu'à ce que quelque chose lise les données du canal.

Ouvrez un autre shell quelque part et dans le même répertoire:

cat fifo

Vous allez lire l'écho, ce qui libérera l'autre shell. Bien que le canal existe en tant que noeud de fichier sur le disque, les données qui le traversent ne le sont pas; tout se passe en mémoire. Vous pouvez fond ( &) l'écho.

Le tube a un tampon de 64 k (sous Linux) et, comme un socket, bloquera l’écrivain quand il sera plein, ainsi vous ne perdrez pas de données tant que vous ne le tuez pas prématurément.

Dans Bash, vous pouvez utiliser la command1 <( command0 )syntaxe de redirection, qui redirige command0le stdout et le transmet à un command1qui prend un nom de fichier comme argument de ligne de commande. C'est ce qu'on appelle la substitution de processus .

Certains programmes utilisant des arguments de ligne de commande de nom de fichier nécessitent en réalité un véritable fichier à accès aléatoire. Par conséquent, cette technique ne fonctionnera pas pour ceux-ci. Cependant, cela fonctionne bien avec wdiff:

user@host:/path$ wdiff <( echo hello; echo hello1 ) <( echo hello; echo hello2 )
hello
[-hello1-]
{+hello2+}

En arrière-plan, cela crée une FIFO, dirige la commande à l'intérieur <( )de la FIFO et transmet le descripteur de fichier de la FIFO en tant qu'argument. Pour voir ce qui se passe, essayez de l’utiliser avec echopour imprimer l’argument sans rien faire:

user@host:/path$ echo <( echo hello )
/dev/fd/63

La création d'un canal nommé est plus flexible (si vous souhaitez écrire une logique de redirection compliquée à l'aide de plusieurs processus), mais pour de nombreux objectifs, cela suffit et est évidemment plus facile à utiliser.

Il y a aussi la >( )syntaxe pour quand vous voulez l'utiliser en sortie, par exemple

$ someprogram --logfile >( gzip > out.log.gz )

Voir aussi la feuille de triche pour les redirections Bash pour les techniques associées.

wdiff est un cas particulier car il nécessite 2 arguments de nom de fichier, mais pour toutes les commandes ne nécessitant qu'un argument et qui refusent obstinément de prendre autre chose qu'un argument de nom de fichier, il existe 2 options:

• Le nom de fichier '-' (c'est-à-dire un signe moins) fonctionne environ la moitié du temps. Cela semble dépendre de la commande en question et de la question de savoir si le développeur de la commande intercepte ce cas et le gère comme prévu. par exemple

  $> ls | chat -

• Il existe un fichier psuedo nommé / dev / stdin qui existe sous Linux et qui peut être utilisé lorsqu'un nom de fichier est absolument requis par une commande. Ceci est plus susceptible de fonctionner car il ne nécessite aucune manipulation de nom de fichier spéciale à partir de la commande. Si un fifo fonctionne ou si la méthode de substitution du processus bash fonctionne, cela devrait également fonctionner et n'est pas spécifique au shell. par exemple

  $> ls | chat / dev / stdin