Re: _call_program (and possibly other hooks) or opt_args quoting prob lem.

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On May 20,  9:43pm, Borsenkow Andrej wrote:
} Subject: Re: _call_program (and possibly other hooks) or opt_args quoting 
}
} > I'm not sure what you mean by "parameter value as it appears" -- is the
} > word "value" out of place in that phrase?
} 
} Once more:
} 
} user enters
} 
} $PWD/a\ b
} 
} as the "value" of option -d. When this is finally passed to a program
} for execution, shell expands $PWD so program actually sees (remove
} quotes) "/home/bor/test/a b". This is "real" value of option -d.
[...]
} I am sorry if it is confusing but I really do not understand what you do
} not understand ... it seems pretty clear to me :-)

I get it now.  The word "parameter" was what confused me -- zsh's use of
"parameter" to refer to shell variables like $PWD has always been a pain
in the brain.  Anyway, I couldn't tell whether you were talking about the
value of the parameter $PWD, or the presence of a parameter expansion in
the command-line arguments, or what.

On May 21, 10:14am, Sven Wischnowsky wrote:
} 
} I'm not sure if we should commit this patch, because, as was already
} pointed out, ${(e)...} on a string as it is reported now should give
} one the needed expansion. With the patch that would become ${(Qe)...}.
} 
} Any opinions?

Having looked at Andrej's example with _files, I think you should commit
the patch.  It would appear that the number of cases where we'd need to
insert uses of ${(e)...} without the patch, exceeds the number of cases
where we'd need to insert ${(Qe)...} with it.

However, that opinion is based on very superficial analysis, so if anyone
thinks otherwise ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net