| 1 |
Mike Frysinger wrote: |
| 2 |
|
| 3 |
> On Sunday 30 September 2007, Zac Medico wrote: |
| 4 |
>> Donnie Berkholz wrote: |
| 5 |
>> > On 04:52 Sat 29 Sep , Mike Frysinger wrote: |
| 6 |
>> >> does this work with multilines ? |
| 7 |
>> >> if [[ -e ${S}/asdfasdfasdf && \ |
| 8 |
>> >> -f ${WORKDIR}/moo ]] |
| 9 |
>> >> then |
| 10 |
>> >> |
| 11 |
>> >> this is a crappy example, but entirely correct when the if statement |
| 12 |
>> >> gets real long ... |
| 13 |
>> > |
| 14 |
>> > No, it doesn't. That's why I just made it a warning instead of a |
| 15 |
>> > failure, because it's not always going to work. |
| 16 |
>> |
| 17 |
>> If there aren't many false positives then we don't have to reduce it |
| 18 |
>> to a warning since they can use the new repoman --force option to |
| 19 |
>> force the commit. If there are many false positives then I think we |
| 20 |
>> should try to filter those out if possible so that we don't have to |
| 21 |
>> reduce it to a warning and spam people with bogus warning messages. |
| 22 |
> |
| 23 |
A place to start might be a list of all known variables from say the |
| 24 |
devmanual, along with whether they're allowed to be used as |
| 25 |
multi-parameters in `for' or function/cmd calls. So it's legitimate to see |
| 26 |
eg: for f in $A (even if it isn't space-proofed; that'd need an array.) |
| 27 |
Most variables like $S and $WORKDIR are 'scalar' so their expansions should |
| 28 |
always be quoted. |
| 29 |
|
| 30 |
By only focussing on known variables, we wouldn't be prone to false |
| 31 |
positives with user vars (for which we can't know what expansions are |
| 32 |
appropriate.) |
| 33 |
|
| 34 |
> i see --force as something you should use in order to get around |
| 35 |
> semi-serious (but there's a good reason for it) ... not something that |
| 36 |
> people should have to use to get around perfectly legit code ... |
| 37 |
> |
| 38 |
> maybe a new function in repoman that would eat a line as the shell defines |
| 39 |
> it (in other words, sucks in all line continuations) |
| 40 |
|
| 41 |
Is there no way to tie into the bash parser code with PyC? I don't know it |
| 42 |
very well, but I have a feeling you do.. ;) Other than that the KATE syntax |
| 43 |
highlighter for BASH was recently updated and is very effective. It might |
| 44 |
be a good starting point. |
| 45 |
|
| 46 |
|
| 47 |
-- |
| 48 |
gentoo-dev@g.o mailing list |
Archives