The authors of the utilities seem to make a pretty good case on how GNU’s ‘true’ and ‘false’ are POSIX compliant, because their extensions to them are covered where POSIX leaves the behavior as undefined, and in fact it seems to be the invocation of ‘true’ with any arguments itself that is not in accordance to POSIX.
Whether it’s “not common sense” is not very apparent when “common sense” is pretty difficult to define here (as often the case).
> The authors of the utilities seem to make a pretty good case on how GNU’s ‘true’ and ‘false’ are POSIX compliant, because their extensions to them are covered where POSIX leaves the behavior as undefined, and in fact it seems to be the invocation of ‘true’ with any arguments itself that is not in accordance to POSIX.
Ok, so undefined behavior is seen an escape valve through which the devs can change longstanding behavior in the interest of consistency with a newer set of interface standards they've devised. Fine.
But then this response from a dev on that mailinglist[1]:
> Note that it is a high bar to
change the behavior of something like 'true'.
Hm... now I'm slightly intrigued.
Did the change that introduced the standard "--help" flag and addition of locale-related code flow directly from the "escape valve" of undefined behavior in POSIX? Or was the undefined behavior merely a starting point for a much more involved discussion about whether to change a long-standing interface that could introduce subtle bugs in old scripts/programs that relied on implementation details of undefined behavior?
Edit: clarification. Also if someone can point me to a mailing list discussion that shows evidence of the latter I would be much obliged.
The behavior of --help in GNU's true is not undefined, it is clearly defined in its manpage. Implemenations conforming to the GNU spec are a strict subset of those conforming to the POSIX spec.
Changing thr behaviour is a braking change because they are no longer conforming to their old spec. Adding the flag is not a breaking change, as they stayed consistent with the old spec
You're talking as if this were a recent change. GNU true --help has existed for about 28 years now (it was introduced in sh-utils 1.7). That's more than half of Unix's existence.
Careful: If you go by "longstanding behavior" instead of standards, you quickly get to the point where you have to ask yourself the question which longstanding behavior you want to honor for "consistency". This may not universally be true, but in the case of the shell(s) and everything that surrounds it, I'm pretty sure it is.
Shells are pretty much the wild west out there. I wouldn't be too surprised if some AIX shell variant or something came along and consistently bails out with an error when any argument is given to 'true', including --version. It might not be a common shell variant for you, but it might for other people. Hence, standards.
I'm not really arguing in favor of --help and --version to 'true'. I just don't see much of a problem with it.
Whether it’s “not common sense” is not very apparent when “common sense” is pretty difficult to define here (as often the case).