On Wed, 2006-10-18 at 07:40 -0700, Bill Moseley wrote:
> It's hard to fix a fundamentally broken design.  And the patch seems
> to not really have helped.
> 
> Dave's example:
>     '/path/to/'&& rm -Rf /'&&echo .pdf'
>     => \'/path/to/\'&& rm -Rf /\'&&echo .pdf\'
> 
> Ok, what about this:
>     \'/path/to/\'&& rm -Rf /\'&&echo .pdf\'
>     => \\'/path/to/\\'&& rm -Rf /\\'&&echo .pdf\\'
> 

I think the original patch would avoid that by escaping every non-alnum
character.  Current CVS is problematic for several reasons.

> The code also has some buffer overrun potential.

I would agree.

> Might have to change FileFilter option from:
> 
>     FileFilter .doc catdoc "-s8859-1 -d8859-1 '%p'"
> 
> to
> 
>     FileFilter .doc catdoc -s8859-1 -d8859-1 %p
> 
> which makes more sense.

Then everything after the command becomes an array of arguments?

> Not sure how to do that on Windows where I'd still use popen.  I don't
> have a way to test on Windows.

On Windows we could wrap double quotes around %p and other variables
before passing them to popen().  Its (effectively) impossible to create
a file with double quotes in the name.  And the shell, if you want to
call it that, doesn't understand escaping or anything like that.

If you want to use a fork-exec on UNIX we probably could use
CreateProcess on Windows as you mentioned the other day.  But I think
we'd still want to fallback to popen() for other systems which don't
have fork.  (Not that I can name many off hand...  Maybe VMS?)

-- 
 David L Norris
  http://webaugur.com/
  ICQ - 412039