On 04 Jun 2006 11:18:54 +0200, Dominik Vogt wrote: > > On Sun, Jun 04, 2006 at 12:50:19AM +0000, Mikhael Goikhman wrote: > > > > And finally, should $[ENV_VAR] like $[PATH] be quoted by default? > > Hm.
I think I convinced myself that we may continue not to quote it. > > I see pros and cons to do this. Most of variable values (even $PATH) has > > an expected value, so a user may guess about a proper quoting on his own. > > On the other hand, the consistent solution would be to always quote any > > string var. > > Hm, isn't the right way to fix this mess to rewrite the parser > from scratch? I have the impression that we're trying to solve > problems that are caused bay the flawed design. I like the current parser rules, because they are simple and intuitive for me. Of course we may adopt bash (or zsh) command line parsing rules or anything else, but I don't think that some completely new design may somehow solve all problems. It is probably possible to improve parser by adding contexts. I.e. have one rules for Exec processing, other for menu title context, other if we expand inside 'quoted' string, and so on. But still I would leave some control to a user. Let's consider this line: $[command] tail Should the variable be expanded into one word even if it contains spaces? I think, no, because we lose functionality this way. If someone wants one word, he would write: "$[command]" tail Now, what do we do if the variable contains a double quote? Should it be escaped? Hard question, one answer may be "no", because a user may prepare variable to have double quote, space, double quote, specially to overcome this one-word limit. And if he insists, then he may specify: $[command:dquote] tail or (also one-word, but using the single quote, the same effect here): $[command:quote] tail The question of the default filter is difficult. We may decide that: "$[command]" tail is equivalent either to always-one-word: "$[command:in-dquote]" tail or alternativelly to potentially-more-than-one-word: "$[command:noquote]" tail (Unlike "dquote" filter, "in-dquote" does not add surrounding double quotes, just escapes them.) All in all, I think we should have all these filters to give the user full control, regardless of the design. This is currently pretty easy to implement. But choosing good defaults may be not easy. Regards, Mikhael.
