web-dev-qa-db-fra.com

Comment fonctionnent `>` et `>>`?

J'ai essayé de rev un fichier, puis de le diriger vers cat > same_file mais il se transformait en un fichier vide.

Pendant que j'essayais rev file.txt | cat > file2.txt && mv file.txt file2.txt; cela fonctionnait.

Même rev file.txt | cat >> file.txt; a fonctionné.

Mais quand j'ai essayé rev file.txt | cat > file.txt cela a échoué.

command-lineredirect
9
Vintux

La chose fondamentale que vous devez comprendre dans ce cas entre les deux façons de rediriger (> et >>) est la suivante:

>

Redirections et écrase les informations sur lesquelles il a été pointé. Cela se produit lors de la réception d'informations par le biais du tuyau "|"

>>

Redirections et concaténent les informations qui lui ont été signalées. Cela se produit lors de la réception d'informations par le biais du tuyau "|"

Dans les deux cas, si le fichier n'existe pas, il sera créé à la place. Les informations ne seront concaténées que si ">>" si vous l'exécutez à nouveau sur le même fichier. Avec ">" vous écraseriez simplement tout ce que vous avez fait lors de la première utilisation.

Mais voici le problème lorsque vous utilisez le même fichier d'entrée que le fichier de sortie. Dans ce cas particulier, si vous utilisez ">", vous supprimerez les informations que la partie "entrée" doit analyser, car le fichier de sortie "écrasera" le fichier. Alors dans:

rev file.txt | cat > file.txt

Ce qui se passe réellement dans "l'explication au ralenti" est:

  1. rev se prépare à inverser le contenu de file.txt et à l'envoyer à un canal
  2. Tandis que rev envoie les informations au canal, le tuyau les diffuse directement vers cat.
  3. Lorsque cat reçoit les informations, il les applique automatiquement au file.txt avec lequel il a été défini.
  4. Le mot clé ici est "while", car tout se passe en même temps. S'il vous plaît voir les excellents commentaires ci-dessous par Emil pour avoir une compréhension plus profonde de cette partie.
  5. cat n'attendra pas que rev transmette l'ensemble du fichier. Il commencera simplement à la minute où la première partie de l'information lui parviendra, ce qui signifie que, selon le symbole que vous avez utilisé, il ouvrira une connexion à file.txt.
  6. Dans ce cas puisque vous avez utilisé > au lieu de >> , le Shell tronquera le fichier de sortie, ce qui signifie qu'il ouvrira et effacera les informations de file.txt en attendant que les nouvelles informations y parviennent. Avec >> cela ouvrirait une connexion avec file.txt et attendrait de nouvelles informations sur la dernière ligne détectée.
  7. Puisque les informations étaient déjà effacées dans file.txt avec > , rev essaierait de faire son travail et n'obtiendrait rien car cat a tout supprimé pour préparer la nouvelle information.

Alors, pourquoi les autres travaillent-ils après avoir lu ce qui précède? À cause de ce:

rev file.txt | cat > file2.txt && mv file.txt file2.txt

Ici, vous dirigez le chat vers l’envoi des informations à par un autre fichier . Dans ce cas, le fichier d'entrée traité file.txt n'est pas le même que le fichier de sortie file2.txt. Après cela, vous écrasez littéralement tout le file2.txt avec file.txt, de sorte que tout le processus créé par cat a été supprimé. Fondamentalement, la ligne entière pourrait être simplifiée comme cp file.txt file2.txt car elle fait la même chose puisque file2.txt à la fin perd la rev et est écrasée par la commande mv.

rev file.txt | cat >> file.txt

Dans ce cas, vous concaténez les informations dans le même fichier. Donc, il s’agit seulement d’ouvrir une connexion à ce fichier mais pas d’effacer les informations comme on le voit avec un seul > . Le résultat final devrait être, l'information originale plus l'information inversée.

18
Luis Alvarado

Lorsque le shell voit la redirection, il ouvre d’abord les fichiers pertinents avant d’exécuter les commandes concernées. Ainsi, quand vous faites:

foo file.txt | bar > file.txt

La redirection vers file.txt provoque son tronquage avant que foo soit exécuté et puisse lire file.txt. Sur une note de côté, c'est pourquoi vous ne pouvez pas faire:

sed 'blah' file.txt > file.txt

Et pourquoi sed dispose d'une option d'édition sur place.

Enfin, faire:

.. | cat > file.txt

is tilisation inutile de cat , en particulier si vous essayez de lire file.txt plus tôt.

Si vous souhaitez inverser un fichier sur place, il n'y a pas de raccourci . Vous pourrez peut-être utiliser les astuces sed ou awk avec l'édition sur place.

9
muru

> est un redirecteur (opérateur) envoyant la sortie à autre chose
(entrée de la commande suivante, imprimante ..)

Dans votre cas, la sortie passe dans un fichier _file.txt_. Si ce fichier existe déjà, il est écrasé, sinon il est créé.

>> est un opérateur d'ajout. Si _file.txt_ existe déjà, la sortie est ajoutée à la fin du fichier. si le fichier n'existe pas, il est créé et la sortie écrite dans le nouveau fichier, identique à > (redirecteur).

3
Ken Mollerup

Vous pouvez utiliser Vim en mode Ex:

ex -sc '%!rev' -cx file.txt

  1. % sélectionner toutes les lignes

  2. ! commande d'exécution

  3. x enregistrer et fermer

0
Steven Penny