getconf package from HaikuPorts has limited functionality.

[johnsonjh]

Tested on Hybrid Haiku (Walter/hrev55027):

• getconf package from HaikuPorts is non-functional.

Steps to reproduce:

1. Install getconf using pkgman;
2. Execute getconf PATH; printf '%s\n' $?

Expected result:

/bin
0

(or /bin:/boot/system/apps:/boot/system/preferences, or similar)

Message when executed from terminal:

undefined
0

Additional information:

• This command really should be in the base system, it is required for POSIX compliance.
• Displaying the basic / default PATH is likely the most common use of getconf and should be supported.
• Arguably incorrect exit status: getconf should not, by my reading, exit with status 0.
  • The POSIX standard is ambiguous here, but, states that 0 means that "The specified parameter_name was valid and getconf displayed its value successfully.". It was valid, but because the value was not displayed successfully, the status should be greater than zero (IMHO).

[lonemadmax]

The POSIX standard is ambiguous here, but, states that 0 means that "The specified parameter_name was valid and getconf displayed its value successfully.". It was valid, but because the value was not displayed successfully, the status should be greater than zero (IMHO).

It now reads "The specified variable is valid and information about its current state was written successfully.". Later, in the rationale:

Early proposal versions of getconf specified exit status 1 when the specified variable was valid, but not defined on the system. The output string "undefined" is now used to specify this case with exit code 0 because so many things depend on an exit code of zero when an invoked utility is successful."

[lonemadmax]

The problem with the value seems to be in Haiku itself. It's a bit late for me and I'll test (even patch, if I'm right) tomorrow, but as I'm reading it now, for PATH getconf first calls confstr with an empty buffer to get the length and the creates the buffer and calls it again to get the value. That is allowed by the standard but Haiku implementation gives EINVAL for the first call.

[johnsonjh]

It now reads

Ugh POSIX ...

(The horror ... the horror ...)

It's quite inconsistent and unfriendly that this utility can signal success but not return valid data.

Trying to set the PATH to "undefined" (after a 'successful' request for PATH information) is probably still going to cause almost any hypothetical script to fail - and it's a bit involved to check the output in addition to the status - they could have (IMO!) easily just defined a status >1 for this case.

This makes something simple into potentially something absurd:

GCPATH="$(command -p getconf PATH)" &&
    { # /* getconf */
        if [ "${GCPATH:-}" = "undefined" ]; then
            printf '%s\n' \
                "*** getconf PATH failed! (using fallback)"
            GCPATH="/bin:/usr/bin"
        fi
    } || # /* !getconf */
    {
        EXIT="${?:-}"
        printf '%s\n' \
            "*** getconf failed! (${EXIT:?*** shell failed!})"
        exit "${EXIT:-1}"
    }
printf 'GCPATH=%s\n' \
    "${GCPATH:?*** life failed!}"
PATH="${GCPATH}:${PATH}" && export PATH &&
    { # /* export */
        printf 'PATH=%s\n' \
        "${PATH:?*** God failed!}"
    } || # /* !export */
    {
        EXIT="${?:-}"
        printf '%s\n' \
            "*** export failed! (${EXIT:?*** shell failed!})"
        exit "${EXIT:-1}"
    }

(Not to mention all the pitfalls in setting the path this way I'm leaving out to make this a short example... using traps can actually make it more complicated...)

Of course this is not your fault and really has nothing to do with you ... I'm just ranting ... (grumble…grumble)

Thanks for looking into this!

[johnsonjh]

Oh.

That ridiculousness above reminds me (and, sorry, I don't have Haiku handy to check myself), does Haiku's command -p default shell builtin get the standard PATH successfully?

It would be impossible to be able to portably call any standard utility otherwise...

Since there are no standard PATHs you can ever depend on even existing (other than /, /tmp, /dev/null, /dev/console, and /dev/tty), and because you can't get assume that getconf will always be in the PATH, only the fact it's required to be in the standard PATH the system defines, you have to find it through the command builtin.

The absolute shortest possible way (that I know of) to portably call getconf - at least in the context of a executing a standard utility in a clean environment (but, for brevity, purposely ignoring case the undefined getconf response ... and IFS and locale nonsense ... and ignoring most other errors) and without giving any unnecessary output when setting up the environment - would be the following horror show:

(set +eu; { \unalias -a; set -f; unset -f env getconf } > /dev/null 2>&1 }; PATH="$(command -p getconf PATH)" env -i PATH="${PATH:?}" ls)

So, hopefully, command -p doesn't suffer the same issue as getconf PATH ...

Thanks for caring about this - it would be nice to see getconf included with the system as well, so Haiku could be (a bit more) POSIX-complaint without having to install extra packages.

[pulkomandy]

Adding the command to Haiku is tracked here: https://dev.haiku-os.org/ticket/10269
You can upvote that ticket if you have a Trac account at Haiku.

[johnsonjh]

@pulkomandy

I did a quick check and indeed it seems to resolve the problem.

I'll go ahead and close this issue - thanks again.

(Closing: fixed in haiku/haiku@4c23dfb)