On Thu, Jul 13, 2006 at 06:39:40PM +0200, Viktor Griph wrote: > On Thu, 13 Jul 2006, Dominik Vogt wrote: > > >On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: > >>On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] > >>>Hm, now that I think about it, the new functionality deviates from > >>>the way the old $0 ... worked in important ways which should be > >>>fixed: > >>> > >>>* A range of args like $[0-1] is expanded to the original text, > >>> not the unquoted form. > >>> > >>> I.e. in 'foo "a0" "a1" "a2"' > >>> > >>> $[0-1] is expanded to '"a0" "a1"' but should be expanded to > >>> 'a0 a1'. > >> > >>Do we really want that? It prevents passing arguments on to another > >>function. The way it is now (quote-persistent) is as $* has worked, and is > >>essensial for pasing multiple parameters on to another function without > >>risking that they split into more parameters than intended. I believe that > >>the current way is a good default until the variable quote system has been > >>implemented. > > > >Yes, I really want that. Fvwm has always worked this way and > >changing this would break many functions. Mikhael suggested > >several times to add some notion of expansion modifies to instruct > >fvwm to quote the result, i.e. $[quote:0] to get '"0"' instead of > >'0'. I think this is the right approach. > > > >The fact that $* works differently just means that it's broken.
> $* has always worked they way it works as well. I for sure have some > functions that rely on passing arguments to other functions, so changing > the behaviour of $* would break my config. Also reading the todo-vars file > it states that $[<number>] should be unquoted for backwardscompability. > The $[<range>] can be treated differently as that is a new feature. I see > use for both the 'raw' style and the unquoted style, but as I understand > the todo it really should be single-quoted as they are niether $[<number>] > not $[<range>], which are the only exceptions to that rule listed. > > Regarding the dequoting of the positional parameters I belive the best > thing would be to make a function to unquote an entire string. I'm not > sure how optimized it is to peek every token just to get rid of the > quotings. Also the most flexible code for the argument expansion would be > keeping the raw string as long as possible, and then dequote it and > possible requote it depending on filter-selection. No, I think that is the wrong approach. Disregarding the fact that there won't be big changes in the parser before 3.0, its job is: * To read in tokens from a command line and provide them to the functions that use the parser. * To allow embedding whitespace and other special characters in tokens, the caller may quote parts of the token with double or single quotes, backticks and backslashes. * The parser has to remove one level of quoting every time it parses a token because *that is what the quoting was made for*. * If a function wants to pass a token to another command or function, it has to quote the token. The problem in fvwm is that there is no safe way to quote a token. The correct fix is to provide that functionality, not to modify the parser to do obscure things. I should never have coded the parameter $* in the way I did but should have called it $@ instead ($@ in shells works as $* now works in fvwm). > Maybe the best thing is to remove the $[<range>] alltogether until the > filter-system is ready to not add another exception to how things work. > I'd really like to hear Mikhael's opinion on this. Note that passing arguments without dequoting them introduces subtle problems. Assume you have a function that takes a random number of (possibly quoted) arguments and passes them to a shell command: AddToFunc foobar + I Exec ls $* In this case, the arguments are filenames. Since the shell interprets the command, the caller of the function needs to choose a shell-compatible way of quoting. For example, he could say foobar "file with spaces" with double quotes but not foobar `file with spaces` with backticks. [snip] Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
