On Sunday 03 October 2010 07:49:03 Denys Vlasenko wrote:
> On Sunday 03 October 2010 02:35, Rob Landley wrote:
> > On Thursday 30 September 2010 17:15:44 Denys Vlasenko wrote:
> > > On Thursday 30 September 2010 23:29, Rob Landley wrote:
> > > > > > (Making {file,file} curly bracket support work would be darn nice
> > > > > > too, that's the biggest thing I miss. You can't even follow the
> > > > > > Linux From Scratch build instructions without that...)
> > > > >
> > > > > This is not easy. Consider three commands:
> > > > >
> > > > > v='/bin/*'; echo $v
> > > > > v='/bin/{a,b}*'; echo $v
> > > > > echo /bin/{a,b}*
> > > > >
> > > > > In the first case, unquoted $v is globbed *after* $v value is
> > > > > substituted, and echo prints long list of filenames in /bin.
> > > > >
> > > > > In the second case, echo prints just "/bin/{a,b}*"
> > > > >
> > > > > In the third case, echo prints all filenames in /bin which start
> > > > > from a and b.
> >
> > Wildcards can be inside the curly brackets as easily as outside:
> >
> > blah/{o?e,two.*}/*.txt
>
> For brace expansion, glob chars have no special meaning.
> It simply expands to:
>
> blah/o?e/*.txt blah/two.*/*.txt
>
> and then both words are globbed.
>
> > So either resolution happens at the same time, or you make multiple
> > resolution passes in which case keeping track of what was quoted and what
> > wasn't (and what was already expanded and what wasn't) is INSANE.
>
> It is already rather complex, with nested "...", $(cmd), `cmd`,
> ${var/pattern/repl} and so on. With backspace quoting on every level (with
> subtly different rules!). I'd say we are already in "insane" land.
>
> > > if we want to have more users,
> >
> > More than we have right now, when we don't support {} at _all_ even in
> > the trivial completely unquoted cases with no wildcards present?
> >
> > If we want more users, then we need to run their scripts. Don't worry
> > about what bash does or doesn't do in made-up examples, show me scripts
> > people are currently using which don't run under hush. And the only way
> > to do that is approximate bash's behavior closely enough that people
> > _try_ to run those scripts, meaning adding trivial {} support and then
> > seeing where it's insufficient and needs to be expanded.
> >
> > > we should be compatible with bash (latest one, if older ones
> > > are different).
> >
> > You're suggesting a need to be bug-for-bug compatible with something that
> > changes its behavior every version. That's not a viable course of
> > action.
>
> Rob, this is not a bug. Example of bugs:
It's inconsistent, the spec doesn't say what the correct behavior is, and the
behavior changes from version to version.
> for v in ""; do echo "v=$v"; done # prints "v=". ok
> for v in "$@"""; do echo "v=$v"; done # doesnt print anything!
How is that a bug? That's normal quote processing.
Just as "a""b" is combined together into the single argument "ab", "$...@}""x"
would be combined together into "$...@}x", so "$@""" is combined together into
"$@" which is then expanded normally, and in the case of no command line
arguments expands into zero arguments.
If you want a guaranteed null argument at the end of your list, you need a
space to separate the arguments:
for v in "$@" ""; do echo "v=$v"; done
> export a=`echo b c` # exports a='b c'
> "export" a=`echo b c` # not the same as above!
Putting quotes around export disables keyword evaluation in the first pass, so
you're well into undefined behavior territory if you ask me. I haven't checked
the spec but it seems like putting quotes around "export" could disable its
recognition as a shell builtin entirely, and thus it could probably legally
search $PATH for an executable called "export".
Instead the line gets re-parsed after the quotes are evaluated, the "export"
is recognized then, but the re-parsing breaks up arguments based on the spaces
they have at the time. *shrug* Either way, that's a "don't do that" sort of
thing.
> We do not have to implement bash behavior for insane cases like these.
I agree. We do not.
> But v='/bin/{a,b}*'; echo $v isn't a too far-fetched thing like above ones.
> Users WILL try something like it, and ask it to be fixed.
Wait for them to do so.
> Brace expansion and globbing are documented to be two different things.
>
> Implementing them incorrectly will force me later to rip them out,
> and reimplement correctly again. This already happened in ash's
> ${var/pattern/repl} code. It is broken now. "Simply" fixing it
> is not possible, it needs to be redone from scratch.
The ash code wasn't designed, it just sort of _happened_. And the bash man
page says what ${var/pattern/repl} is supposed to do, so there is something
other than a single implementation saying what to do there.
> I do not want to write the same thing twice.
I rewrote mount... four times, was it?
> > I note that dash still doesn't handle {} at all, and thus can't be used
> > to run this bit of LFS:
> >
> >
> > http://www.linuxfromscratch.org/lfs/view/6.7/chapter06/creatingdirs.html
> >
> > Now LFS gets away with that because they build bash in chapter 5, so they
> > know what they're running with. But I make my own chapter 5 equivalent
> > out of an Aboriginal Linux root filesystem and I need to build bash 2.05b
> > to get it to work. I cannot use hush for that case, because of the lack
> > of trivial {} support. Not because of some "quoted string stuck in a
> > variable then gets expanded in a way that changes the precedence of
> > braces vs wildcards" corner case bug, but because the basic functionality
> > isn't htere.
>
> I believe I implemented brace expansion in hush so that it passes
> all three these tests:
>
> v='/bin/*'; echo $v
> v='/bin/{a,b}*'; echo $v
> echo /bin/{a,b}*
I guess I should go report the inconsistent behavior to the bash people now,
and let them evaluate the inconsistency. They might fix it in the next
version, in which case you can claim you're compatible with older versions of
bash but not the current one.
> I dread to think what corner cases with escaped \{ and unpaired {}s
> I will need to chase down now...
It doesn't work that way.
Implement things that break existing bash scripts. Wait for people to try
more bash scripts. Speculatively implementing version-specific bash bugs in a
maze of twisty impossible to maintain corner is pointless.
Rob
--
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem
Forever, and as welcome as New Coke.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
