"ip help" output is an error

"ip help" output is an error

[Dmitri Seletski]

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

Re: "ip help" output is an error

[Stephen Hemminger]

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.

Re: "ip help" output is an error

[Dmitri Seletski]

I never done C or github submit before, I hope I did it right way.

Regards

Dmitri Seletski

On 6/21/26 16:21, Stephen Hemminger 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.

Re: "ip help" output is an error

[David Laight]

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

Re: "ip help" output is an error

[Dmitri Seletski]

Hello David,(sorry for duplicate, I keep on forgetting to turn off HTML)

Yes, user could do the redirection, but it's less convenient and 
counterintuitive. IMHO, it's just wrong.

Once user has done "ip help" - IMHO, exit code should be 0. Because user 
did run a command and it correctly executed with a reasonable 
results(provided help text).

And if exit code is 0 - then it reasonably stands that output data is 
standard output and not an error.


"it do exit(0) is likely cause new scripts to fail on old systems." - do 
I understand correctly, concern is that existing scripts that depend on 
current behavior will fail?

First of all, I am guessing that there are not many scripts that depend 
on "ip help".

Second of all, if there are such scripts and we follow this logic - do 
we ever patch anything? Since any script out there can depend on broken 
behavior that will be patched?

Third of all, people who wrote such scripts, should have reported bug 
here in the first place. But it's neither here nor there.


Do I fail to see a bigger picture here? Cause I feel silly talking in 
this mailing list.(I submitted a change for this issue about half a day ago)

Kind Regards

Dmitri Seletski


On 6/22/26 08:49, David Laight wrote:
> 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
>

Re: [PATCH iproute2-next] "ip help" wrong output, exit code.

[Stephen Hemminger]

On Sun, 21 Jun 2026 22:48:59 +0100
Dmitri Seletski <drjoms@gmail.com> wrote:

> From 0805e07105cd15c5b94271a4706e50e3c65dbde5 Mon Sep 17 00:00:00 2001
> From: Dmitri Seletski <drjoms@gmail.com>
> Date: Sun, 21 Jun 2026 22:12:43 +0100
> Subject: [PATCH iproute2-next]  "ip help" wrong output, exit code.
> 
> Changed output of "ip help" from standard error to standard output. And 
> Exit is now 0 instead of -1. "ip help|grep bridge" - now gives bridge 
> syntax instead of flooding user with everything from "ip help".
> ---
> ip/ip.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ip/ip.c b/ip/ip.c
> index e4b71bde..4627b61c 100644
> --- a/ip/ip.c
> +++ b/ip/ip.c
> @@ -56,7 +56,7 @@ static void usage(void) __attribute__((noreturn));
> 
> static void usage(void)
> {
> -fprintf(stderr,
> +fprintf(stdout,
> "Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }\n"
> "       ip [ -force ] -batch filename\n"
> "where  OBJECT := { address | addrlabel | fou | help | ila | ioam | l2tp 
> | link |\n"
> @@ -72,7 +72,7 @@ static void usage(void)
> "                    -o[neline] | -t[imestamp] | -ts[hort] | -b[atch] 
> [filename] |\n"
> "                    -rc[vbuf] [size] | -n[etns] name | -N[umeric] | 
> -a[ll] |\n"
> "                    -c[olor]}\n");
> -exit(-1);
> +exit(0);
> }

Your mailer damages white space.

Re: [PATCH iproute2-next] "ip help" wrong output, exit code.

[David Laight]

On Mon, 22 Jun 2026 07:57:00 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:

> On Sun, 21 Jun 2026 22:48:59 +0100
> Dmitri Seletski <drjoms@gmail.com> wrote:
> 
> > From 0805e07105cd15c5b94271a4706e50e3c65dbde5 Mon Sep 17 00:00:00 2001
> > From: Dmitri Seletski <drjoms@gmail.com>
> > Date: Sun, 21 Jun 2026 22:12:43 +0100
> > Subject: [PATCH iproute2-next]  "ip help" wrong output, exit code.
> > 
> > Changed output of "ip help" from standard error to standard output. And 
> > Exit is now 0 instead of -1. "ip help|grep bridge" - now gives bridge 
> > syntax instead of flooding user with everything from "ip help".
> > ---
> > ip/ip.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/ip/ip.c b/ip/ip.c
> > index e4b71bde..4627b61c 100644
> > --- a/ip/ip.c
> > +++ b/ip/ip.c
> > @@ -56,7 +56,7 @@ static void usage(void) __attribute__((noreturn));
> > 
> > static void usage(void)
> > {
> > -fprintf(stderr,
> > +fprintf(stdout,
> > "Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }\n"
> > "       ip [ -force ] -batch filename\n"
> > "where  OBJECT := { address | addrlabel | fou | help | ila | ioam | l2tp 
> > | link |\n"
> > @@ -72,7 +72,7 @@ static void usage(void)
> > "                    -o[neline] | -t[imestamp] | -ts[hort] | -b[atch] 
> > [filename] |\n"
> > "                    -rc[vbuf] [size] | -n[etns] name | -N[umeric] | 
> > -a[ll] |\n"
> > "                    -c[olor]}\n");
> > -exit(-1);
> > +exit(0);
> > }  
> 
> Your mailer damages white space.
> 

The output also needs to depend on whether these is a 'usage' error or
if 'help' is requested.
Code code is correct for the former - except it should do exit(1).

	David

Re: [PATCH iproute2-next] "ip help" wrong output, exit code.

[Dmitri Seletski]

Hello David,


Based on change introduced:

Two samples of "ip help" with demonstration of exit code and standard 
output are below.

This is in line with what expect.


dimkosPC~/compiled/iproute2-next #if ./ip/ip help a >>/dev/null  ; then 
echo help triggered  ; else echo error code triggered  ;fi  #this 
redirects standard output  to /dev/null, so text missing is not error,
but standard text
help triggered

dimkosPC~/compiled/iproute2-next #if ./ip/ip help   ; then echo help 
triggered  ; else echo error code triggered  ;fi
Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
       ip [ -force ] -batch filename
where  OBJECT := { address | addrlabel | fou | help | ila | ioam | l2tp 
| link |
                   macsec | maddress | monitor | mptcp | mroute | mrule |
                   neighbor | neighbour | netconf | netns | nexthop | 
ntable |
                   ntbl | route | rule | sr | stats | tap | tcpmetrics |
                   token | tunnel | tuntap | vrf | xfrm }
       OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
                    -h[uman-readable] | -iec | -j[son] | -p[retty] |
                    -f[amily] { inet | inet6 | mpls | bridge | link } |
                    -4 | -6 | -M | -B | -0 |
                    -l[oops] { maximum-addr-flush-attempts } | -echo | 
-br[ief] |
                    -o[neline] | -t[imestamp] | -ts[hort] | -b[atch] 
[filename] |
                    -rc[vbuf] [size] | -n[etns] name | -N[umeric] | -a[ll] |
                    -c[olor]}
help triggered

Two samples of command that is broken on purpose.

dimkosPC~/compiled/iproute2-next #if ./ip/ip idontexist   ; then echo 
help triggered  ; else echo error code triggered  ;fi
Object "idontexist" is unknown, try "ip help".
error code triggered

dimkosPC~/compiled/iproute2-next #if ./ip/ip idontexist  >>/dev/null  ; 
then echo help triggered  ; else echo error code triggered  ;fi  #this 
redirects standard output  to /dev/null, so text missing is not error, 
but standard text
Object "idontexist" is unknown, try "ip help".
error code triggered

This works as expected as per my understanding.


Not everything is fixed, but chunk of things fixed is better than non of it.

for example:

if ip  add help    ; then echo help triggered  ; else echo error code 
triggered  ;fi  #this redirects standard output  to /dev/null, so text 
missing is not error, but standard text
Usage: ip address {add|change|replace} IFADDR dev IFNAME [ LIFETIME ]
                                                      [ CONFFLAG-LIST ]
       ip address del IFADDR dev IFNAME [mngtmpaddr]
       ip address {save|flush} [ dev IFNAME ] [ scope SCOPE-ID ] [ to 
PREFIX ]
                            [ FLAG-LIST ] [ label LABEL ] [ { up | down } ]
       ip address [ show [ dev IFNAME ] [ scope SCOPE-ID ] [ master DEVICE ]
                         [ nomaster ]
                         [ type TYPE ] [ to PREFIX ] [ FLAG-LIST ]
                         [ label LABEL ] [ { up | down } ] [ vrf NAME ]
                         [ proto ADDRPROTO ] ]
       ip address {showdump|restore}
IFADDR := PREFIX | ADDR peer PREFIX
          [ broadcast ADDR ] [ anycast ADDR ]
          [ label IFNAME ] [ scope SCOPE-ID ] [ metric METRIC ]
          [ proto ADDRPROTO ]
SCOPE-ID := [ host | link | global | NUMBER ]
FLAG-LIST := [ FLAG-LIST ] FLAG
FLAG  := [ permanent | dynamic | secondary | primary |
           [-]tentative | [-]deprecated | [-]dadfailed | temporary |
           CONFFLAG-LIST ]
CONFFLAG-LIST := [ CONFFLAG-LIST ] CONFFLAG
CONFFLAG  := [ home | nodad | mngtmpaddr | noprefixroute | autojoin ]
LIFETIME := [ valid_lft LFT ] [ preferred_lft LFT ]
LFT := forever | SECONDS
ADDRPROTO := [ NAME | NUMBER ]
TYPE := { amt | bareudp | bond | bond_slave | bridge | bridge_slave |
          dsa | dummy | erspan | geneve | gre | gretap | gtp | hsr |
          ifb | ip6erspan | ip6gre | ip6gretap | ip6tnl |
          ipip | ipoib | ipvlan | ipvtap |
          macsec | macvlan | macvtap | netdevsim |
          netkit | nlmon | pfcp | rmnet | sit | team | team_slave |
          vcan | veth | vlan | vrf | vti | vxcan | vxlan | wwan |
          xfrm | virt_wifi }
error code triggered

This is still problematic.


But so far code leaves "ip help" command/argument in better shape than 
it found it in.


I may try improve things more, but lets submit what we already have 
"better", please.

Kind Regards

Dmitri Seletski


On 6/22/26 17:44, David Laight wrote:
> On Mon, 22 Jun 2026 07:57:00 -0700
> Stephen Hemminger <stephen@networkplumber.org> wrote:
>
>> On Sun, 21 Jun 2026 22:48:59 +0100
>> Dmitri Seletski <drjoms@gmail.com> wrote:
>>
>>>  From 0805e07105cd15c5b94271a4706e50e3c65dbde5 Mon Sep 17 00:00:00 2001
>>> From: Dmitri Seletski <drjoms@gmail.com>
>>> Date: Sun, 21 Jun 2026 22:12:43 +0100
>>> Subject: [PATCH iproute2-next]  "ip help" wrong output, exit code.
>>>
>>> Changed output of "ip help" from standard error to standard output. And
>>> Exit is now 0 instead of -1. "ip help|grep bridge" - now gives bridge
>>> syntax instead of flooding user with everything from "ip help".
>>> ---
>>> ip/ip.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/ip/ip.c b/ip/ip.c
>>> index e4b71bde..4627b61c 100644
>>> --- a/ip/ip.c
>>> +++ b/ip/ip.c
>>> @@ -56,7 +56,7 @@ static void usage(void) __attribute__((noreturn));
>>>
>>> static void usage(void)
>>> {
>>> -fprintf(stderr,
>>> +fprintf(stdout,
>>> "Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }\n"
>>> "       ip [ -force ] -batch filename\n"
>>> "where  OBJECT := { address | addrlabel | fou | help | ila | ioam | l2tp
>>> | link |\n"
>>> @@ -72,7 +72,7 @@ static void usage(void)
>>> "                    -o[neline] | -t[imestamp] | -ts[hort] | -b[atch]
>>> [filename] |\n"
>>> "                    -rc[vbuf] [size] | -n[etns] name | -N[umeric] |
>>> -a[ll] |\n"
>>> "                    -c[olor]}\n");
>>> -exit(-1);
>>> +exit(0);
>>> }
>> Your mailer damages white space.
>>
> The output also needs to depend on whether these is a 'usage' error or
> if 'help' is requested.
> Code code is correct for the former - except it should do exit(1).
>
> 	David
>
>