Thanks for the response, I've managed to get an 'expanded' version of downscan running by cribbing from the statusbar overlay.manifest. (need to study up on this xul/xpi stuff ;-})
My setup is a bit different from most. I run ClamAV's clamscan from a javascript wrapper (a Much bigger Time Waster than nay BAT file) on WinDoze 98SE (I know, I know, I'll upgrade as soon as it's 'financially feasible'). To make this work my 'AVProgram' is 'C:\WINDOWS\WSCRIPT.EXE' (the script host program, so moz has something to start) and the first 'parameter' is the fullPath to the script (with intentional spaces, just for fun). Then there are a few odd parameters and the target file.
The problem I was having was getting the script fullPath (with spaces) passed to wscript. The patch to fix it is included below and needs some explaining.
This problem has popped up in two firefox extensions that I know of (Download Scan and SafeDownload) and probably effects others that try to run exteranl programs on windoze. There may be some lingering confusion about the command 'Line' versus the command 'Args'. The command Line is a string processed by a shell command line processor into an array of arguments for the recieving program. The 'paramenters' on the command Line are seperated by spaces. If any parameter contains internal spaces, it must be 'quoted' with leading and trailing '"' characters to let the shell processor know that it's a single unit, not two or more parameters in sequence. If the parameter itself contains quotes, the parameter must be quoted and the internal quotes 'escaped' with a backslash ('\') character to let the command line processor know 'no, we're not there yet'. The command line processor uses these rules to turn the command Line string into an array or collection of 'arguments' for our program.
The recieving program generally doesn't care a fig for quotes and spaces, all it wants is to have each argument passed to it be complete. In many cases the programs' internal command processor will splice multiple args back together, but not always. In some cases leading/trailing quotes will be ignored but in others (most, in my experience) they will cause the program or function to blow up. What we need to do is to process the command Line into argiments in the same way (mostly) that the shell command line processor does.
The splitArgs(argString) function emulates some of the operations of the standard windoze command line processor. It splices quoted parameters into single units, trimming the leading/trailing quotes. It 'unescapes' escaped quotes internal to the parameter and passes any (and all) spaces to the argument. (Windoze cares deeply about multiple spaces in quoted paths, it will hose you bigTime if you mess with them. Hence the need to split on 'simple' space and pad multi spaces back into the qouted parts.)
For other AV programs that have parameters such as
/f foo or -b bar
and crash if they're split, jsut quote 'em. With the patch
"/f foo" or "-b bar"
will be passed as single arguments with no quotes.
The moz browser bug is verified (villified?) in my testing. Sticking any quote into an arg causes BadThings to happen. Usually the '"' is replaced by '\' but other strange things happen as well (see the test outputs below). splitArgs has a 'bugfix' switch which will just nuke all remaining quotes in any args if set on. When (if?) the bug is fixed enabling/disabling code should be added based on browser type/level/version. (exercise left for the student ;-)
My setup is such that I can't 'see' what moz is passing to windoze, I can only see the args array passed to moz and the scriptArgs array passed to me by wscript. With that caveat, here are some moz out/script in test results.
splitArgs output vs. windows/wscript args passed to script, one line per arg.
'normal' cases
input string = remove=foo bar roo
moz args in = 3,
remove=foo
bar
roo
win/wscript args out = 3,
remove=foo
bar
roo
input string = "remove=foo bar roo"
moz args in = 1,
remove=foo bar roo
win/wscript args out = 1,
remove=foo bar roo
input string = remove="foo bar roo"
moz args in = 1,
remove=foo bar roo
win/wscript args out = 1,
remove=foo bar roo
input string = "remove=\"foo bar roo\"" ('bugfix' ON)
moz args in = 1,
remove=foo bar roo ('escaped' quotes nuked)
win/wscript args out = 1,
remove=foo bar roo
escaped quote weirdness. bitten by moz bug, 'bugfix' switch OFF
input string = "remove=\"foo bar roo\"" (windoze legal)
moz args in = 1,
remove="foo bar roo"
win/wscript args out = 3,
remove=\foo
bar
roo\
input string = remove=\"foo bar roo\" (illegal, for test)
moz args in = 3,
remove="foo
bar
roo"
win/wscript args out = 1, (? who stitched it back up ?)
remove=\foo bar roo\
//// end test stuff
This is the patch. Comment out or remove the inidcated lines in downscanoverlay.js beginning at line 111
/*//// original downscan code, line 111
var args = AVArgs.split(" ");
// Put the path where it is supposed to be
for (var i=0; i<args.length; ++i) {
args
= args.replace(/%1/g, elmpath);
args = args.replace(/\[Path\]/g, elmpath); // for backwards compatibility
}
*//// end oruginal downscan code, begin splitArgs patch
Insert the line
var args = splitArgs(AVArgs);
and insert the splitArgs(argString) function anywhere in the scope it can be accessed. (Hint - between the commented out code and just before the call to the function works just fine.) The comment block optional.
Caveat - This patch has been tested on win98SE only. Other win versions may or may not get the same results, I have no way to test. As for how/if the patch will work with *nix systems, I haven't a clue. Volunteers?
- note - sorry 'bout the 'wraparounds'. you'll have to edit them out byt they should be pretty obvious. need a wider board or less long-winded posters.
[Unformatted Code removed]
