Re: "ip help" output is an error

[David Laight <david.laight.linux@gmail.com>]

On Sun, 21 Jun 2026 08:21:05 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:

> On Sat, 20 Jun 2026 10:36:31 +0100
> Dmitri Seletski <drjoms@gmail.com> wrote:
> 
> > Hello iproute2 maintainers,
> > 
> > I am reporting an inconsistency regarding the exit status of the ip help 
> > command.
> > 
> > Current Behavior:
> > When running ip help, the command prints the help documentation to 
> > stdout, but exits with a non-zero status (error). This causes issues in 
> > shell scripts that rely on exit codes for control flow.
> > 
> > Steps to reproduce:
> > bash
> > 
> > # This returns "FAIL" because the exit code is non-zero
> > if ip help > /dev/null; then
> >      echo "SUCCESS"
> > else
> >      echo "FAIL"
> > fi
> > 
> > Expected Behavior:
> > Since the command successfully performs the requested task (displaying 
> > help information) and does not encounter a system error, it should 
> > return an exit code of 0.
> > 
> > Context:
> > This behavior breaks standard Bash logic for automation. For example:
> > ip help && echo "This will not execute"
> > 
> > "ip help |grep br" - this will bring no result.
> > 
> > Current version tested: iproute2-6.19.0
> > 
> > Thank you for your time and for maintaining this tool.
> > 
> > Regards,
> > Dmitri Seletski
> > 
> >   
> 
> Yes iproute2 doesn't do a great job of handling error codes
> with usage vs help. Its a bug and no one has bothered to fix it.
> 

The version I've got does write(2, "Usage...", 972); exit(-1);
Changing it to do write(1, ...) is likely to break scripts, and making
it do exit(0) is likely cause new scripts to fail on old systems.

The 'grep' works fine if you redirect stderr to stdout. 

The exit(-1) is a bug; the parameter is only 8 bits and the high bit
is expected to be used to indicate abnormal termination (eg by a signal).
That should probably be changed to exit(1), there doesn't seem to be
a standard way to differentiate between command line errors and
operational ones.

	David