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