Subj : Re: MultiMail config
To   : Jimmy Day
From : William McBrine
Date : Tue Oct 08 2002 10:34 pm

-=> Jimmy Day wrote to Greg Sears <=-

 JD> BTW, MM seems to work fine with or without these switches.  I put them
 JD> in as you outlined below,

Don't -- his switches were incorrect.

 JD> and I just have 2 more teeny questions -

 JD> 1) What does a "path to junk file" mean?

Um, _that_ doesn't mean anything. But I assume you meant to refer to the
comment "(must include an option to junk/discard paths!)". "Junk" here is a
verb. What this means is that, if a packet was archived with full pathnames
included (rare for a mail packet, and generally an error, but I've seen it
happen), you should tell the unarchiver to discard them when extracting
(i.e., to extract all files to a single directory, and ignore any archived
directories); and you should also tell the archiver not to include them
when building a reply packet.

In the case of PKZip/PKUnzip, discarding the path is the default behavior,
so you don't actually need to add an option to do it. Most other archivers
do need the option.

 JD> 2)  What does the "> NUL" switch do?

It redirects the screen output to the NUL file; i.e., sends it nowhere.  
It's not a switch, but a shell facility which works with all programs that
use standard DOS screen output. (Unfortunately, many DOS programs write
text to the screen in a way that bypasses this.) You can redirect the
output to a file instead, by specifying a filename instead of "NUL".

In this case, I recommend using the undocumented PKZip/PKUnzip command line
switch, "-#", rather than redirecting to NUL, because it should be faster
and use fewer system resources, if only infinitesimally.

.... 2 + 2 = 5 for extremely large values of 2.
--- MultiMail/Linux v0.44
 * Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

.