2019-06-20 09:03:38 +0700, Robert Elz: > Date: Wed, 19 Jun 2019 22:10:43 +0100 > From: Stephane Chazelas <[email protected]> > Message-ID: <[email protected]> > > | By that reasoning, we should also make sure that > | > | find . -name '"***"*.txt' > | > | finds files whose name starts with *** and end in .txt. Because > | "..." is a quoting operator for the shell (and shell globs), so > | it should apply to fnmatch() as well like for \. > > That would be nice - it would be more consistent
So in your ideal shell, a="'x'" echo $a would output x. Then I suppose a='`reboot`' echo $a would reboot and a='$HOME' echo $a would output the content of the $HOME variable. Well, rejoice, that shell exists, it's the Mashey shell from PWB UNIX in the 70s, which did that and more (and where double-quoting disabled it). > though actually > it would be even better to move the other way, and avoid having ' and " > as quoting chars affect glob matching in the shell, as that is the only > place where that happens, nothing else takes quote chars as anything > special in matching contexts. I'm not sure I follow. Are you saying that echo '*.txt' Should not output *.txt? > But neither of those is likely to happen - and it is just barely) possible > to explain to users that '' and "" (and eventually $'') quoting are special > in the shell, and essentially operate (as Joerg mentioned once before) as > if they inserted a \ before every char in the string (after any expansions > in it have been carried out). Then conceptually we have only \ as an > escape/quoting char, which applies everywhere, and should apply consistently. Yes, we agree that the shell syntax is arcane and confusing and counter-intuitive. I can't see how adding an extra layer of backslash processing is going to help. Implementing noglobsubst, noshwordsplit would help. > | In any case, I'm not even sure why we're arguing, the changes > | you're proposing > > I'm not actually proposing any changes. The standard as it is now > written is adequate. (Possibly excepting that one short sentence in > 2.13.1). It could do with some improvements in the wording to make > what it says now clearer, but in this particular area, nothing needs > to change. It's certainly not adequate. If it were and it was to be read as you read it, then all shells would have implemented it by now. If anything, it should be clarified explicitly, either way. [...] > | goes against what *ALL* shells have been documented to do for 50 > | years, so even if it was a good idea, POSIX could not possibly > | mandate it, without changing the name of the interface. > > Huh? What name of what interface? "pattern matching" - you > would be happy (or happier) if it was called something different, > but otherwise was just the same? That's weird... > > Or are you saying that every change to the sh spec reqires it to > be changed to some new name sh1 sh2 sh3 ... ?? Where would we be at > now, about sh1037 ? Yes, sh2020 would probably be a good idea. I hear the next version of ksh93 will actually be a ksh2002. New incompatible interface, new name. Or implement a BASH_COMPAT equivalent or a "use <the-new-interface>" a la perl (or bash's upcoming posixglob?) -- Stephane
