Feature request description
It would be great if podman network rm had an --ignore flag (matching the one for podman network create) that would exit with status 0 when the specified network does not already exist.
This would be really handy for scripting and automation, where one wants to ensure a network is absent without needing to introduce a layer of shell interpretation.
Currently, podman network rm exits with status 1 when the network does not exist, which means some tools need to wrap the command in shell-specific error handling (e.g. || true or checking $?) to achieve idempotent behavior. This makes it harder to write cross-platform scripts, e.g. on Windows which ships with cmd but not sh.
Suggest potential solution
Add an --ignore flag to podman network rm that suppresses the exit code 1 ("network did not exist") case, mirroring the existing --ignore flag on podman network create.
When --ignore is passed:
- If the network does not exist, exit 0 (instead of the current exit 1).
- If the network is in use (exit 2) or another error occurs (exit 125), still report the error as usual.
Have you considered any alternatives?
- Appending
|| true like podman network rm mynet || true, but this masks all errors including the "network in use" case (exit 2), which you'd usually want to know about, and reduces portability
- Appending
|| [ $? -eq 1 ] like podman network rm mynet || [ $? -eq 1 ], but this changes the exit code and reduces portability
- Using a multi-line script like this:
podman network rm mynet
e=$?
[ "$e" -eq 1 ] && exit 0
exit "$e"
...but this requires a multi-line script and reduces portability
Additional context
podman network create --ignore was a great addition and this would be a natural companion to that flag. The create/rm symmetry would make both directions of network lifecycle management simpler and more idempotent.
For reference, there have been similar requests for idempotent removal behavior in other Podman subcommands:
The current exit status table for podman network rm already distinguishes "did not exist" (1) from "in use" (2) and other failures (125), so the --ignore flag would only need to reclassify the "did not exist" case as success.
Feature request description
It would be great if
podman network rmhad an--ignoreflag (matching the one forpodman network create) that would exit with status 0 when the specified network does not already exist.This would be really handy for scripting and automation, where one wants to ensure a network is absent without needing to introduce a layer of shell interpretation.
Currently,
podman network rmexits with status 1 when the network does not exist, which means some tools need to wrap the command in shell-specific error handling (e.g.|| trueor checking$?) to achieve idempotent behavior. This makes it harder to write cross-platform scripts, e.g. on Windows which ships withcmdbut notsh.Suggest potential solution
Add an
--ignoreflag topodman network rmthat suppresses the exit code 1 ("network did not exist") case, mirroring the existing--ignoreflag onpodman network create.When
--ignoreis passed:Have you considered any alternatives?
|| truelikepodman network rm mynet || true, but this masks all errors including the "network in use" case (exit 2), which you'd usually want to know about, and reduces portability|| [ $? -eq 1 ]likepodman network rm mynet || [ $? -eq 1 ], but this changes the exit code and reduces portability...but this requires a multi-line script and reduces portability
Additional context
podman network create --ignorewas a great addition and this would be a natural companion to that flag. The create/rm symmetry would make both directions of network lifecycle management simpler and more idempotent.For reference, there have been similar requests for idempotent removal behavior in other Podman subcommands:
podman rmi --forceshould be idempotent #2234 (podman rmi --forceshould be idempotent)podman image rm -freturns status 1 for non-existent images)The current exit status table for
podman network rmalready distinguishes "did not exist" (1) from "in use" (2) and other failures (125), so the--ignoreflag would only need to reclassify the "did not exist" case as success.