ADVENTURES IN BUG-SQUOOSHING: ZFILER
by Rick Charnes, after too much wine, 4/25/87, San Francisco

     I just spent 45 minutes or so on one of those fun tasks 
known as "bug-squooshing".  It's not something at which I make 
any pretense at making a living and don't do with any frequency. 
But it was satisfying to figure out and you always learn 
something after one of these sessions.  I thought I'd share it 
with other Z-ers in case you're in need of some good coffee-table 
gossip.  

     I have a ZFILER script in which one of the commands is:

                    erase $f,$n.bak

[note: for those using VFILER, substitute "%f" and "%n"]

Easy enough.  Erase the pointer file and its backup.  I like the 
classical ZCPR3 utilities with their file list capability.  This 
is an excellent and important feature, a big advance over CP/M 
programs that is not enough appreciated.  For some reason a good 
number of the Conn Z3 oldies but goodies have this feature 
(ERASE, FINDF, HELPPR [betcha didn't know that], LDR, MCOPY, 
PAGE, PRINT, PROTECT, etc.) but the new ZRDOS utilities don't 
(SFA, DFA, AC, VIEW, VTYPE).  Tell me why.  
 
     Anyway, something strange kept happening when I ran this 
macro on only a very few of my files.  ERASE.COM wouldn't 
properly erase the file but instead would return me its help 
message.  With most files it worked fine.  Why?

     I got another glass of wine and hunkered down.  I tried 
this, I tried that, I tried the other thing.  You know, the 
usual:  Did I have stray control characters in the script?  No.  
I rebooted.  No difference.  Then I noticed that the files on 
which it wasn't working all had one thing in common: they all had 
a filetype and this filetype consisted of exactly two letters, as 
in "HELLO.LT".

     But why would that make a difference?

     So, using the time-tested routine of "isolate as much as 
possible," I tried simply 

               ECHO TRYING TO ERASE $f...

OK, nothing special.  Then I tried it on another file, one 
without a filetype.  Something registered in my brain.  It was 
like one of those "what can you find wrong with this picture?" 
experiences where it only comes to you after you turn away and 
stop thinking about it.  The first file had displayed as

          TRYING TO ERASE IFCONT. ...

whereas the second was

          TRYING TO ERASE LETTER...

Notice anything different?  

     An extra space after the first filename.  

     It hit me: that was it.  Because what ended up getting sent 
to the CCP was exactly:

               ERASE IFCONT.HG ,IFCONT.BAK

See?  ERASE.COM couldn't figure out what I was trying to tell it.  
It thought I _might_ be sending it a file list, but that <SPACE> 
before the comma confused it.  Genuine filelists don't have 
spaces between the filenames.  Parameters do, but filelists 
don't.

     What seemed to be going on was that as per convention, the 
symbol "$f" was "padding" the filetype out to the 3 possible 
spaces.  Could I then never get my ERASE.COM filelist to work 
properly?  

     Well, I dug further.  I tried renaming it to "IFCONT.H" --- 
ONE character in the filetype.  It did NOT do the padding.  
Bizarre.  

     But at this point I guess somebody up there decided the plot 
wasn't thick enough yet, because after playing around a bit more 
I found a file with a two-character filetype that did not do the 
padding.  

     Then something in my brain went into automatic which happens 
if you use Z-Sys enough.  Images and lessons learned from past 
late-nighters float past your mind's eye like clouds in front of 
the moon on a chilly winter's night and help you out as 
beneficent and supportive friends.  I remembered back to a few 
months ago when noticing that VMENU's pointer _sometimes_ (and 
only sometimes) did not return to the pointed-to file after a 
command script was run.  One of the joys of Z-System is that you 
end up learning things that you never really wanted to learn, and 
I discovered after many, many hours of tracking this baby down 
that it would exhibit this strange behavior only on files whose 
archive bit was set.  Could this be the same thing?
     
     Yes.

     Result of bug-squooshing: ZFILER's "$f" symbol pads out the 
filename only on those files that (1) have a filetype, (2) said 
filetype is exactly two characters long, and (3) said file's 
archive (and perhaps other) bit is set.

     Now to see if I can "bug" Jay enough to fix it...