On 5/17/20 7:11 AM, Rob Landley wrote: > I had a reply window open to this when my laptop battery died, and thunderbird > doesn't store unfinished messages like kmail and vi and chrome... > > Anyway, I was reminded of this thread by: > > $ IFS=x; ABC=cxd; for i in +($ABC); do echo =$i=; done > =+(c= > =d)= > $ bash -c 'IFS=x; ABC=cxd; for i in +($ABC); do echo =$i=; done' > bash: -c: line 0: syntax error near unexpected token `(' > bash: -c: line 0: `IFS=x; ABC=cxd; for i in +($ABC); do echo =$i=; done' > $ readlink -f /proc/$$/exe > /bin/bash
Yes, you need extglob to get a word like +(xyz) to parse unquoted. Since the word list following `in' is subject to pathname expansion, it's valid in that context. > > (I tried inserting shopt -o extglob; and shopt +o extglob; at the start of the > -c and it didn't change anything?) Because extglob isn't one of the `set -o' options. I wanted `shopt' to be suitable to set all the shell options, so it understands -o and o and can modify the `set -o' option set. You want `shopt -s extglob'. > Generated code exists and has its costs whether or not you had to manually > write > it. Sure. I'm comfortable with the tradeoff to this point. There are other things I'd rather work on than writing a new parser. > >>> which said to _me_ that the parsing order of operations is >>> >>> A) keep parsing lines of data until you do NOT need another line. >>> >>> B) then do what the lines say to do. >> >> Roughly, if you mean "complete commands have been resolved with a proper >> terminator" and "execute the commands you just parsed." > > The execution can be deferred arbitrarily long (you may be defining a > function) > or never (the else case of an if statement that was true), but yeah. In a way. A function definition is a compound command with a separate exit status, and it's the `if' command we're talking about here, not its constituent parts, some of which may indeed never be executed. > Anyway, that structure needs an "int lineno" added that gets snapshot from the > global TT.lineno, and what I've learned from all this is it gets snapshot at > the > end when we close out the sh_pipeline and start the next one, not at the > beginning when it's allocated. (That's the observation that makes the behavior > make sense now.) No. Kind of in the middle. Consider the following: echo \ one \ two \ $LINENO \ done Bash will always expand $LINENO to 2 in this construct, since it was on line 2 when it figured out it was parsing a simple command. > Last time I looked up youtube clips for the princess bride "once his HEAD is > in > range HIT IT WITH THE ROCK", and winnie the pooh "bear of very little brain", > but I haven't got the spoons to do that again. You fell victim to one of the classic blunders. >> You can probably get away with it as long as that option parsing code stops >> at the first word that doesn't begin with `-'. > > That's literally one character ("^" at the start of the option string in the > middle argument of the NEWTOY() macro.) You've lost me there. Are you saying that you use ^ to mean something when parsing options? >>> Documenting this as a deviance from <strike>posix</strike> the bash man page >>> seems the better call in this instance. >> >> Documenting what as a deviation? POSIX doesn't do long options; you can do >> whatever you like with them. > > My shell standard isn't posix, the standard I'm trying to implement is the > bash > man page. Then why recommend that I document it as a deviation from something POSIX doesn't standardize? >>> These days I handle that sort of thing by waiting for somebody to >>> complain. That way I only add missing features somebody somewhere actually >>> _uses_.) >> >> It has to be a lot more than one person. > > Yeah, but if I'm on the fence about it to begin with it only takes one person > to > confirm "yeah, that's actually used". Sometimes. I'm not getting paid for any of this; if I implement something new it has to be something I think is valuable or will pay off in the long run, or something lots of people are requesting. > Also, Elliott speaks for the Android userbase. They ship a billion devices > annually. When he tells me he needs a thing, it carries some weight. (We argue > about how and where, but "what" is generally a foregone conclusion.) Sure. The Linux distros play the same role for me, though I did get some good input from the Solaris guys a while back. > Yes and no. There's bsd and macos support now, and post-1.0 I might put some > of > my own effort into expanding the BSD side of it. (MacOS is a cross between > "BSD's downstream" and "a weird proprietary mega-corporation that can sign a > check if it wants me to care", but Elliott has users who build AOSP on MacOS > and > borrows a laptop to do fixups there every six months or so, and sends me > patches.) I do all my development on Mac OS X and do testing and some debugging on Linux. But I don't pretend that Apple is ever going to update the bash version they ship, and I know they're going to try and deprecate it due to licensing issues, so I don't spend any time putting in anything Mac OS- specific. Most of the proposals -- even the bad ones -- come from the Linux side. >>> It's a pity posix is moribund. >> >> It's not dead, just slow. > > Give him time. I think you give Jorg a lot more credit for influence than he deserves. > >> https://www.austingroupbugs.net/view.php?id=789 >> >> So we started talking about this in some official proposed way in 2013, >> continued sporadically until 2018, decided on some official text to add >> to the standard in September, 2018, and it will be in the next major >> revision of Posix, issue 8. > > There's going to be an issue 8? Yes, Geoff is preparing the document now. Posix has been replacing issue 7 in place doing > the "continuous integration" thing (grab random snapshot du jour from the > website and call it good, no two people ever experience quite the same > version) > for 12 years now. That's mostly up to the open group, not the people working on the standard itself. > (I ranted a lot more here last time in the email that got lost. Probably a > good > thing.) About release schedules? How much more is there to say about them? I mean, release engineering is complex, but it doesn't seem like there are that many new topics to consider. > I only started using bash in 1998. :) And it was 10 years old at that time. Man, we've come a long way. > If your current locale setting has an appropriate gettext database > installed, > $"strings" get looked up and replaced with translated versions, otherwise > they act like normal double quoted strings. Also, "bash -D SCRIPT" will show > you all the $"" strings in a SCRIPT so translators can make a gettext > database > for a new $LANG. Pretty much. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/ _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net