Re: SWISH-E 2.4.4 filters can not locate files
David L Norris <[email protected]> Wed, 18 Oct 2006 08:06:48 -0700 (PDT)
| Newsgroups | gmane.comp.web.swish-e |
|---|---|
| Message-ID | <[email protected]> |
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