Lors de la création d'un fichier vide, pourquoi pourrait-on préférer 'toucher le fichier' à ': >> fichier'?

33

Jamais réalisé que vous pouviez faire cela jusqu'à maintenant:

: >> file

Il semble être fonctionnellement similaire à:

touch file

Y a-t-il une raison pour laquelle la plupart des ressources semblent préférer toucher au shell intégré?

shell files touch

— Harold Fischer
source

7

La forme abrégée peut être liée au shell, tandis que touch est une commande autonome. Par conséquent, la forme abrégée dépend du shell que vous utilisez (et les utilisateurs ont de fortes préférences dans ce domaine) car ils ne fournissent peut-être pas tous le raccourci. touchêtre autonome fonctionnera de la même manière, quoi que vous utilisiez.

— Patrick Mevzek

3

Lié Quelle est la différence entre fichier tactile et> fichier sur AU.

— dimanche

6

Le premier exemple doit être édité sur : >> fileou même de >> filemanière à avoir le même effet, c’est-à-dire à NE PAS détruire le contenu du fichier.

— user000001

2

touchmet principalement à jour le mtime. Il ne vide pas un fichier existant contrairement à >.

— rexkogitans

2

Ni la commande "crée un fichier vide"; ils n'ont ce résultat que si le fichier n'existe pas encore. Pour garantir un fichier vide, il vous faut > file.

— Alexis

47

Vous n'avez même pas besoin d'utiliser :; vous pouvez simplement > file(au moins dans bash; d'autres coquilles peuvent se comporter différemment).

En termes pratiques, il n'y a pas de réelle différence ici (même si le minuscule frais supplémentaire lié au fait d'appeler /bin/touchest une chose).

touchToutefois, vous pouvez également modifier les horodatages d’un fichier existant sans en modifier ni en effacer le contenu; plus loin, > filesupprimera tout filece qui existe déjà. Cela peut être contourné en utilisant plutôt >> file.

Une autre différence touchest que vous pouvez lui faire créer (ou mettre à jour l'horodatage sur) plusieurs fichiers à la fois (par exemple touch foo bar baz quux) avec une syntaxe plus succincte qu'avec la redirection, chaque fichier nécessitant sa propre redirection (par exemple >foo >bar >baz >quux).

Utilisant touch:

$ touch foo; stat -x foo; sleep 2; touch foo; stat -x foo
  File: "foo"
  Size: 0            FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (991148597/redacted)  Gid: (1640268302/redacted)
Device: 1,5   Inode: 8597208698    Links: 1
Access: Fri May 25 10:55:19 2018
Modify: Fri May 25 10:55:19 2018
Change: Fri May 25 10:55:19 2018
  File: "foo"
  Size: 0            FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (991148597/redacted)  Gid: (1640268302/redacted)
Device: 1,5   Inode: 8597208698    Links: 1
Access: Fri May 25 10:55:21 2018
Modify: Fri May 25 10:55:21 2018
Change: Fri May 25 10:55:21 2018

Utilisation de la redirection:

$ > foo; stat -x foo; sleep 2; >> foo; stat -x foo
  File: "foo"
  Size: 0            FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (991148597/redacted)  Gid: (1640268302/redacted)
Device: 1,5   Inode: 8597208698    Links: 1
Access: Fri May 25 10:55:21 2018
Modify: Fri May 25 10:56:25 2018
Change: Fri May 25 10:56:25 2018
  File: "foo"
  Size: 0            FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (991148597/redacted)  Gid: (1640268302/redacted)
Device: 1,5   Inode: 8597208698    Links: 1
Access: Fri May 25 10:55:21 2018
Modify: Fri May 25 10:56:25 2018
Change: Fri May 25 10:56:25 2018

— DopeGhoti
source

6

Il semble que >> filene mettra pas à jour l'heure de modification. Pas ce que recherche OP, mais je voulais juste souligner que cela ne semble pas être une alternative complète au toucher.

— Jesse_b

2

Puisque la question ne spécifie pas un shell particulier. Il peut être intéressant de > filenoter que in zsh est équivalent à cat > file, non : > file.

— JoL

Aussi, tcsh le permet : > file, mais commet une erreur > file. Peut-être que l’équivalence de > fileto : > fileest limitée à la bourne shell et à bash?

— JoL

+1 pour la rigueur, notez toutefois que plusieurs obus traditionnels (je dirais même deviner tout ou la plupart des coquilles parce que la plus simple mise en œuvre serait naturellement la cause que cela fonctionne comme un effet secondaire), vous pouvez toucher plusieurs fichiers en utilisant la redirection du shell: : >foo >barou le : >>foo >>barseront touchez à la fois fooet bar.

— mtraceur

Seulement pour être pédant en raison du contexte de la question réelle ici, mais : >foo >barne sera pas touchles fichiers; il va rediriger la sortie (null) de : dans les fichiers. touchtoucherait les fichiers. (:

— DopeGhoti

32

Parce que vous pouvez avoir touchplusieurs fichiers en une fois sans avoir à saisir des caractères spéciaux supplémentaires. Cela inclut des éléments tels que l’agrandissement de l’attelle, par exemple touch file{1,2,3,4}.

Un autre problème est que lorsque vous écrivez un tutoriel, il est assez important de réaliser que vos lecteurs ne sont probablement pas très au courant du sujet. Une simple commande peut être beaucoup plus compréhensible qu'une combinaison étrange de caractères autres que des lettres. Je pense il y a un certain nombre d'utilisateurs de shell occasionnels qui ne savent pas ce qui :est, pour la simple raison qu'il n'a pas vraiment faire quoi que ce soit. De même pour un simple > foosans commande: même si vous savez ce qu'est une redirection, une redirection sans source peut ne pas être intuitive.

De plus, ici, sur unix.se, nous écrivons souvent des exemples de commandes avec le signe dollar en tête pour indiquer l'invite. Les caractères spéciaux au début de la ligne peuvent être confondus avec cela. (Notez que certains systèmes et shells sont utilisés >dans le cadre de l'invite par défaut.)

— ilkkachu
source

4

Et si la commande n'est pas complètement comprise, il y a toujours un "contact humain". Je doute que "man:> file" puisse renvoyer quoi que ce soit d’utile :-) De plus, les invites WRT, certaines (peut-être la plupart) vous permettent de définir l’invite comme bon vous semble. Mine affiche le nom du système (car j'utilise beaucoup de xterms distants) et le répertoire en cours, et est défini sur des couleurs différentes pour différents systèmes.

— jamesqf

1

@jamesqf, yep. Maintenant, bien sûr, il y a aussi help :ou tout ce que votre shell a pour documentation. Mais pour cela, il faut reconnaître :qu’il s’agit d’une commande en soi, se rappeler que tout n’a pas de page de manuel et, enfin, pouvoir trouver :la documentation. La dernière partie peut être assez difficile. : D

— ilkkachu

@jamesqf, et oui, je voulais surtout dire le dernier caractère de l'invite par défaut.

— ilkkachu

1

+1 pour signaler les aspects d' intuition et de non-être-une-obscure-construction.

— mtraceur

@ilkkachu: Ouais. Trouver des points dans la documentation n'est pas si difficile: trouver celui qui ne se limite pas à la ponctuation est une autre affaire :-)

— jamesqf

18

Eh bien, pour moi, la principale raison est la lisibilité. Avec touch filevous, vous savez ce qui se passe, même une personne peu instruite en scripts shell sait ce qui se passe. Et sinon, c'est facile à faire man touchet à voir:

A FILE argument that does not exist is created empty

Avec les éléments cryptiques tels que :et >, il est plus difficile de savoir ce qui se passe, et comme il n'y a pas de réel avantage, il n'est pas nécessaire de l'utiliser.

— yo '
source

6

Imaginez que vous recherchiez l'un de vos anciens scripts shell dont vous vous souviendrez seulement qu'un fichier de marqueur est créé dans / tmp. Il est facile de grep tous vos fichiers * .sh pour le mot "touch". Grepping pour deux points produira à la place de nombreux faux positifs si vous ne savez pas quel nom de fichier exact rechercher.

— B de C
source