Bug 1778883

Hi!

Solution is to escape the dash, just like the semi-colon (and any double quotes [or even curly braces if using zsh]). For me, there are so many things to escape for, quoting the whole nft command in ticks slowly makes it into my muscle memory. Not saying it's a good solution, but fixing for these things (Pablo even tried once) is a rather futile attempt given the unfixable cases (like semi-colon).

Speaking of documentation, an introductory paragraph about the need to escape/quote things is in order and consistent quoting/escaping in examples. I guess that should clarify any open questions.

Cheers, Phil

(In reply to Phil Sutter from comment #3)
> Hi!
> 
> Solution is to escape the dash, just like the semi-colon (and any double
> quotes [or even curly braces if using zsh]). For me, there are so many
> things to escape for, quoting the whole nft command in ticks slowly makes it
> into my muscle memory. Not saying it's a good solution, but fixing for these
> things (Pablo even tried once) is a rather futile attempt given the
> unfixable cases (like semi-colon).
> 
> Speaking of documentation, an introductory paragraph about the need to
> escape/quote things is in order and consistent quoting/escaping in examples.
> I guess that should clarify any open questions.
> 
> Cheers, Phil

Hello Phil,
escaping the dash does not help because the issue is inside nft. As stated above, the dash wont work unless something else (like a whitespace, ref comment 0 example (1)) precedes it in the argument. In other words, standalone argument of '-100' considered an option instead of a priority number in this case.
i tested this in bash and zsh

bash:
# nft add table nat
# nft add chain nat prerouting { type nat hook prerouting priority \-100 \; }
nft: invalid option -- '1'

zsh:
# nft add chain nat prerouting \{ type nat hook prerouting priority -100 \; \}
nft: invalid option -- '1'
# nft add chain nat prerouting \{ type nat hook prerouting priority \-100 \; \}
nft: invalid option -- '1'

putting whole {} into '' of course works around the issue.

Hi,

(In reply to Tomas Dolezal from comment #4)
> escaping the dash does not help because the issue is inside nft. As stated
> above, the dash wont work unless something else (like a whitespace, ref
> comment 0 example (1)) precedes it in the argument. In other words,
> standalone argument of '-100' considered an option instead of a priority
> number in this case.
> i tested this in bash and zsh

Oh, you're right, sorry. So in order to "properly" escape it you have to put double dash somewhere in front of it, like so:

| nft -- add chain nat prerouting { type nat hook prerouting priority -100 \; }

Cheers, Phil

After discussion with Phil we agreed to update documentation of the package to say explicitly that workaround from comment 5 is needed to pass in negative priority on command line unless the priority part is quoted with at least adjacent preceding part.

Upstream changed its mind, options are no longer allowed after the first non-option. This should fix for negative priority values. Commits to backport are:

commit fb9cea50e8b370b6931e7b53b1a881d3b95b1c91
Author: Pablo Neira Ayuso <pablo>
Date:   Fri Dec 13 11:32:46 2019 +0100

    main: enforce options before commands
    
    This patch turns on POSIXLY_CORRECT on the getopt parser to enforce
    options before commands. Users get a hint in such a case:
    
     # nft list ruleset -a
     Error: syntax error, options must be specified before commands
     nft list ruleset -a
        ^             ~~
    
    This patch recovers 9fc71bc6b602 ("main: Fix for misleading error with
    negative chain priority").
    
    Tests have been updated.
    
    Signed-off-by: Pablo Neira Ayuso <pablo>

commit ea5af85371bd18658ea2ffa0a6c9c48e2c64684b
Author: Pablo Neira Ayuso <pablo>
Date:   Thu Jan 9 18:16:18 2020 +0100

    main: restore --debug
    
    Broken since options are mandatory before commands.
    
    Fixes: fb9cea50e8b3 ("main: enforce options before commands")
    Signed-off-by: Pablo Neira Ayuso <pablo>

Doc Text is fine with me.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:1774