On 6/23/21 2:56 AM, Denys Vlasenko wrote: > On Tue, Jun 22, 2021 at 2:08 PM Rob Landley <[email protected]> wrote: >> I tend to wait for people to show up with a complaint attached to a >> real-world >> use case and do lazy-binding decision making then. Now that somebody's >> showed up >> who cares, would: >> >> A) always showing total >> B) implementing --total longopt without the -t short option >> C) changing -t to show total instead of terabytes >> D) removing -t >> >> be less unpleasant? > > C or D. > IOW: avoid having an incompatible option.
I already did option D: https://github.com/landley/toybox/commit/b1b7fec80d20 You're right, I misread it when implementing. >> To me, option C is the worst because that's INTERNALLY INCONSISTENT, which >> is a >> thing toybox tries to avoid being: > > And dd options style is internally inconsistent with most of Unix utilities. Not exactly the high water mark for "doing it right": grandfathered in since 1971, posix requires EBCDIC support for it, and people on IRC literally insisted its posix writeup was a practical joke by the committee. (No really, http://lists.landley.net/pipermail/toybox-landley.net/2017-July/009093.html) That said: "most" is not all: keyword=value parsing shows up a lot. Sure ps and mount prefix them with -o but env and the shell don't. It's used as an _output_ format in id and blkid, as an input format in various config files... the dd command is by no means the only keyword=value parsing toybox does, and it's less weird than: $ ps -o pid:37=fruit,comm=potato The dd command is consistent within itself: it's has a dozen different options all handled the same way. It doesn't make a call out to an existing norm which it then violates ala "here is the same unit list as everywhere else... until it suddenly stops and becomes something else". That said, I already mentioned toybox accepts "dd seek=0x1000k" because consistency. (And toybox ps -o accepts as input all the fields it displays as output, which debian's very much does not. Also, toybox's ps --help mentions "ps -o HELP" to list the fields it can display, still dunno how to make debian's ps do that. Gotta go to the man page and scroll down to line 596. Plus my ps accepts the same input for -o and -O in both ps and top, and uses the same -o and -O _options_ for ps and top. (Which is a difference from debian's, but 90% of the use of this is gui interactive and top/htop don't accept the same command line options either.) "toybox being consistent with toybox" is a strongly weighted design input for me, and "existing script needs" is another strongly weighted design input. > Perfectionism is not achievable, real-world evolution of APIs > ends up with inconsistencies like that. I know. The question is whether this instance should be allowed to stand. Each one is a decision call, not "gnu did X therefore we have no choice". (Gnu netcat existed, you didn't seem to care either. :) There are places I _chose_ to explicitly violate posix. Take "echo" for example, my "deviations from posix" section (a thing toybox has in several commands, https://github.com/landley/toybox/blob/master/toys/posix/echo.c#L7) mentions that we support -en (because EVERYBODY did) and thus -- (to disable -en) even though posix EXPLICITLY said not to honor --. I'm told that eventually posix blinked on that one: https://www.austingroupbugs.net/view.php?id=1222 A good standards body will document, not legislate. Posix has never successfully told anybody what to do. They yanked tar and cpio decades ago, specifying "pax" instead. $ pax bash: pax: command not found I look at posix, LSB 4.1 (before the linux foundation drove it off a cliff), michael kerrisk's man7.org, other specs like IETF RFCs where applicable, and a whole lot of testing what the command line utilities in my distro actually DO. Plus I sometimes google for a "second opinion" from the various bsds. And I pester Elliott for all sorts of details about how android works. I weigh it all together with "how does toybox work", and then people show up later and tell me I did it wrong for their use case. :) >> But this is not a widely used command (because /proc/meminfo exists), and >> systems too small to have /proc mounted generally already know exactly how >> much >> memory they have and/or do their own sysinfo() call in a monolithic app, so >> you're the first person to care enough to mention it. >> >> > hexedit FILE >> > Hexadecimal file editor/viewer. All changes are written to >> > disk immediately. >> > -r Read only (display but don't edit) >> > ^^^^^^^ hexedit 1.5 has no such opt >> >> So you're saying that an interactive GUI utility (which cannot be used in a >> non-interactive mode) may not be compatible with existing shell scripts. I'm >> not >> convinced this issue is why? > > Just an observation. I'm not saying you must remove -r. I make a distinction between "standard" and "a command exists with this name amongst the fifty thousand debian packages but is not there by default on a new install". (And I look askance at ones that are but which mention another implementation in their package description with the implication you might want to try that version instead, as both vim-tiny and netcat-traditional do. Not exactly "the standard".) Rob _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
