0

My question is almost answered by this question answer, but the command suggested there spits out many error messages re: the inaccessibility of certain system folders when searching the entire system drive.

So, is there any way to make gci -Path "C:\" -Recurse | where {$_.Name -like '*.txt'} return all txt files on C:, ignoring inaccessible folders?

I would also accept any answer that points to an alternative cmd or powershell command that effectively does the same thing. MTIA! :-)

UPDATE: Apologies for the negative comments guys, I obviously didn't test out this exact scenario properly, nor did I explain what I really want (see Mael's comment below and my replies to it).

I am trying to automate the process of setting up an SSH client, and want to search for any/all public keys that already exist on the system before I go unnecessarily creating new ones. So the extension that I'm actually searching for is .pub, not .txt!

I originally said .txt coz I thought it would be clearer and easier to test, without effecting the results...obviously I was wrong! But why?? Ideally, the command that I'm searching for would work with any file extension (i.e. *.ext, not *.ext*), and not produce false positives like <left part of file or folder name><extension><right part of name>.

Thanks again everyone! :-)

  • i’m thinking this might be less of an issue of what script you are running and more to do with your file associations - what program is currently set to open public keys by default? i was under the impression that .pub in this circumstance was just a way to append the key and not technically an extension - as opposed to .pub which is the extension for Microsoft Publisher files. you may need to be running this in conjunction with assoc and ftype; i’ll try to find time to test this theory and edit my answer if it helps. – mael' Jul 13 at 8:06
  • @mael' Hmm, very interesting indeed! I never would've thought that this had anything at all to do with file associations! I guess I'm even more of a fuzzy searching n00b than I thought! Anyway .pub is currently associated with Notepad on the system that I'm testing this on. Many thanks for your continued effort! :D – Kenny83 Jul 13 at 8:23
  • I've updated my answer with a slightly different approach – mael' 2 days ago
1

PowerShell: Short version:

gci C:\ *.pub -file -ea silent -recurse

Full version:

Get-ChildItem -path C:\ -filter *.pub -file -rroracton silentlycontinue -recurse

  • Using -filter *.pub should be faster as it uses the file system provider. (+1) – LotPings Jul 13 at 18:57
  • *.txt is the filter in my example. Path and Filter are positional parameters. Will edit answer to reflect *.pub – Keith Miller Jul 13 at 22:25
0

I prefer for loops for this:

for /r "c:\" %A in (*.txt) do (echo %A)

This for /r loop goes through c:\ and all subfolders of c:\, each iteration will assign a text file to parameter %A, then echo %A in the command window, or you can make it (echo %%A>>sometextfile.txt) to pipe the results into a text file.

Reference: For


Updated with Information from Comments:
I've been unable to replicate your issue - I threw a bunch of files (Microsoft Publisher files, public keys with a .pub extension added to them, private keys, text files, etc. all with various names i.e. "no.pub.txt", "thanks ok.pub", "maybe a.pub.ppk", etc.) into a bunch of folders (also included "pub", ".pub", etc.) and ran the script and it only ever returned the files with a .pub extension - whether those were actually working .pubs or not.

From my limited understanding, public SSH keys always contain specific strings (I assume based on how they are generated, but I only have experience with PuTTy) - so let's try nesting a loop that uses findstr:

@echo off

for /r "c:\" %%A in (*.pub) do (
    for /f "delims= tokens=*" %%B in ('findstr /i /c:"BEGIN SSH2 PUBLIC KEY" "%%A"') do (
        echo %%A
    )
)

pause

This loops through c:\ and pulls out everything your for /r returns for *.pub - since this is unreliable for you for some reason, we nest it with for /f to go through those results and pull out everything that contains the string BEGIN SSH2 PUBLIC KEY, after which we echo our original parameter %%A. Give that a shot and see if it helps - if your public keys are setup differently you can just replace the string within the quotes.

Reference: Findstr, for /r, for /f

  • This does not handle one of the requirement in the question ("error messages re: the inaccessibility of certain system folders when searching the entire system drive.") – DavidPostill Jul 12 at 17:14
  • Wow you guys jumped on this quicker than I've ever seen before on any StackExchange site! Many thanks! However, this answer does the same thing as all the others I've found on StackOverflow and SuperUser...it echoes out files with txt in the name, not files with an extension of txt. Seriously, how hard is it for this to be done on Windows without WSL?? In any Unix variant, it would literally take me 2 freaking milliseconds with the find command!! – Kenny83 Jul 12 at 17:26
  • OK I've re-read the above comment and taken a deep breath...apologies for the rant and for getting frustrated. And just to make sure that I'm being really clear about what I don't want, the suggested for loop gives me C:\Program Files (x86)\dotnet\sdk\2.2.300\Sdks\Microsoft.NET.Sdk.Publish\... as one of the results when I use *.pub for the extension. What gives?? – Kenny83 Jul 12 at 17:29
  • What specific environment are you using? I can't reproduce your results - I tried setting up a small folder with .txt files, .bmp files with .txt in the name, and folders with .txt in the name, and the for loop is only returning the .txt files. Are you running the command-line through specific software? – mael' Jul 12 at 17:47
  • @mael' I'm running Windows 10 x64 1903 (the latest major release, only about 2 months old) and simply using cmd. For Powershell commands, I'm prepending powershell . Just out of curiosity, what are you running? This would help me understand why so many people think that this and other commands like it are valid solutions. – Kenny83 Jul 13 at 7:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.