home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / CPM / ZCPR33 / S-Z / ZFILER.BUG < prev    next >
Text File  |  2000-06-30  |  5KB  |  109 lines
  1. ADVENTURES IN BUG-SQUOOSHING: ZFILER
  2. by Rick Charnes, after too much wine, 4/25/87, San Francisco
  3.  
  4.      I just spent 45 minutes or so on one of those fun tasks 
  5. known as "bug-squooshing".  It's not something at which I make 
  6. any pretense at making a living and don't do with any frequency. 
  7. But it was satisfying to figure out and you always learn 
  8. something after one of these sessions.  I thought I'd share it 
  9. with other Z-ers in case you're in need of some good coffee-table 
  10. gossip.  
  11.  
  12.      I have a ZFILER script in which one of the commands is:
  13.  
  14.                     erase $f,$n.bak
  15.  
  16. [note: for those using VFILER, substitute "%f" and "%n"]
  17.  
  18. Easy enough.  Erase the pointer file and its backup.  I like the 
  19. classical ZCPR3 utilities with their file list capability.  This 
  20. is an excellent and important feature, a big advance over CP/M 
  21. programs that is not enough appreciated.  For some reason a good 
  22. number of the Conn Z3 oldies but goodies have this feature 
  23. (ERASE, FINDF, HELPPR [betcha didn't know that], LDR, MCOPY, 
  24. PAGE, PRINT, PROTECT, etc.) but the new ZRDOS utilities don't 
  25. (SFA, DFA, AC, VIEW, VTYPE).  Tell me why.  
  26.  
  27.      Anyway, something strange kept happening when I ran this 
  28. macro on only a very few of my files.  ERASE.COM wouldn't 
  29. properly erase the file but instead would return me its help 
  30. message.  With most files it worked fine.  Why?
  31.  
  32.      I got another glass of wine and hunkered down.  I tried 
  33. this, I tried that, I tried the other thing.  You know, the 
  34. usual:  Did I have stray control characters in the script?  No.  
  35. I rebooted.  No difference.  Then I noticed that the files on 
  36. which it wasn't working all had one thing in common: they all had 
  37. a filetype and this filetype consisted of exactly two letters, as 
  38. in "HELLO.LT".
  39.  
  40.      But why would that make a difference?
  41.  
  42.      So, using the time-tested routine of "isolate as much as 
  43. possible," I tried simply 
  44.  
  45.                ECHO TRYING TO ERASE $f...
  46.  
  47. OK, nothing special.  Then I tried it on another file, one 
  48. without a filetype.  Something registered in my brain.  It was 
  49. like one of those "what can you find wrong with this picture?" 
  50. experiences where it only comes to you after you turn away and 
  51. stop thinking about it.  The first file had displayed as
  52.  
  53.           TRYING TO ERASE IFCONT. ...
  54.  
  55. whereas the second was
  56.  
  57.           TRYING TO ERASE LETTER...
  58.  
  59. Notice anything different?  
  60.  
  61.      An extra space after the first filename.  
  62.  
  63.      It hit me: that was it.  Because what ended up getting sent 
  64. to the CCP was exactly:
  65.  
  66.                ERASE IFCONT.HG ,IFCONT.BAK
  67.  
  68. See?  ERASE.COM couldn't figure out what I was trying to tell it.  
  69. It thought I _might_ be sending it a file list, but that <SPACE> 
  70. before the comma confused it.  Genuine filelists don't have 
  71. spaces between the filenames.  Parameters do, but filelists 
  72. don't.
  73.  
  74.      What seemed to be going on was that as per convention, the 
  75. symbol "$f" was "padding" the filetype out to the 3 possible 
  76. spaces.  Could I then never get my ERASE.COM filelist to work 
  77. properly?  
  78.  
  79.      Well, I dug further.  I tried renaming it to "IFCONT.H" --- 
  80. ONE character in the filetype.  It did NOT do the padding.  
  81. Bizarre.  
  82.  
  83.      But at this point I guess somebody up there decided the plot 
  84. wasn't thick enough yet, because after playing around a bit more 
  85. I found a file with a two-character filetype that did not do the 
  86. padding.  
  87.  
  88.      Then something in my brain went into automatic which happens 
  89. if you use Z-Sys enough.  Images and lessons learned from past 
  90. late-nighters float past your mind's eye like clouds in front of 
  91. the moon on a chilly winter's night and help you out as 
  92. beneficent and supportive friends.  I remembered back to a few 
  93. months ago when noticing that VMENU's pointer _sometimes_ (and 
  94. only sometimes) did not return to the pointed-to file after a 
  95. command script was run.  One of the joys of Z-System is that you 
  96. end up learning things that you never really wanted to learn, and 
  97. I discovered after many, many hours of tracking this baby down 
  98. that it would exhibit this strange behavior only on files whose 
  99. archive bit was set.  Could this be the same thing?
  100.      
  101.      Yes.
  102.  
  103.      Result of bug-squooshing: ZFILER's "$f" symbol pads out the 
  104. filename only on those files that (1) have a filetype, (2) said 
  105. filetype is exactly two characters long, and (3) said file's 
  106. archive (and perhaps other) bit is set.
  107.  
  108.      Now to see if I can "bug" Jay enough to fix it...
  109.