Possible printing bug in Gulam

Possible printing bug in Gulam

Post by Ralph P. Sob » Fri, 02 Mar 1990 16:58:00



I have come across a * bug which seems to cause a print overrun
when I run my my batch file from Gulam, my favorite ST shell, from my
1040 STF.  This problem occurs in *all* 3 versions of Gulam that I
have: 1.00.00.xx, 1.03.04.05 (121887), 1.03.05.05 (03xx88) (I don't
have the actual numbers in front of me :-) Here's the batch file.  If
someone can see an error in it, I'd love to hear about it.

echo " Disk: $-n" >prn:
# cat a:\diskid.qqq > prn:
echo 'n' >prn:

foreach file { a:\...\*.arc }
        echo $file
        echo Verbose listing of $file : >prn:
        echo ' ' >prn:
        c:\arc\arc -v $file >prn:

        echo ' ' >prn:
        echo '...'
        sleep 8
endfor

This little procedure will print out a verbose listing of one of my
ARChive disks.  Normally, after a certain number of files are listed,
I get a -35 error.  After that Gulam can't find anymore files on any
disk!!  Leaving to the desktop and reentering Gulam does not help; it
doesn't even find gulam.g in the same directory.  And once, coming
back to the desktop, there were "0 Files" in all my windows!

It seems that some system tables somewhere were overridden.  The only
solution is to reboot, a warm boot suffices!  By the way, in my
C:\AUTO\ folder I have ETRNL2, ACACHE, FATSPEED, and GEMBOOT.  Would
any of these have an interaction?  If I remember correctly, FATSPEED
does do some patching for print redirection also.

Thanks.

--
Ralph P. Sobek                    Disclaimer: The above ruminations are my own.



 
 
 

Possible printing bug in Gulam

Post by Ralph P. Sob » Fri, 02 Mar 1990 18:08:00


I forgot to mention that the `sleep 8' in my batch file, actually does
help.  It delays the inevitable crash!
--
Ralph P. Sobek                    Disclaimer: The above ruminations are my own.




 
 
 

1. Fix bugs to fix bugs, or to Fix Bugs?


|[...] it seems that the system code performs the "cd .." command
|by stripping *one* directory from the current path.  However,
|the used algorithm doesn't make sense [if relative paths are passed in].

|    Should one only supply full pathnames to the file selector,
|    or should the described behaviour be considered a bug?

I think this is a case of "Doc, it hurts when I do this..." As Allan
has said, if the file selector misbehaves when you pass it a relative
filename, don't pass relative filenames to the file selector. It
bothers me when I see programs doing this, because what does "." mean
when a program brings up a file selector?  For all I know, the program
could change directories numerous times for its own devious purposes.
How the heck do I know what its idea of the current directory is?

Please use fully qualified pathnames in the file selector.  I know that
means you can't go very deep, but that's life on one line of a 40
column screen.

|Wouldn't this be an idea for a dc week utility. A TSR that parses all pathnames
|before calling the system routine. So these commercial applications will not
|cause problems to anyone.

I'd like to echo Allan's sentiments on this one, too... fixing "bugs"
for no other reason than to allow buggy programs to run is A Bad Idea.

Believe it or not, I may even be more rabid about this issue than Allan.
I think Atari should do everything in its power to discourage lazy
programming.  Our goal should be able to point at programs available on
our computers and show how easy they are to use, and how robust they are.
We shouldn't be required to apologize for the number of auto folder
programs that you need to patch various bugs/features/whatevers so that
programs X.PRG, Y.APP and Z.PRG can all coexist peacefully.

I think people who write little TSR helper programs shouldn't waste
their time writing auto folder patches that let DB Master One run
under TOS 6.7.  They should spend their time enhancing the utility
of TOS machines, so we move forward.

--
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>

2. Dowding book on spacing

3. Possible Laser C Ver 1 Bugs

4. InterNIC domain release time (grumble)

5. Corrupt data on disk -- possible bug?

6. TurtleBeach Pinnacle...is this the way to go for Pro Midi with a PC?

7. Dumas encode -- possible bug

8. NT can't see userlist

9. CIVILIZATION bug - solution possible?

10. CAB: A possible bug & request for authentication

11. gulam bug

12. Gulam bug? and turtle limitation.

13. GULAM beta (bug???)