Liste des fichiers dans le répertoire: sortie étrange

J'essayais de lister les fichiers dans un répertoire, mais j'obtiens des résultats étranges.

C'est la commande que je tape dans l'invite de commande: dir *t.*

C'est le résultat:

c:\test\1.1.1990.txt
c:\test\1.31.1990.txt
c:\test\1.txttxt
c:\test\11.11.2007.txtGif
c:\test\12.1.1990.txt
c:\test\12.31.1990.txt
c:\test\2.tGift
c:\test\2.txtGif
c:\test\5bbb.exeTxt
c:\test\test.txt

La 9ème sortie est particulièrement étrange: 5bbb.exeTxtpourquoi avoir ce résultat compte tenu de ma requête? (maintenant que je regarde cela, la plupart des résultats semblent bizarres?) Par exemple, pourquoi 2e?

Quelqu'un peut-il s'il vous plaît expliquer?

J'aurai besoin d'utiliser la méthode GetFiles , qui fonctionne de la même manière, c'est pourquoi je suis intéressé.

Connexes: liste les fichiers du dossier correspondant au motif (débordement de pile)

windows command-line

— Communauté
source

Êtes-vous sûr de ne pas faire de faute de frappe là-dessus? À moins que je ne lise mal, la seule chose que je vois qui corresponde réellement à votre requête est le dernier élément de la liste. Tout le reste (la plupart du temps) semble correspondre à la sortie appropriée pour dir *.t*(l'exception étant l'avant-dernier élément, que vous avez également noté comme étrange).

— Iszi

@Iszi: C'est pourquoi je suis confus. Pouvez-vous recréer ce problème localement chez vous? Voici l'écran: postimg.org/image/mjl7yjhed

Dupliqué de mon côté. Très étrange. Pendant une minute, j'ai pensé que cela pourrait avoir quelque chose à voir avec les mappages de noms de fichiers courts, mais les résultats de dir /xne montrent rien qui puisse l'expliquer. Quelle version de Windows utilisez-vous? PowerShell pourrait être un meilleur outil pour tout ce que vous essayez de faire ici. (J'ai testé la même commande dans PowerShell - où direst un alias Get-ChildItem, et les résultats étaient

— conformes aux

@Iszi: Je dois (probablement) l'utiliser via la méthode C #, comme je l'ai déjà mentionné.

Je ressens à nouveau ce problème XY Problem . Je suggère d'ouvrir une question séparée, avec la description de votre problème actuel . Tout d’abord, vous présumez que tout ce qui est en C # - un langage de programmation relativement nouveau - fonctionnera de la même manière qu’une commande de niveau utilisateur dans une console aussi archaïque qu’elle CMDsoit très imparfaite. S'il existe une relation entre C # et une interface de ligne de commande Windows commune, ce serait avec PowerShell, mais cela ne va toujours pas dans le bon sens.

— Iszi

Réponses:

Je soupçonne que c'est à cause du comportement mentionné dans le blog de Raymond Chen (avertissement - pas de documentation).

Par exemple, si votre modèle se termine par. *, Le. * Est ignoré. Sans cette règle, le modèle *. * Ne correspondrait qu'aux fichiers contenant un point, ce qui aurait probablement pour effet de casser 90% de tous les fichiers de traitement par lots de la planète, ainsi que de la mémoire vive de tout le monde, car tous les utilisateurs de Windows NT 3.1 grandissaient dans un environnement complexe. monde où *. * signifiait tous les fichiers.

Votre schéma est *t.*, ce qui devient, je suppose *t, qui correspond 5bbb.exeTxt. Je ne sais pas comment ça DirectoryInfo.GetFilesmarche, pourquoi ne pas simplement le tester?

On dirait que peut-être les noms courts sont également appariés, ou les trois premiers caractères de l'extension.

G:\junk\filetest>dir
 Volume in drive G is Extended2
 Volume Serial Number is 3E2F-7A67

 Directory of G:\junk\filetest

09/09/2014  10:01 AM    <DIR>          .
09/09/2014  10:01 AM    <DIR>          ..
09/09/2014  09:59 AM                 6 test.txtR
09/09/2014  10:01 AM                 2 test.txtrrr
               2 File(s)              8 bytes
               2 Dir(s)  162,957,000,704 bytes free

G:\junk\filetest>dir *.txt
 Volume in drive G is Extended2
 Volume Serial Number is 3E2F-7A67

 Directory of G:\junk\filetest

09/09/2014  09:59 AM                 6 test.txtR
09/09/2014  10:01 AM                 2 test.txtrrr
               2 File(s)              8 bytes
               0 Dir(s)  162,957,000,704 bytes free

G:\junk\filetest>dir /x *.txt
 Volume in drive G is Extended2
 Volume Serial Number is 3E2F-7A67

 Directory of G:\junk\filetest

09/09/2014  09:59 AM                 6 TEST~1.TXT   test.txtR
09/09/2014  10:01 AM                 2 TEST~2.TXT   test.txtrrr
               2 File(s)              8 bytes
               0 Dir(s)  162,957,000,704 bytes free

— dsolimano
source

@dsolimano: comment expliquez-vous la 4ème sortie alors?

@dsolimano: voici une autre sortie étrange: postimg.org/image/dtb1r1ck7 , peut-être pourriez-vous expliquer cela?

Je ne peux pas! Peut-être que cela correspond à un nom court? Ou peut-être que cela correspond simplement aux trois premiers caractères de l'extension. Je vais poster un test que je viens de courir.

— dsolimano

@dsolimano: peut-être les trois premiers caractères de l'extension - cela expliquerait la sortie n ° 4 dans ma dernière capture d'écran? Je ne suis pas sûr de ce que vous avez essayé de montrer dans votre échantillon ... Peut-être que cette méthode de correspondance de motif n'est pas très fiable?

@georgem Type dir *t /xet il expliquera votre dernier problème de sortie.

— Iszi

Je pense que @dsolimano (et sa source, Raymond Chen) se sont rapprochés de votre problème mais n’ont peut-être pas la bonne explication. Après quelques réflexions, recherches et tests, bien que je n’aie pas encore fourni de documentation à ce sujet, je suis parvenu à une conclusion assez précise.

Mon hypothèse est basée sur un comportement quelque peu lié aux noms de domaine et à certaines autres ressources informatiques nommées. Avec les noms de domaine, il y a en fait un point de fin implicite à la fin. www.superuser.comEst donc réellement www.superuser.com.. Ma conclusion, après quelques tests, est que l'API Windows (si ce n'est le système de fichiers lui-même) utilise la même convention pour les noms de fichiers.

Pensez à tous les noms de fichiers que vous avez donnés et qui correspondent à votre résultat. Si vous considérez que les noms de fichier 8.3 sont inclus dans les recherches, comme décrit ici , et supposez que les noms de fichier longs avec un point final et les noms de fichier 8.3 avec un point final sont également inclus, vous constaterez que chacun de ces fichiers correspond à au moins un. version de son nom de fichier. (N'oubliez pas que le *caractère générique est un espace réservé qui représente "un nombre quelconque de caractères, ou aucun caractère".)

c:\test\1.1.1990.txtcorrespond à 1.1.1990.txt.ou111990~1.TXT.
c:\test\1.31.1990.txtcorrespond à 1.31.1990.txt.ou131199~1.TXT.
c:\test\1.txttxtcorrespond à 1.txttxt.ou1956B~1.TXT.
c:\test\11.11.2007.txtGif correspond à 111120~1.TXT.
c:\test\12.1.1990.txtcorrespond à 12.1.1990.txt.ou12199~1.TXT.
c:\test\12.31.1990.txtcorrespond à 12.31.1990.txtou123119~1.TXT.
c:\test\2.tGift correspond à 2.tGift.
c:\test\2.txtGif correspond à 2BEFD~1.TXT.
c:\test\5bbb.exeTxt correspond à 5bbb.exeTxt.
c:\test\test.txtcorrespond à test.txtoutest.txt.

Vous pouvez tester cela en créant une série de fichiers de test C:\testcomme décrit ci-dessous et en l'exécutant dir *t.*à nouveau.

Un fichier avec une extension se terminant par "t".
Un fichier dont le nom se termine par "t".
Un fichier avec une extension plus longue que trois lettres avec la troisième lettre dans l'extension étant "t".
Certains fichiers correspondant à plus d’un des critères ci-dessus.
Un fichier dont le nom se termine par "t", et aucune extension du tout.
Certains fichiers qui ne répondent à aucun des critères ci-dessus.

Vous devriez voir, comme je l'ai fait, que dir *t.*seuls les fichiers appartenant aux catégories 1-5 ci-dessus seront renvoyés. Les fichiers de la catégorie 6 seront exclus. Vous pouvez également utiliser la GetFilesméthode ci-dessous plus directement avec les mêmes fichiers avec PowerShell, à l’aide de la commande ci-dessous, et vous devriez voir les mêmes résultats.

[IO.Directory]::GetFiles('C:\test','*t.*')

— Iszi
source

Je vais étudier votre théorie. Mais dans mon cas, les utilisateurs vont taper le motif correspondant. Par conséquent, je dois savoir exactement quelle sera la sortie, je ne peux pas compter sur les "surprises". Compte tenu de cela, recommandez-vous toujours d'utiliser la méthode Directory.GetFiles?

@georgem Honnêtement, je ne suis ni programmeur, ni connaissant exactement vos exigences. Donc, je ne peux vraiment pas vous donner une bonne réponse à cela. Je dirai que la Get-ChildItemscommande de PowerShell semble avoir un comportement plus "normal" et prend en charge RegEx. Donc, vous voudrez peut-être voir comment il fait son travail et essayer de travailler à partir de là.

— Iszi