Roy Marples wrote:
> On Tue, 2007-10-02 at 19:37 +0100, Steve Long wrote:
>> Roy Marples wrote:
>> > With [[ ]] you don't need to quote, which encourages people not to
>> > bother learning when and when not to quote.
>> >
>> Ugh, that is so untrue imo. In #bash most people don't know [[ and use [
>> without quoting, as well as leaving out quotes elsewhere. Which is why we
>> beat them over the head about quoting _all_ the time (!quotes in #bash
>> [1])
>
> You should always quote when using [ - the only exception you can ever
> make is when using something like $? or $# as that is always a number.
>
Indeed.
>>
>> > Regular readers of -dev will also notice a large amount of people not
>> > quoting correctly, my view is that bash encourages this through the use
>> > of [[ ]].
>> >
>> A lot of those have been stuff like cd $S (when S could have spaces
>> according to where the tmp dir is located) and the like, ie stuff outside
>> [[. Honestly, [[ has got little to do with learning about quoting, since
>> the typical case where quoting is missing is when a path is passed to a
>> command. The thing to learn is that the shell expands everything before
>> passing it to a command, and that spaces will lead to two parameters
>> where you thought you had one, unless you use quotes. (ie cd "$S" )
>
> Everything in shell IS a command with the exception of variable
> assignment. Why do you think [ exist in /usr/bin?
>
Yes I know, it's the same reason greycat will often use test -e blah &&
blahBlah to show where the command comes from. (Which is why you use 'help
test' to see what tests are actually available.) It doesn't change the fact
that quoting issues show up outside [[, and you need to be aware of them in
bash just as much as in sh.
IMO the real reason you have such an issue with quoting is the redundant
braces which are Gentoo house style; too many newbie scripters think that
cd ${S} is safe when it should be cd "${S}" or more simply cd "$S". I don't
buy the legibility argument since most people use syntax highlighting. It
just sets the parser up for a non-event (yes I am *that* fussy about
cycles.) My suspicion is that it came from echo "${RD}message$NO"
> Once you think "everything is a command" then quoting becomes a lot
> easier. [[ ]] removes this concept.
>
Yeah but the point is you learn about quoting for every other command, or
you simply won't be writing reusable scripts (assuming they actually work
for you at all.)
>> Inside [[ is similar to assignment, in that it's down to the lex/parse
>> (eg
>> a=' omg spaces!'; b='oh Noes! '$a; echo "$b" # works fine -- but note
>> what happens when you echo $b with no quotes.) kojiro knows more about
>> the corner cases where quoting is needed in [[, but it _never_ shields
>> you from quoting issues outside tests, and you *will* be told about it if
>> you paste an unsafe loc in #bash. (We don't care if that's not the
>> current problem as you see it: if you're not quoting right, your scripts
>> are worse than useless, since they'll break when your users least expect
>> it, for no apparent reason, and you're nowhere to be found. People soon
>> learn not to paste unsafe expansions ;p and they get into the habit of
>> always quoting.)
>>
>> [1] USE MORE QUOTES! Read
>> http://bash-hackers.org/wiki/doku.php?id=syntax:words to understand why.
>> http://www.grymoire.com/Unix/Quote.html will tell you how. -- Optimally,
>> you should quote every parameter expansion ($foo).
>
> So in other words, [ ] always needs quotes whereas [[ ]] normally
> doesn't but could need quotes in corner cases.
>
> I know which I'd prefer - certainty over uncertainty.
>
Well to be absolutely honest I've never actually needed them, and I only
mentioned it for completeness as kojiro said there was some case (involving
array expansion iirc, so sh wouldn't even be able to express the metaphor,
let alone get in a twist about it.) It was definitely not the run-of-the
mill issue. I still would not give up pattern and regex matching (to name
my top two) in [[, and definitely not for the trade-down to sh, where you'd
be doing all kinds of odd syntax to get round the limitations of the
lowest-common denominator.
I'd prefer powerful, expressive tools which don't lock me into a proprietary
solution. A GNU userland seems a small price to pay, and we're only talking
about one app here, not the whole userland. (I had actually thought the
point of Gentoo/FBSD was to use the BSD kernel with Gentoo/GNU tools. It
seems odd that the tail is now wagging the dog, so to speak, much as I like
the idea. Can I ask why you are so resistent to Gentoo/FBSD using GNU
tools?)
I still don't see the use case, sorry. If an embedded system can't support
bash (and even if it could tbh) it'd be a fool who compiled on the target
imo. (I wouldn't put gcc on an embedded system for a start, but then I'm
old ;) And bash works everywhere else afaict. Who exactly does "freeing the
tree" help, and how is it such a great inconvenience for those users to
install bash?
Wrt choice, what about the developer choice to use a fully featured shell so
they don't have to write 5 loc where 1 would do, or mess around with
error-prone evals, and set which allows only 1 array etc? (I know you can
handle all kinds of weird quoting in eval, but it makes my head hurt, and I
would *hate* to maintain that kind of code.) Leave alone the choice not to
fix it, since it patently isn't broken.
One last point on arrays: it's true that you can pass an array to a
command/function with foo "[EMAIL PROTECTED]" but there's nothing to stop an
eclass
saying "we reference arrays bar baz and qux which you should populate
before using this eclass/function," and indeed accessing all three arrays
in the same function. The single case just isn't such a performance hit
compared to the whole configure/make cycle, and I'd imagine the locality is
preferred for maintenance.
Search a list of 250 pkgs repeatedly with inList "$pkg" "[EMAIL PROTECTED]" and
you
start to notice it, though ;)
--
[EMAIL PROTECTED] mailing list
