"auto" for Kerberos, a history
douglas.bagnall at catalyst.net.nz
Thu Aug 20 23:36:24 UTC 2020
On 20/08/20 6:53 pm, Stefan Metzmacher via samba-technical wrote:
> yes means no fallback to NTLM,
> Should we use "disabled", "if_available", "required"
> instead of "no", "auto", "yes"?
I am a fan of "auto", as telling the tool "you decide".
It is nice for the user because there is a convention, and it is nice for
the toolmaker because there is no implicit guarantee about what decision
it will make.
There is considerable precedence for --foo=auto in command line culture.
The biggest cluster is --color=WHEN, where WHEN is conventionally
always|auto|never. This is shared by ls, rustc, rpm, tc, grep, ip, git,
and dozens or hundreds or thousands of other tools.
While --color=WHEN's always/never is a different take than yes/no, yes/no
are usually also accepted:
$ ls --color=maybe
ls: invalid argument ‘maybe’ for ‘--color’
Valid arguments are:
- ‘always’, ‘yes’, ‘force’
- ‘never’, ‘no’, ‘none’
- ‘auto’, ‘tty’, ‘if-tty’
Try 'ls --help' for more information.
A very brief search for other --foo=auto options reveals:
cp --reflink=auto --sparse=auto
flake8 -j auto
git log --decorate=auto
git format-patch --cover-letter=auto --numbered=auto --base=auto
gpg --trust-model=auto --tofu-default-policy=auto
mount -t auto
Now, of course, I am not saying we want to follow gpg's human interface
guidelines, just that this pattern will have some resonance with users. If
the option is "if_available", people like me will be always forgetting the
exact term and whether it uses an underscore or a hyphen.
OK, so sorry for being late and somewhat bikesheddy. I don't object to new
more precise terms, but please let's not remove "auto". It is alright to
be vague, because it is SUPPOSED to be vague.
More information about the samba-technical