How to apply a rename command to all subfolders in powershell?

I am new to powershell and I am having a hard time applying this one command to all of the subfolders I have. I have used:

ls | Rename-Item -NewName {$_.name -replace "ALL",""}

And this works for only the one subfolder that I am in. This takes the ALL out of the files names as that is not needed for my purposes. How would I go about applying this command to all of the subfolders so I don't have to go in manually and apply them one at a time. So far, I have tried

dir -recurse ls | Rename-Item -NewName {$_.name -replace "ALL",""}

And this ran but didn't do anything to any of the files. I tried a few variations of this as well, but they did not compile.

Any help would be greatly appreciated

Solution

dir -recurse ls

dir and ls^[1] are both aliases of PowerShell's Get-ChildItem cmdlet, so you need:

either dir -recurse
or ls -recurse
or - the best choice if you want to use an alias^[2] - gci -recurse
or, finally, using the full cmdlet name, Get-ChildItem -Recurse

^{To see all aliases that are defined for Get-ChildItem, run Get-Alias -Definition Get-ChildItem.}

Additionally, to limit processing to files, add the -File switch:

Get-ChildItem -File -Recurse | Rename-Item -NewName { $_.Name -replace 'ALL' }

^{I'm using '...' quoting instead of "..." quoting for conceptual clarity, given that the string's content is to be used verbatim (no string interpolation needed). Also, omitting the replacement-string operand of the -replace operator defaults to '' (the empty string), so it can be omitted.}

Note: The -replace operator is case-insensitive by default, as PowerShell generally is. If you want to match ALL only in all-uppercase, use the case-sensitive variant of the operator,
-creplace.

As for what you tried:

this ran, but didn't do anything to any of the files

ls in your dir -recurse ls command was positionally bound to Get-ChildItem's
-Path parameter.
Because of the highly unfortunate behavior of -Path in combination with -Recurse, described in GitHub issue #5699, no error occurred, despite there (presumably) being no file or subdirectory literally named ls.
- In effect, Get-ChildItem looked for an file or directory named ls on all levels of the subdirectory hierarchy and, in the absence of any, produced no output, i.e. amounted to a quiet no-op.
- While in your case this behavior amounted to obscure failure, in the worst-case scenario it can be destructive, as discussed in the linked GitHub issue.

^{[1] on Windows; on Unix-like platforms, ls refers to the platform-native /bin/ls utility.}

^{[2] This is the best choice, because it doesn't use the name of another shell's or platform's similar, but syntactically different command or utility. The name gci is formed according to PowerShell's own naming conventions, where g is the official alias abbreviation of the Get, one of the approved verbs.}