Powershell: Remove-Item doesn't respect Recurse switch set to $false

[PrzemyslawKlys]

Steps to reproduce

Remove-Item -LiteralPath $AnyFolderWithFiles -Recurse:$false

Expected behavior

When defined Recurse:$false I would expect the command to accept it and simply not do anything. I explicitly want to delete folder only when it's empty, so if Remove-Item detected files in specified folder and I set Recurse to false I would expect it to simply not do anything.

Actual behavior

Environment data

[vexx32]

This is a good example of why cmdlets should never use Cmdlet.ShouldContinue() calls directly, despite some folks wanting to argue otherwise. There's no way to bypass the prompt with the way the cmdlet is designed.

IMO changing it so that an explicit -Confirm:$false is respected would be great; -Force isn't appropriate here as we don't want the folder removed anyway.

I'd expect maybe an error to be emitted stating the folder can't be removed without removing its children, but forcing a prompt here means that implementing the necessary logic for this to work in a headless environment / automation script would need multiple additional command calls (when it's clear Remove-Item is perfectly capable of determining if the container is empty in the first place).

[PrzemyslawKlys]

Just to be clear, Force is also ignored :-)

[SeeminglyScience]

There's no way to bypass the prompt with the way the cmdlet is designed.

How bout:

if (-not (gci $path -ea 0)) {
    Remove-Item $path
}

Wanting that specific behavior isn't super common, the above is a fine for those edge cases imo.

I'd expect maybe an error to be emitted stating the folder can't be removed without removing its children, but forcing a prompt here means that implementing the necessary logic for this to work in a headless environment / automation script

Doesn't it throw in -NonInteractive?

---

Side note, I don't think we should encourage differing behavior on -Switch:$false. That still just translates to "not present". You'd have to check BoundParameters and the value which seems really counter intuitive (and real confusing for splatting).

[PrzemyslawKlys]

It's not about how to get information if folder is empty. I'm using either of those 2 options:

• $FullFolder = Test-Path -Path "$($_.FullName)\*"
• Get-ChildItem -LiteralPath $Folder -Force -ErrorAction Stop | Select-Object -First 1 | Measure-Object - and check for count -eq 0

I'm just trying to point out that behavior, where it claims Recurse is not set when it's set (just to $false), is giving me a wrong error message, and generally prompting for input where I don't want it and can't prevent it.

[SeeminglyScience]

I'm just trying to point out that behavior, where it claims Recurse is not set when it's set (just to $false), is giving me a wrong error message, and generally prompting for input where I don't want it and can't prevent it.

It isn't set though, -Recurse:$false is just the explicit version of excluding the parameter. Switch parameters only have two states.

[vexx32]

Pretty sure -Confirm:$false is already treated differently by cmdlets implementing ShouldProcess and using Cmdlet.ShouldProcess() -- it ignores the confirmimpact settings completely and bypasses the prompt.

[SeeminglyScience]

Pretty sure -Confirm:$false is already treated differently by cmdlets implementing ShouldProcess and using Cmdlet.ShouldProcess() -- it ignores the confirmimpact settings completely and bypasses the prompt.

Yeah it is, but that's also super confusing and frequently complained about. I don't think that mistake should be propagated.

[vexx32]

I don't disagree, but I'd say we then have a need for an additional switch for SupportsShouldProcess to explicitly bypass prompts. That's probably a separate issue, but either way I think the behaviour of Remove-Item here is awkward to workaround at the best of times.

[SeeminglyScience]

I don't disagree, but I'd say we then have a need for an additional switch for SupportsShouldProcess to explicitly bypass prompts.

I do kinda wish ShouldContinue would always throw if the command is not the top level interactive command. Probably too big of break though. Yeah I'd be down for a ThrowOnPrompt style parameter (with a better name) to be added to CommonParameters. Or if you mean as a replacement for -Confirm:$false yeah I agree.

That's probably a separate issue, but either way I think the behaviour of Remove-Item here is awkward to workaround at the best of times.

It's barely awkward at the worst of times 😛

At the best of times you're either removing a file or a directory with -Recurse -Force. The worst of times is when you specifically only want to delete a folder when it's empty, which is pretty easily worked around by wrapping the Remove-Item call in a simple if block.