La différence entre -r et -R

La plupart des commands POSIX qui ont l'option récursive de traversée de directory ( ls , chmod , chgrp , chmod , cp , rm ) ont -R pour cela.

rm aussi -r parce que c'est ce que c'était initialement.

Maintenant, le comportement varie lorsque des liens symboliques sont trouvés dans la marche dans l'tree. POSIX a essayé de rendre les choses cohérentes en ajoutant les options -L / -H / P pour donner à l'user une chance de décider quoi faire avec les liens symboliques en laissant la valeur par défaut quand aucune n'est spécifiée.

POSIX grep n'a pas de -r ou -R .

GNU grep n'avait initialement ni l'un ni l'autre. -r été ajouté en 1998. C'était suivre les liens symboliques.

-R été ajouté comme synonyme en 2001 pour la cohérence avec les autres utilitaires. C'était toujours suivre les liens symboliques.

En 2012 (grep 2.12), -r été modifié afin de ne plus suivre les liens symboliques, peut-être parce que -L , -H étaient déjà utilisés pour autre chose.

BSDs grep étaient basés sur GNU grep depuis longtime. Certains d'entre eux ont réécrit leur propre et ont gardé plus ou less la compatibilité avec GNU grep . Apple OS / X a traité le problème des liens symboliques différemment. -r et -R sont les mêmes et ne suivent pas les liens symboliques. Il y a cependant une option -S qui agit comme l'option -L chmod / cp / find pour suivre les liens symboliques.

Pas du tout. Cela dépend simplement de ce que les développeurs ont choisi. C'est souvent parce que -r et -R sont des options valides. Dans les programmes que vous avez cités, par exemple:

• les versions récentes de GNU grep :

   -r, --recursive Read all files under each directory, recursively, following symbolic links only if they are on the command line. This is equivalent to the -d recurse option. -R, --dereference-recursive Read all files under each directory, recursively. Follow all symbolic links, unlike -r. 

• chmod n'a pas d'option -r donc, vraisemblablement, les développeurs préfèrent -R . Cependant, bien sûr, -r est une string d'autorisation valide (comme souligné par @Arkadiusz Drabczykso), il ne peut pas vraiment être utilisé ici.

Surtout, il s'agit d'une preference personnelle du développeur. Parfois, cependant, une option en majuscule est choisie si une option en minuscules préférée est prise pour quelque chose d'autre que les développeurs croient être plus important que, par exemple, le fonctionnement récursif. Dans le cas de chmod -r est un mode valide. Par exemple:

 $ ll FILE -rw-r--r-- 1 ja ja 0 Sep 9 16:42 FILE $ chmod -r FILE $ ll FILE --w------- 1 ja ja 0 Sep 9 16:42 FILE 

Je n'arrive pas toujours à me tromper et à oublier qui est qui.

Dans la mesure du possible, utilisez les versions GNU de ces utilitaires, puis utilisez les noms plus longs pour les options.

 command --recursive 

Y a-t-il une logique derrière la sélection des arguments pour ces arguments?

Non.

Ou pas beaucoup. Les utilitaires Unix ont été développés au coup par coup et les options de commands reflètent les choix individuels de leurs développeurs principaux ou uniques. Il n'y a que 26 lettres d'option minuscules ASCII disponibles, ce qui est l'set préféré (les commands sont généralement en minuscules pour faciliter la frappe), et cet set limité conduit à des conflits mnémoniques. Les conflits entraînent des incohérences à mesure que de nouvelles versions de commands / utilitaires acquièrent de nouvelles fonctionnalités .