| 1 |
Doug Goldstein wrote: |
| 2 |
> I know the other thing I didn't answer was the fact that some variables |
| 3 |
> aren't quoted. It doesn't matter at all considering their configure |
| 4 |
> script can't handle spaces in the path names anyway. We've been though |
| 5 |
> that already. Additionally, qmake can't handle spaces in there even if |
| 6 |
> you do quote so it really doesn't matter much. |
| 7 |
> |
| 8 |
I disagree: it's important to do the correct thing, wrt spaces in filenames, |
| 9 |
in scripts, since there is a well-understood method of doing so (quoting) |
| 10 |
and once it is correct, it is always correct no matter what use is made of |
| 11 |
it in the future. If upstream tools can't deal with them, then they need to |
| 12 |
be fixed. I appreciate that might not happen for this configure script, but |
| 13 |
it shoud happen for qmake. (I find it hard to believe that qmake can't deal |
| 14 |
with spaces in filenames tbh, not from experience: it just sounds |
| 15 |
amateurish.) |
| 16 |
|
| 17 |
> Some of these review changes truly feel like working at a company where |
| 18 |
> you know the ins and outs of your tool. You can rattle off its |
| 19 |
> capabilities to a millimeter. A new boss/manager comes in and has no |
| 20 |
> idea what the tool is or the mission but by god he knows how to do your |
| 21 |
> job better and you will follow his procedures. It makes no difference if |
| 22 |
> his steps have no effect on the tool and waste more of your time. You |
| 23 |
> additionally have to start giving him progress reports on how you're |
| 24 |
> doing using his procedures, which instantly means you get less work done. |
| 25 |
> |
| 26 |
> That's what this commits review list feels like. |
| 27 |
|
| 28 |
Fair enough: that's how you feel about it. The quoting issue isn't new |
| 29 |
though[1]: that it hasn't been picked up on before is no excuse for not |
| 30 |
fixing it now, imo. The tool in question is bash, not the upstream |
| 31 |
configure script or qmake, and correct usage should be a point of pride: |
| 32 |
again, only my opinion. |
| 33 |
|
| 34 |
Then again, no-one's making you report back-- you're not under any |
| 35 |
contractual obligation to respond: must just be professional pride? ;-) |
| 36 |
|
| 37 |
[1] http://www.grymoire.com/Unix/Quote.html |
| 38 |
http://bash-hackers.org/wiki/doku.php?id=syntax:words explains why and how |
| 39 |
the issue arises. |
| 40 |
|
| 41 |
|
| 42 |
-- |
| 43 |
gentoo-dev@g.o mailing list |
Archives