getfacl: add some long options for Linux compatibility

[kevans]

Summary

Only three of our options have compatible looking long options, w.r.t.
the commonly provided getfacl(1) on Linux systems. Of particular
interest is --omit-header, which is -c on !FreeBSD and -q on FreeBSD.

Sponsored by: Klara, Inc.

[olce]

bin/getfacl/getfacl.c

62

Is it customary not to mention long options in usage()?

[olce]

bin/getfacl/getfacl.c

62

[--omit-headers] => [--omit-header]

[kevans]

bin/getfacl/getfacl.c

62

I usually try not to in order to avoid the redundancy (assuming there's an equivalent short opt), but I'm open to suggestions that that's not a good goal to have.

When I first started adding long options to things, my train of thought was that if I see, e.g., both -n and --numeric in a usage statement, I'm going to assume there might be some subtle difference rather than them being two aliases for the same behavior and waste more time than I need to looking at the manpage to understand the non-difference, especially for tools that I'm already familiar with the short opts on.

[olce]

bin/getfacl/getfacl.c

62

I was mostly asking for my own sake if there was some established implicit policy, and as a reminder for you if there was.

Personally, I'm not sure what would be best either. I think that all options should be listed, but at the same time usage() is supposed to be concise.

As a data point, GNU's getfacl only prints short options on the first line, or if a non-existent flag is input, but prints only long options when --help is passed. GNU coding standards don't seem to say anything hard about long options. But they also say that each command must support --help, which we don't have.

As you know it since you're the author, our ls lists --color, which is not a redundant option.

As for redundant options, [-d|--default] would be closer to what I'd want but far from perfect as well (both forms aren't exclusive but instead completely equivalent). I think we would need another notation for that, perhaps something like (-d|--default).

Anyway, not terribly important for this review/commit, just a side note and food for thoughts on a possible addition to style(9).