Right, the obvious point overlooked is.. having to poke in the program by chance, on hesitation.. to find out discrepancies, as a confirmation of suspected misalignment between the manual page and the actual program implementation. At individual user level, each time by many system operators on their own wits (and consumers of the program as an interpreter, for example scripts, compilers etc). Instead of just "using" the program and relying that the behaviour is predictable and.. somewhat "truthful" to the actual implementation specifics, by documentation / manual page reference (as expected). Or even consistent over time, and predictable by standards compliance and system specific (cohesive principles). So much for idealisation, the factual state is.. what you do not validate yourself is not validated (who do you trust with that), and it will and does fail you.. all the time, everywhere you look into it and use it thoroughly, continuously, for decades. It does fail you persistently and inevitably, despite working as tested by its implementers. Having to look into the source to confirm the manual page before running the program is a step that is optional, but when you take it and find discrepancies, or failure.. you question the changes leading to that, the changelog and which comes from where and how (also how often).
The --version being supported and not documented is a minor point, a totally harmless one, but things that are undocumented will creep, these matters not being addressed do get wider lapses, and not only in a one off case. They become tolerated, the norm and a systemic failure (acceptance and oversight, even on re-evaluations). Yet, we've seen recently, developers have picked up on the call to action, needless to say (as usual), so consider this particular minute "resolved" as a one system operator cry could go that far, for one small point of a "long timed options" case of no such "long options" time. That's not the main point, however. This AWK, that is being constantly re-imported on a continual non-rhythmic pace into OpenBSD from the upstream, which is "neither _true_ (the heck that pretence means), nor the one". It comes from a third party "group" developing it on a "leisure moon(ing) stroll" (carelessly), receives less scrutiny and is sloppily changed routinely, by non-BSD and non-KNF aware GNU / Linux novices in the public (and they can't prove it's better than this criticism outlined). Also, no one can argue with the times and epochs, as things change.. quality and attention to detail degrade in later generation programmers, they are distracted and doing voluntary work on the side pro bono. No auto-type spell checkers and code analysis tools can fix this. Volunteer people are not university graduates any more in the Americas and elsewhere too (for the last 20+ years), and it's going to deteriorate further. Newer tools help, but don't solve it, and these tools do NOT work on (and target) our particular system, and its specifics and properties. That is the objective reality. Other than the obvious "problems" in this particular awk(1) continual reintroduction and "long and slow fix-ups of bugs and subtle behaviour issues" in system tree, it is simply not the OpenBSD quality, and we should be aware of that in public. There is no robust normalised UTF-8 implementation system wide either, and feature creep is set to prevail over quality of programming not only in the many and modernised awk-ren, as it shows in this case for a long(opt) long time so far. As for the compatibility with other systems, you know what to do and how to rationally address these, conformance and coverage of some "portability" is normal and expected (even). No arguments about it.. need to keep up the machine classes and important use cases and adjust the system and extended software according to these necessities. The actual disgusting point is being lied to in the program implementation compared to the program documentation, and it's a foreign problem reintroduced continually. It's not about the UTF-8 or new features all that much, and not about staying legacy and conservatively capsuled in time. Except that it's also part of the what gets ran and what gets proven, and replicated in other programs as custom / non-uniform or manually propagated discrepancies.. Then, there is supposed to be some "trust", that what goes in the system is - if not "robust" and "secure" - at least on that track, or "in long term strive for that and not just acceptance of defeat over this" (you know the speech). There are other larger bulk program being imported continually in the base system and getting exercised like this, and in times even exorcised and excised, it gets the views and attention but does it ever get "fixed" or "normalised" or even conceptually worked on ever for real, other than palliative accommodation? You know the answer. I do know it too, it does not get the real work until these are replaced with own in-house re-implementations from scratch and that is a monumental effort and can lead to expensive wastes of accumulated solutions to problems that are being re-targeted in the clean. We also don't see this ever happening in the upstream (b|n)AWK-ers on Github (and other such), they are not really responsible for and not actually responsive to, the goals and objectives of OpenBSD (the project, and the UNIX legacy and BSD systems derived experience). We can't expect that from them. So, it was not about purity all that much as "BSD" legacy principles, it is somewhat.. but not in the retrograde fixation. More in the reliability and implementation quality, and documentation that is objective to the "state" of the import upkeep. Now, after that outline, what is the solution. One way is, separation of concerns as ported (n)awk (with UTF-8 and what not, on a selectable set of import control) and its re-sync to the base system on fulfilment of the robustness and quality (and reuse of components). Instead it's now in the system and worked slowly en vivo, which would obviously keep messing up OpenBSD base all the time, rather than just being a port with upstream patches, that gets its robust and stable variant in system. It might be challenged even as extra work, but the project is doing so much manual work, yes missing historic options to separate robust from progressive. You saw that with sudo. One day you will see it with awk (and other programs and facilities). Or a clearly outlined local changes to the awk imported and better awareness in the manual, which is what awk-local(1) would bring / meant. It's in the source tree readme files, but not in the documentation (manuals). Shell, compilers, libraries, utils and everyday user interface programs get these honours of local change documented, awk not. Either way, getting such third parties drop their "nuggets" (and fails) in OpenBSD like that is a continuous annoyance, which is appreciated as work needed.. but it never ends like that (the loss of control is never fixed, the work is always surmounting). So, it's about restoring some control and documentation to implementation validity, and system uniformity rather than.. Bulk packaging as it's with the "distribution of non-matching tar (chestnuts and bolts) balls with somewhat broken feathers in there". Yes, the GNU and the distribution model of packages is NOT an operating system, it's something else, which we already have in the ports. The operating system need not be like that, it needs more "validity" and "reliability" as it is exercised more and has higher requirements towards its integrity. This does not mean to get rid of the progressive branches of utilities, just their unstable and unreliable variants from tarnishing the system control and operative reliance. On 9/23/23, Marc Espie <marc.espie.open...@gmail.com> wrote: > Apart from the obvious troll, I believe there is a point. > > From time to time, I go to other projects and try to figure out how far > we are from compatibility... > > Not documenting compat options means that somebody outside the project > would have to guess at stuff, instead of just reading the manpage and > figuring out "hey, I can just use --version here just like elsewhere". > > Just because we find long options to be disgusting (tm) doesn't mean we > shouldn't try to document what's here to stay. > > Face it, as much as we would like OpenBSD to stay pure, some compat stuff > is there to stay. > > Let's try not to be more prickly to the outside world than we need, as much > as we have a reputation to uphold, shall we ? Thanks for your time reading this, which you already knew (and all the work over the years). Now, some extra points if you did not drop out boringly tired so far.. System operators should be able to rely on what is worked in the system to be really deemed system quality. Programs grow, and they need a core and extended variants separation. You know how it goes with the regular expressions and other pattern matching. You will see it happening in multiplexers and libraries too, this separation is not reserved only for user access control and text editing routines. System daemons and services, and resolvers and their libraries and utilities, and core internet application protocols are too subject to this scrutiny. AWK is just an one "example" to use for the commentary and plead. To "normalise" and "separate" robust core and "progressive" feature rich for the "system included" parts too. Rather than "a mix and mash" in system and not having a porting containment for that, thus resulting in evictions and losses of worked well out important facilities and utilities, and major changes and tear with that. Renaming is not needed when there exist system base and expanded (extended) variants with modal choices. Remember well the regular expressions variants, it's also demonstrated well in the shell functionality. It was not well carried in the system user privileges tooling (su/sudo/doas), and it's going to be badly handled in the terminal emulators and multiplexers and resolver cases as well. As for the the core internet protocols applications, what gets developed in OpenBSD as separation of base and extended variants, goes epochal and lasts long. This kind of foresight, is not that abstract and difficult to pertain and handle. We're all grown up and know well what is research and development, and system stability and reliability. We should be able to have both system core and expanded variants, rather than work in bulk and tearing out every couple of years of something really important and having a 5 year misery strain until the replacement actually materialises (yes, it happens slow and painful and the result is suboptimal). You do not simply tear out regular expression engines and their standardisation like that. Why you do it with system operator utilities is a completely mystery. It's not because it can be done, though.. That kind of "tactic" is not systemic, it's ad hoc, in situ and chaotic. There is a better way (and more than one).
