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