<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 8, 2020, 12:29 Rob Landley <<a href="mailto:rob@landley.net" target="_blank" rel="noreferrer">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3/8/20 11:44 AM, Chet Ramey wrote:<br>
> On 3/8/20 10:53 AM, Rob Landley wrote:<br>
>><br>
>> I read through the posix shell bits long enough ago it was probably SUSv3 rather<br>
>> than v4, but at the moment I'm taking bash as my standard and just doing<br>
>> whatever that does. <br>
> <br>
> Well, I appreciate that, but there just might be one or two places (or,<br>
> depending on who you talk to, one or two hundred) where bash diverges<br>
> from the standard. That might be because of bugs, or backwards<br>
> compatibility, or the standard having made a dumb decision.<br>
<br>
Sure. There are a couple places where "bash does a thing" and what I decide to<br>
do is different, most recent one I hit was:<br>
<br>
  $ for i<br>
  > in one two three<br>
  > do echo $i;<br>
  > done<br>
  one<br>
  two<br>
  three<br>
  $ for i; in one two three; do echo $i; done<br>
  bash: syntax error near unexpected token `in'<br>
<br>
But in general, if the bash userbase hasn't noticed/minded a posix discrepancy<br>
(or outright bug) over the past 20 years, I'm not sure why I should care?<br>
<br>
> And you can sometimes get into trouble for following the standard *too*<br>
> closely;<br>
<br>
Linux has "echo -e", posix does not. Guess which one toybox implements?<br>
<br>
Meanwhile, all toybox commands support "--", including toybox echo, regardless<br>
of what the host debian one does consistency won out there. Although I<br>
compromised by doing the xargs-style behavior where option parsing ends with the<br>
first non-option argument so "echo -- hello" prints hello but "echo hello --"<br>
prints "hello --". And yes when Elliot found out you can do "ls hello -l" and<br>
the whole can of worms about "rm *" expanding to -r and such, he suggested all<br>
toybox commands should do that, but I stayed with the more-standard behavior of</blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
letting you "ls subdir -l". That discussions on the toybox list somewhere. We<br>
have threads about this sort of corner case all the time, ala:<br>
<br>
  <a href="http://lists.landley.net/pipermail/toybox-landley.net/2017-March/008888.html" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.landley.net/pipermail/toybox-landley.net/2017-March/008888.html</a></blockquote></div></div><div dir="auto"><div dir="auto"><br></div><div dir="auto">Well some of that is the glob() function or maybe wordexp(). My thought was to make it so that when glob() hit a file named "-rf" to expand it would expand it to "./-rf" to prevent people from being "too clever by half" also making it so the simple ".*" would not expand to either "." or ".." I don't recall a glob in toybox but it is usually part of the C library or shell.</div><div dir="auto"><br></div><div dir="auto">A few years back David Wheeler proposed limiting the characters in filenames</div><div dir="auto"><a href="https://lwn.net/Articles/686789/" target="_blank" rel="noreferrer">https://lwn.net/Articles/686789/</a> in attempt to fix the issue by whitelisting valid first, middle, and ending characters.  I thought that fixing glob() so it is less surprising was a better answer.<br></div><div dir="auto"><br></div><div dir="auto">I have had stupid characters in file names and if you have not used the "./-" construct it is hard to get rid of them.</div><div dir="auto"><br></div><div dir="auto">Also <Tab key> expansion of arguments should use the same or similar logic... so "rm -<Tab>" -> "rm ./-" if there is a file "./-" would help.</div><div dir="auto"><br></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>
Ah, here was that specific thread:<br>
<br>
  <a href="http://lists.landley.net/pipermail/toybox-landley.net/2018-October/009796.html" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.landley.net/pipermail/toybox-landley.net/2018-October/009796.html</a><br>
<br>
As you can see posix _is_ referenced, but it's not the last word.<br>
<br>
> cf. the issues with bash-5.0 treating an unquoted backslash as<br>
> subject to being removed by pathname expansion. The heated, lengthy<br>
> discussion that ensued eventually concluded that the plain text of the<br>
> standard -- which all agreed was what bash-5.0 implemented -- did not<br>
> reflect shell implementations or the original intent of the standard<br>
> developers, and that bash-4.4 implements the right way to do it.<br>
<br>
I haven't implemented pathname expansion yet. IFS corner cases took a couple<br>
weeks longer than I expected, and I'm still slogging my way through the 8<br>
gazillion ${stuff} variants.<br>
<br>
> That was not the first occurrence of that phenomenon.<br>
<br>
I'm still subscribed to the posix list, I just don't read it as closely as I<br>
used to and basically never reply.<br>
<br>
>> I should do another pass reading posix afterwards, but after<br>
>> <a href="https://landley.net/notes-2016.html#11-03-2016" rel="noreferrer noreferrer noreferrer" target="_blank">https://landley.net/notes-2016.html#11-03-2016</a> I've been much less interested in<br>
>> interacting with the posix committee due to the risk of another Schilling, and<br>
>> have pretty much backed up to<br>
>> <a href="https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/" rel="noreferrer noreferrer noreferrer" target="_blank">https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/</a> in much the same<br>
>> way Debian backed up to LSB 4.1 ala <a href="https://lwn.net/Articles/658809/" rel="noreferrer noreferrer noreferrer" target="_blank">https://lwn.net/Articles/658809/</a><br>
> <br>
> I gently recommend that you use the 2018 version of the standard; the group<br>
> did a lot of good work in those intervening years. That's the version I<br>
> shoot for.<br>
<br>
I used SUSv2. I upgraded to SUSv3. I upgraded to SUSv4. I'd happily evaluate<br>
SUSv5, but there isn't one because posix stopped having releases. Instead they<br>
randomly replace the existing data at the same URL, so if I point people at that<br>
website I have no idea what'll be there when they look.<br>
<br>
Why toybox does NOT do that kind of "continuous integration" without releases is<br>
one of the few toybox FAQ entries I actually got written up and posted to the<br>
website:<br>
<br>
  <a href="https://landley.net/toybox/faq.html#releases" rel="noreferrer noreferrer noreferrer" target="_blank">https://landley.net/toybox/faq.html#releases</a><br>
<br>
(I was going to say "finished" there, but another argument in favor of releases<br>
I didn't mention there is the "heartbeat" role. Just re-certifying that what we<br>
have is still current and still maintained is valuable, even if the changes are<br>
just a couple typos. Bumping the release schedule down to something less<br>
frequent makes sense for a less-active project, but SUSv4 came out a full 10<br>
years ago and what you have up is still "issue 7" at the same URL, despite<br>
having replaced it at least twice.)<br>
<br>
Previous posix releases had different URLs. If the posix list decided<br>
<a href="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html" rel="noreferrer noreferrer noreferrer" target="_blank">https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html</a> is too old<br>
and instead of going back to the "cc" everybody actually uses, instead<br>
renumbered it to standard du jour (c18 apparently), nobody would even know c99<br>
had _been_ in SUSv4 unless they knew the magic stable URL. (Thank you for having<br>
one, by the way.) And no, that's not an academic concern: in the case of "tar"<br>
and "cpio", being able to pull up the old standard you dropped as a frame of<br>
reference for things was nice, and both commands cite the relevant old posix<br>
spec in the comments at the top. (Nobody uses "pax", and cpio -H newc is the<br>
basis for RPM and initramfs. We've been discussing teaching it about xattrs on<br>
the kernel list on and off for years now.)<br>
<br>
Let me know if posix ever cuts a new release.<br>
<br>
> I understand about Jorg. I'd like to be able to tell you to just ignore him<br>
> and listen to other voices, but I get that it's emotionally taxing and his<br>
> voice is loud enough to drown out others.<br>
<br>
Most projects have... certain individuals. There's talks on that too<br>
(<a href="https://www.youtube.com/watch?v=Q52kFL8zVoM" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.youtube.com/watch?v=Q52kFL8zVoM</a>) and I'm told Linus Torvalds<br>
himself spent a couple months in therapy last year.<br>
<br>
But in this case, in a public thread, nobody else spoke up with a different<br>
view. His voice was the ONLY voice. So I stopped listening.<br>
<br>
>> I still _sort_ of care about newer posix, but I got {bracket,expansion} working<br>
>> last year <br>
> <br>
> The group has discussed brace expansion. It's more or less a valid<br>
> extension not described by the standard.<br>
<br>
The failure mode of posix is the absence of stuff, to the point you can't boot a<br>
posix-only system (no init, no mount, I always assumed microsoft and IBM's need<br>
to pass FIPS 151-2 back in the day led to signing large checks to open holes big<br>
enough to drive NT and OS/360 through).<br>
<br>
I view it as a frame of reference to diverge from, and that's fine. It's still<br>
more useful than LSB. (Possibly less so than <a href="http://man7.org" rel="noreferrer noreferrer noreferrer" target="_blank">man7.org</a>. Yes he has releases,<br>
they're at <a href="https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/Archive/" rel="noreferrer noreferrer noreferrer" target="_blank">https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/Archive/</a>)<br>
<br>
>> and last month taught my $IFS splitting to understand utf8 characters<br>
> <br>
> ? I don't think there's anything in POSIX that restricts IFS to single-<br>
> byte characters, since everywhere it refers to a "character" it's supposed<br>
> to be understood that a character can consist of multiple bytes. The<br>
> standard defines the term that way.<br>
<br>
The bash man page defines "IFS whitespace" as different from unicode whitespace.<br>
(Space, tab, and newline only. Mine will in theory take the non-blank oggham<br>
whitespace, although I haven't added that to tests/sh.test yet. :)<br>
<br>
No idea what posix says about it, the last time I read the whole posix shell<br>
section end to end was... my blog says 2007. (I've triaged the command line<br>
utilities at length a lot more recently, for<br>
<a href="http://landley.net/toybox/roadmap.html#susv4" rel="noreferrer noreferrer noreferrer" target="_blank">http://landley.net/toybox/roadmap.html#susv4</a> and<br>
<a href="https://landley.net/toybox/status.html" rel="noreferrer noreferrer noreferrer" target="_blank">https://landley.net/toybox/status.html</a> . Including checking the 2013 version to<br>
see if anything interesting seemed to have changed, in the before-Jorg times.)<br>
<br>
I am scrutinizing All The Behavioral Corner Cases in the world, but then I<br>
always do when I write a new command, just like<br>
<a href="https://landley.net/notes-2012.html#15-05-2012" rel="noreferrer noreferrer noreferrer" target="_blank">https://landley.net/notes-2012.html#15-05-2012</a> and<br>
<a href="https://landley.net/notes-2012.html#13-04-2012" rel="noreferrer noreferrer noreferrer" target="_blank">https://landley.net/notes-2012.html#13-04-2012</a> from forever ago.<br>
<br>
Posix is in there, but what the linux command line in my host distro does is at<br>
least as important. Half the time I look at posix it's because I'm trying to<br>
figure out what I might be able to get away with _excluding_. When I _first_<br>
started thinking about doing a proper shell (back when I was maintaining busybox<br>
and it had 4 shells), I started by printing the bash man page into a three ring<br>
binder:<br>
<br>
  <a href="https://landley.net/notes-2006.html#24-08-2006" rel="noreferrer noreferrer noreferrer" target="_blank">https://landley.net/notes-2006.html#24-08-2006</a><br>
<br>
>> (and have a TODO item that if IFS is an array it should understand strings), and<br>
>> I honestly don't expect to live long enough for either NOT to be a divergence<br>
>> from Posix.<br>
> <br>
> I don't see POSIX ever standardizing arrays, and no conforming application<br>
> will ever expect IFS to be an array, so as long as you DTRT when IFS is a<br>
> string variable, you should be free to do whatever you like.<br>
<br>
I often try to document "deviations from posix" at the top of each command. I<br>
have a todo item as part of the eventual 1.0 release cleanup to go through and<br>
update all those sections as part of updating the test suite for Full Coverage.<br>
But that's a year's worth of work all by itself, and I don't get to work on<br>
toybox full time...<br>
<br>
Rob<br>
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" rel="noreferrer noreferrer" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div></div></div>