Re: [PATCH nft] parser_bison: on syntax errors, output expected tokens

["Jan Kończak" <jan.konczak@cs.put.poznan.pl>]

> Just a note that there might be slight delay with this getting
> applied because we'd like to make a new release soon.

Regarding the patch to dump all expected tokens on syntax errors in
'nft' command: should I modify it somehow so that it gets applied?
Or just wait, or you decided it's not a good idea after all?

In the meantime, I toyed with what parser expects as the next token,
and I see surprises here and there.
For example, is it intended that 'add' and 'rule' keywords are
optional? Right now, to add a rule, it suffices:
   nft F I tcp dport ssh accept

Plus, bogon hints from parser occur on parsing expressions such as
   nft add rule ip F I ct state ?
   nft add rule ip F I tcp dport ?
Because all these are parsed by the same subset of grammar rules
(I guess starting at 'relational_expr'), the possible tokens are
the same for any such expr.
By "bogon hints" I mean that commands get parsed successfully but
raise an error later on. E.g., 'nft F I ct state missing' yields
datatype mismatch claiming that missing is a boolean, not a state.

Interestingly, by "abusing" the junk token which always triggers
a syntax error it is possible to create a bash autocompletion script
that tries to execute nft command typed in so far but appended with
junk, and parses expected tokens into completions. I feel ambivalent
if it makes sense to build autocompletion this way, but it speeds up
checking what the parser expects.

Simple autocompletion (obviously requiring the patch) follows.
----------------------------
_nft(){
    expectedTokens=$(
        "${COMP_WORDS[@]:0:$COMP_CWORD}" $'\025' 2>&1 \
        | grep -A1 "unexpected junk"                   \
        | grep '^expected any of:'                      \
        | cut -d: -f2-                                   \
        | sed 's/, /\n/g'
    )
    [ "$expectedTokens" ] || return 1;
    EXPECTED=()   NONKEYWORD=()
    while read token; do
        [[ $token == '<'*'>'       ]] && { NONKEYWORD+=("$token"); continue; }
        [[ $token == "end of file" ]] && continue
        [[ $token == "newline"     ]] && continue 
        [[ $token == "colon"       ]] && { EXPECTED+=(':');   continue; }
        [[ $token == "semicolon"   ]] && { EXPECTED+=('\\;'); continue; }
        [[ $token == "comma"       ]] && { EXPECTED+=(',');   continue; }
        [[ $token == *[[:space:]]* ]] && { printf "\e[s\nautocompletion problem: space in token \"$token\"\n\e[u" 1>&2; continue; }
        EXPECTED+=("$token")
    done <<< "$expectedTokens"
    COMPREPLY=( $(compgen -W "${EXPECTED[*]}" -- ${COMP_WORDS[$COMP_CWORD]}) )
    if [[ $NONKEYWORD ]]; then
        # TODO: logic for values (non-keyword tokens); either call some
        # 'nft list …' to detect what shall be proposed here and add it to
        # COMPREPLY, or adjust COMPREPLY if the value is a new name / address
        # / port etc. that cannot be completed / guessed.

        if [[ ${COMP_LINE:$COMP_POINT-1:1} == [[:space:]] ]] ; then
            # append non-keyword placeholders after a whitespace character to
            # make them appear among completions, but be non-autocompletable
            for VAL in "${NONKEYWORD[@]}"; do
                COMPREPLY+=(" $VAL")
            done;
            # if there is only one possibility, then add an empty alternative
            # to prevent autocompleting the name of the non-keyword itself
            # (e.g. 'nft delete rule ip F T handle' expects only <number>)
            [[ ${#NONKEYWORD[@]} == 1 && ${#COMPREPLY[@]} == 1 ]] && COMPREPLY+=("")
        fi
    fi
    return 0;
}
complete -F _nft nft
----------------------------