Hello Bob!

05 Aug 03 22:15, Bob Jones wrote to Mike Tripp:

 BJ> Then you are in favor of the line
 BJ> SEND NORMAL NOARC 
 BJ> is a NO-OP in the route.cfg file....

You're a programmer.  You know the difference between a NOP and a piece of
logic that is operating as designed and exhibiting the behavior documented
by its author.
===
one large packet file.  The command "Send  NoArc
" has the same net effect as "Change Normal 
".  This modifier apples to BinkleyTerm systems only.
===
 BJ> In my opinion, that is stupid.  I don't agree with your analogy as
 BJ> being equivalent.

"ren *.* *.tmp" isn't a NOP because the directory happens to be
empty during an execution.  "del *.tmp" isn't a NOP just because
only files with other extensions are present at the time.  The logic is
executed as designed with the parameters specified by the user and based on
the the data present.  The fact that the directory looks the same after the
run as it did before the run does not mean that any statement was not
executed precisely nor that the statements failed to run in a proper
top-down manner.

That's my analogy and I'm sticking with it. :)  It has served me well for
many years, has kept me from observing any behavior that didn't match my
expectations or that was inconsistent with the documentation while
maintaining my own ROUTE.CFG.

 BJ> I believe squish documentation states that the FIRST line found
 BJ> that matches is what is executed and that's it....

You are the first I've encountered with that expectation.  The closest
thing I can find is:

===
Routing commands in ROUTE.CFG are executed from top to bottom in
sequence.  In other words, if you place a certain routing command
before another, you can be assured that Squish will process each
command in the order you specified.

By default, unless routing commands are used for a given node,
mail will be sent directly to that node, uncompressed, using the
normal message flavour.  However, various routing commands can be
used to modify this behaviour.
===

 BJ> Any way....  I probably should have dropped this subject instead
 BJ> of replying.

No need to shy away from it, especially if you are planning to actively
develop an option that will change Squish so that it behaves more like
another program than Squish.  Just call it a "modification",
"enhancement", or "alternate approach" rather than
referring to a "fix" for a Squish "bug/feature" that's
long overdue because Squish "fails to execute in a proper top-down
manner". There's quite a few folks that have found it to be sane,
logical, documented, predictable behavior that's been successfully utilized
for years.

I would actually enjoy access to an OS/2 port that would let me experiment
with your approach...just to see what all the fuss is about.  My
"analogy" has me so trained to think like Squish, that I can only
imagine the pitfalls and not the benefits of the alternate approach.  I'm
intrigued, but not to the point of installing and configuring another OS or
tosser from scratch to see it in action.

.\\ike

--- GoldED/2 2.50+