Managing permissions with PowerShell is only a bit easier than in VBS or the command line as there are no cmdlets for most day-to-day tasks like getting a permission report or adding permission to an item. PowerShell only offers Get-Acl and Set-Acl but everything in between getting and setting the ACL is missing. This module closes the gap.
MIT License
431
stars
61
forks
source link
Get-ChildItem2 does not handle ContinueException #1
Get-ChildItem2 has an unhandled error. This particular code snippet is useful with a where clause to return a first result without having to wait for the entire pipeline to process.
raandree wrote 2015-02-28 at 10:38
Fixed now in Changeset 38597. However the BreakException and ContinueException is not accessible in PowerShell V2 and it seems as it cannot be caught directly.
I have never tested this and used "Select-Object -First 1" instead. This gives you the same behavior in PowerShell V3 and higher.
wrote 2015-02-28 at 10:40
ALIENQuake wrote 2015-06-04 at 00:12
I have different relults even if I use "Select-Object -First 1"
raandree wrote 2015-06-04 at 06:44
This is because Get-ChildItem2 sort files and folder alphabetically. The built-in cmdlet Get-ChildItem displays folders first and then files. Get-ChildItem2 sorts like the old cmd.exe dir command.
ALIENQuake wrote 2015-06-04 at 15:34
Well, I think that it's very wrong to change such fundamental behavior. I'm sure that you see a lot of possible problems and
potentially deleting of the wrong files/folders. Can you please change it for the next release?
P.S. I don't want to start another topic so I just mention that Get-ChildItem2 should be renamed to Get-NTFSChildItem as the rest of you module commands. It was a good decision to include prefix.
wrote 2016-01-03 at 13:55
ALIENQuake wrote 2016-01-03 at 18:11
Hi, I still get wrong object when i use Get-ChildItem2 -r | select-object -First 1
the feedback I got from other people was that the old DOS style listing was more comfortable. Directories first and then files, both in an alphabetical order. This is why I haven’t changed the behavior.
How about making this configurable and letting the user decide?
-Raimund
raandree wrote 2016-01-03 at 20:21
\ Closed by raandree 03.01.2016 05:55
Indeed, old DOS style listing might be more comfortable BUT! it should be only listing, not different object inside pipeline. The best approach would be to leave the listing "view" intact and match object order as core PS. But I think that it is not
possible or it would require too much work. I such case, I'm in favor to make this configurable and letting the user decide only when default behavior will match core PS - because it is one of the most important PS module and people started to use it everyday,
you cannot expect that they have to remember about different object sorting. I don't even want to think what damage could happen when Powershell newcomer will write some copy/delete script using Get-ChildItem, face 256 path limit, install you module, replace
Get-ChildItem with Get-ChildItem2 - goodbye files...
This issue was imported from CodePlex
addilapi wrote 2015-02-27 at 17:57 Observe the results of:
Get-ChildItem -Recurse | ForEach-Object {$_; Continue}
Get-ChildItem2 -Recurse | ForEach-Object {$_; Continue}
Get-ChildItem2 has an unhandled error. This particular code snippet is useful with a where clause to return a first result without having to wait for the entire pipeline to process.
raandree wrote 2015-02-28 at 10:38 Fixed now in Changeset 38597. However the BreakException and ContinueException is not accessible in PowerShell V2 and it seems as it cannot be caught directly.
I have never tested this and used "Select-Object -First 1" instead. This gives you the same behavior in PowerShell V3 and higher.
wrote 2015-02-28 at 10:40
ALIENQuake wrote 2015-06-04 at 00:12 I have different relults even if I use "Select-Object -First 1"
raandree wrote 2015-06-04 at 06:44 This is because Get-ChildItem2 sort files and folder alphabetically. The built-in cmdlet Get-ChildItem displays folders first and then files. Get-ChildItem2 sorts like the old cmd.exe dir command.
ALIENQuake wrote 2015-06-04 at 15:34 Well, I think that it's very wrong to change such fundamental behavior. I'm sure that you see a lot of possible problems and potentially deleting of the wrong files/folders. Can you please change it for the next release?
P.S. I don't want to start another topic so I just mention that Get-ChildItem2 should be renamed to Get-NTFSChildItem as the rest of you module commands. It was a good decision to include prefix.
wrote 2016-01-03 at 13:55
ALIENQuake wrote 2016-01-03 at 18:11 Hi, I still get wrong object when i use Get-ChildItem2 -r | select-object -First 1
Windows 10, PS 5, ntfssecurity 4.1
raandree wrote 2016-01-03 at 20:21 Hi,
the feedback I got from other people was that the old DOS style listing was more comfortable. Directories first and then files, both in an alphabetical order. This is why I haven’t changed the behavior.
How about making this configurable and letting the user decide?
-Raimund
raandree wrote 2016-01-03 at 20:21 \ Closed by raandree 03.01.2016 05:55
wrote 2016-01-03 at 20:21
wrote 2016-01-03 at 20:21
ALIENQuake wrote 2016-01-04 at 12:34 Hi,
Indeed, old DOS style listing might be more comfortable BUT! it should be only listing, not different object inside pipeline. The best approach would be to leave the listing "view" intact and match object order as core PS. But I think that it is not possible or it would require too much work. I such case, I'm in favor to make this configurable and letting the user decide only when default behavior will match core PS - because it is one of the most important PS module and people started to use it everyday, you cannot expect that they have to remember about different object sorting. I don't even want to think what damage could happen when Powershell newcomer will write some copy/delete script using Get-ChildItem, face 256 path limit, install you module, replace Get-ChildItem with Get-ChildItem2 - goodbye files...