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'"
> 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
ICQ - 412039
Received on Wed Oct 18 08:08:41 2006