Am Donnerstag, den 14.07.2005, 19:41 +0200 schrieb A. Pagaltzis:
> * Lars Lindner <lars.lindner@...> [2005-07-14 19:20]:
> > Removing all quotes from the user passed string looks like the
> > best solution. Also we shouldn't quote escaped shell strings.
> I object. I’ve used quotes to pass strings with whitespace to
> commands in various contexts, and I’d rather be annoyed to find I
> I was going to suggest looking for `'%s'` or `"%s"` and treating
> them as `%s`, but that’s not without problems either, since it
> makes it impossible to concatenate *surrounding* quoted strings
> to a parameter, as in something like
> sendcmd 'open '%s' behind'
> where the `sendcmd` programs gets called with a single argument,
> the string `open http://example.com/ behind` including spaces.
> The only reliable way I can think of if you want to hand-hold the
> user is to bypass the shell by tokenizing the string using
> g_shell_parse_argv(), perform %s-substitution on each argument
> separately, and then use exec() or something where the shell is
> never called.
> But then the user can’t use redirections, environment variables,
> and the like.
> Hmm. Maybe that’s fine, since people who want to complex things
> can (and possibly should) write a script for that.
> OTOH, the given example could be written as
> sendcmd open\ %s\ behind
> so maybe removing quotes around `%s` is the way to go – as long
> as you document this extravagnt behaviour somewhere, anyway.
> Not sure what would be best, but just removing all quotes sounds
> like a bit of an extreme measure to me.
You are right. I didn't thought of the typically remote
command syntax parameters used with Mozilla compatible/based
browsers. I only thought of simple "<browser-cmd> url" command
line pairs, which I still think are the most common use case
for the user defined browser setting.