Si vous pensez à quelque chose comme ls foo*.txt vs. rm foo*.txt, alors oui, ils afficheront et supprimeront les mêmes fichiers. Le shell étend le glob, et le passe à la commande en question, et les commandes agissent sur les fichiers répertoriés. L'une les répertoriant, l'autre les supprimant.
La différence évidente est que si l'un de ces fichiers était un répertoire, alors ls afficherait son contenu, mais rm échouerait à le supprimer. Ce n'est généralement pas un problème, car rm supprimerait moins que ce qui était affiché par ls.
Le gros problème ici vient de l'exécution de ls * ou rm * dans un répertoire contenant des noms de fichiers commençant par un tiret. Ils se développeraient en lignes de commandes des deux programmes comme si vous les aviez écrits vous-même, et ls prendrait -r pour signifier "ordre de tri inverse", tandis que rm prendrait -r pour signifier une suppression récursive. La différence importe si vous avez des sous-répertoires d'au moins deux niveaux de profondeur. (ls * affichera le contenu des répertoires du premier niveau, mais rm -r * supprimera tout ce qui se trouve au-delà du premier sous-niveau aussi.)
Pour éviter cela, écrivez des globs permissifs avec un ./ initial pour indiquer le répertoire actuel, et/ou mettez un -- pour signaler la fin du traitement des options avant le glob (c'est-à-dire rm ./* ou rm -- *).
Avec un glob comme *.txt, ce n'est en fait pas un problème car le point est un caractère d'option invalide, et provoquera une erreur (jusqu'à ce que quelqu'un développe les utilitaires pour inventer un sens pour cela), mais il est toujours plus sûr de mettre le ./ de toute façon.
Bien sûr, vous pourriez également obtenir des résultats différents pour les deux commandes si vous modifiez les options de globbing du shell, ou créez/déplacez/supprimez des fichiers entre les commandes, mais je doute que vous ayez voulu parler de ces cas. (Traiter les nouveaux/fichiers déplacés serait extrêmement compliqué à faire en toute sécurité.)
