[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [Toybox] patch: add built-in versions of sha-2 family hash functions
From:       Rob Landley <rob () landley ! net>
Date:       2021-06-25 10:45:30
Message-ID: 18b62935-f6e2-1b18-d601-d9cf636aabf3 () landley ! net
[Download RAW message or body]

On 6/23/21 2:56 AM, Denys Vlasenko wrote:
> On Tue, Jun 22, 2021 at 2:08 PM Rob Landley <rob@landley.net> 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
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]