Gulam bug? and turtle limitation.

Gulam bug? and turtle limitation.

Post by John Buchan » Tue, 02 Jan 1990 17:43:00

I was hacking away and found that this gulam file crashed gulam.  Does
anyone have any ideas on how to do this.  

if -e $MAN_LIB$
        more $MAN_LIB$
        echo No man entry for $1

I can see the file and then as I exit the shell crashes with 2 or 3 bombs.

I have set MAN_LIB d:\man\ in gulam.g.

TURTLE does not back up a file that does not fit on a floppy.  This could
prove to be a severe limitation.  Has anyone hacked this or done anything
about this.

John Buchanan                     Dynamic Graphics Project
                                  Computer Systems Research Institute
                                  University of Toronto
(416) 978-6619                    Toronto, Ontario M5S 1A4

UUCP:           ...!mcvax!!juancho

| Typical conversation on comp.[atari|amiga|mac].*                  |
My watch is better than yours.  It has multitasking, windows and


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. Old version transfer 5.25 to 3.5 disks?

3. gulam bug

4. I'm missing something (Motorola BSP vs US Robotics 128k)

5. Possible printing bug in Gulam

6. Deuteros help required

7. GULAM beta (bug???)

8. Mail Servers for ftp and more

9. Bug in VIEWER.APP & Gulam on Falcon

10. Bug in gulam alpha version - (nf)

11. gulam ls bug?

12. Bug in bets test Gulam

13. WARNING! Bug in Gulam v1.03