Re: PATCH: improve ${(q)...}

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Apr 29,  9:51am, Peter Stephenson wrote:
}
} > The proposed patch changes the behavior of nested (q) options rather
} > significantly.  E.g., ${(qqq)${(qq)v}} becomes very different.  This
} > could be important if the resulting string is going to be processed
} > with "eval".
} 
} I don't follow that.  The quotation is present if the inner quotation
} would cause the word to behave differently when unquoted.  Stripping
} multiple levels of quotation should therefore still work.  Or are you
} thinking of things like the example below?

I'm not necessarily thinking of any specific example.  With the current
code, ${(qqq)${(qq)v}} produces "'foo'" which still has single quotes
after one level of quotes is stripped.  If that's combined with another
string that also contains single quotes, whether by directly adjacent
concatenation or by interpolation inside a double-quoted string, etc.,
those quotes might mean something.
 
} I won't rely on my expectation here---it's different with backslash
} quoting anyway.  However, you've certainly spotted a case I hadn't where
} this changes the behaviour.  I can look for different letters...
} Hmm, we could use qQ which is currently meaningless as a sort of
} shorthand for "minimal quoting"...?

What does (qqQQ) mean, then?  Or (qQq)?  It'd probably be better to pick
something that currently isn't even valid syntax, like (q-) ... I was
all set to suggest (q1) (q2) etc. but (q0) already means "split at NULL
bytes and then quote".  However, (q-) raises the question of what (-q)
means, and whether (-) by itself means anything; the only character that
is currently "attached" to a preceding flag is ":" and (q:EXPR:) seems
like overkill.