![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
probably a command syntax error, right?
Yes. Sorry. By "cmd line pipeline" I was imagining you would know to start it in a cmd window (not a Powershell window). ; )
But actually you don't even need to have a separate window. Instead you could just enter cmd in a Powershell window to get into a cmd shell environment and then enter the "cmd pipeline" there. To leave that environment and go back to Powershell you would then just enter "exit".
In fact, part of the confusion for you is probably in the Powershell where we are using the dir command which is really an alias of a real Powershell cmdlet for the convenience of cmd window users who are used to typing that when getting lists of modules. For the convenience of UNIX users ls is another alias. The real Powershell cmdlet is incongruously called Get-ChildItem which even hardcore Powershell users would probably want to reduce to gci to simplify typing.
| PS C:\windows\system32> Get-Alias -Definition Get-ChildItem<br><br><br>CommandType Name <br><br>----------- ---- <br><br>Alias dir -> Get-ChildItem <br><br>Alias gci -> Get-ChildItem <br><br>Alias ls -> Get-ChildItem |
|---|
Maybe I should start using ls instead of dir in my Powershell examples. That would be more comfortable for me than "gci" and might not confuse people as much as dir seems to. However, ls in Powershell probably has its own syntax quirks that UNIX users would have to get used to too.
Coincidentally, I recently became aware of the need for some more switches even when listing stuff under a User Profile, so maybe you will need the same extra switches to see what the other pipeline was showing us before (for who knows what reason)? In any case please amend the Powershell pipeline to
| PS C:\WINDOWS> **dir -Re -Fi "*16407*" -Fo -ErrorAction:SilentlyContinue | Where-Object -FilterScript {!$_.FullName.EndsWith(".manifest")} | Sort-Object Name, LastWriteTime | ft Length, FullName -AutoSize** |
|---|
and again, with that, all I find are directories but taking out the filter for manifest proves that the syntax should find files (e.g. items which report lengths) too.
BTW the same time that I found the need for these extra switches also made it more apparent how unreliable file timestamp data can be (worse than I suspected) so the Sort step may or may not do anything helpful and we will just have to try to match up module "versions" by their lengths, particularly in the case of whatever results are given for the Lengths that you already showed you have in System directories. We could do a separate list of them or just refer back to the one that you have already given for that matching. Note that they will be eliminated from this list because 16407 will not appear anywhere in their "FullName" property.
Let's do a separate list for those anyway, save switching back and forth between two separate posts and scanning through a different sort order trying to find a match.
| PS C:\windows> **dir -Re -Fi "*Flash*" -Fo -ErrorAction:SilentlyContinue | Where-Object -FilterScript {$_.FullName.Contains("\Sys")} | Sort-Object Name, LastWriteTime | ft Length, FullName -AutoSize** |
|---|
HTH
Robert