Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #3767 > unrolled thread

Basic does not clear file on open

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Basic does not clear file on open Bill Chatfield <billchatfield1@gmail.com> - 2017-08-11 07:58 -0700
    Re: Basic does not clear file on open Michael J. Mahon <mjmahon@aol.com> - 2017-08-11 11:33 -0500
      Re: Basic does not clear file on open Bill Chatfield <billchatfield1@gmail.com> - 2017-08-11 10:50 -0700
    Re: Basic does not clear file on open James Davis <JPD.Enterprises@outlook.com> - 2017-08-11 09:38 -0700
    Re: Basic does not clear file on open gids.rs@sasktel.net - 2017-08-11 13:38 -0700
      Re: Basic does not clear file on open Bill Chatfield <billchatfield1@gmail.com> - 2017-08-11 14:01 -0700
        Re: Basic does not clear file on open gids.rs@sasktel.net - 2017-08-11 23:41 -0700
          Re: Basic does not clear file on open gids.rs@sasktel.net - 2017-08-11 23:51 -0700
      Re: Basic does not clear file on open Michael J. Mahon <mjmahon@aol.com> - 2017-08-11 18:57 -0500
      Re: Basic does not clear file on open ewerst@msn.com - 2017-08-12 07:54 -0700
        Re: Basic does not clear file on open ewerst@msn.com - 2017-08-12 08:00 -0700
          Re: Basic does not clear file on open gids.rs@sasktel.net - 2017-08-12 12:29 -0700
            Re: Basic does not clear file on open ewerst@msn.com - 2017-08-13 09:11 -0700
              Re: Basic does not clear file on open Michael J. Mahon <mjmahon@aol.com> - 2017-08-13 13:40 -0500
              Re: Basic does not clear file on open gids.rs@sasktel.net - 2017-08-13 16:41 -0700
                Re: Basic does not clear file on open gids.rs@sasktel.net - 2017-08-13 16:58 -0700
                Re: Basic does not clear file on open ewerst@msn.com - 2017-08-13 19:08 -0700
                  Re: Basic does not clear file on open gids.rs@sasktel.net - 2017-08-14 07:46 -0700
          Re: Basic does not clear file on open Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2017-08-13 04:53 -0500
            Re: Basic does not clear file on open John Brooks <jbrooks@blueshiftinc.com> - 2017-08-13 14:30 -0700
              Re: Basic does not clear file on open Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2017-08-14 18:33 -0500
            Re: Basic does not clear file on open gids.rs@sasktel.net - 2017-08-13 16:49 -0700
              Re: Basic does not clear file on open Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2017-08-14 18:43 -0500
                Re: Basic does not clear file on open Bill Chatfield <billchatfield1@gmail.com> - 2017-08-15 06:13 -0700
                  Re: Basic does not clear file on open gids.rs@sasktel.net - 2017-08-15 13:22 -0700
                    Re: Basic does not clear file on open Bill Chatfield <billchatfield1@gmail.com> - 2017-08-15 13:26 -0700
                      Re: Basic does not clear file on open Antoine Vignau <antoine.vignau@laposte.net> - 2017-08-15 13:48 -0700
                        Re: Basic does not clear file on open Bill Chatfield <billchatfield1@gmail.com> - 2017-08-16 06:08 -0700

Page 1 of 2  [1] 2  Next page →

#3767 — Basic does not clear file on open

I'm testing a Basic program that writes to a text file. For some test runs, the output is shorter than others. In that case, I see text at the end of the file left over from previous tests. I can't remember what the right solution for this is and Google doesn't seem to know either. I can surely delete the file every time before writing to it, but is there a better solution?

10 LET D$=CHR$(4)
15 LET F$="STUFF"
20 PRINT D$;"OPEN ";F$
30 PRINT D$;"WRITE ";F$
40 PRINT "LINE 1"
45 PRINT "LINE 2"
50 PRINT D$;"CLOSE ";F$

RUN
45
LIST

10 LET D$=CHR$(4)
15 LET F$="STUFF"
20 PRINT D$;"OPEN ";F$
30 PRINT D$;"WRITE ";F$
40 PRINT "LINE 1"
50 PRINT D$;"CLOSE ";F$

RUN

The file STUFF still has both lines:

LINE 1
LINE 2

[toc] | [next] | [standalone]

#3768

Bill Chatfield <billchatfield1@gmail.com> wrote:
> I'm testing a Basic program that writes to a text file. For some test
> runs, the output is shorter than others. In that case, I see text at the
> end of the file left over from previous tests. I can't remember what the
> right solution for this is and Google doesn't seem to know either. I can
> surely delete the file every time before writing to it, but is there a better solution?
> 
> 10 LET D$=CHR$(4)
> 15 LET F$="STUFF"
> 20 PRINT D$;"OPEN ";F$
> 30 PRINT D$;"WRITE ";F$
> 40 PRINT "LINE 1"
> 45 PRINT "LINE 2"
> 50 PRINT D$;"CLOSE ";F$
> 
> RUN
> 45
> LIST
> 
> 10 LET D$=CHR$(4)
> 15 LET F$="STUFF"
> 20 PRINT D$;"OPEN ";F$
> 30 PRINT D$;"WRITE ";F$
> 40 PRINT "LINE 1"
> 50 PRINT D$;"CLOSE ";F$
> 
> RUN
> 
> The file STUFF still has both lines:
> 
> LINE 1
> LINE 2
> 

You need to delete the old file if you want to write a new one. 

One way to do this without error even if the "old" file doesn't yet exist
is by opening/creating the file, then deleting it prior to the "real" OPEN.


-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3770

On Friday, August 11, 2017 at 12:33:47 PM UTC-4, mjm...@aol.com wrote:
> Bill Chatfield <billchatfield1@gmail.com> wrote:
> > I'm testing a Basic program that writes to a text file. For some test
> > runs, the output is shorter than others. In that case, I see text at the
> > end of the file left over from previous tests. I can't remember what the
> > right solution for this is and Google doesn't seem to know either. I can
> > surely delete the file every time before writing to it, but is there a better solution?
> > 
> > 10 LET D$=CHR$(4)
> > 15 LET F$="STUFF"
> > 20 PRINT D$;"OPEN ";F$
> > 30 PRINT D$;"WRITE ";F$
> > 40 PRINT "LINE 1"
> > 45 PRINT "LINE 2"
> > 50 PRINT D$;"CLOSE ";F$
> > 
> > RUN
> > 45
> > LIST
> > 
> > 10 LET D$=CHR$(4)
> > 15 LET F$="STUFF"
> > 20 PRINT D$;"OPEN ";F$
> > 30 PRINT D$;"WRITE ";F$
> > 40 PRINT "LINE 1"
> > 50 PRINT D$;"CLOSE ";F$
> > 
> > RUN
> > 
> > The file STUFF still has both lines:
> > 
> > LINE 1
> > LINE 2
> > 
> 
> You need to delete the old file if you want to write a new one. 
> 
> One way to do this without error even if the "old" file doesn't yet exist
> is by opening/creating the file, then deleting it prior to the "real" OPEN.
> 
> 
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

Nice trick! Thanks!

[toc] | [prev] | [next] | [standalone]

#3769

Search for "Random" and/or "Sequential" in the "ProDOS" and "Integer BASIC" and "Applesoft BASIC" manuals.  IIRC, there is a way to force one or the other when you open or write to a file.

[toc] | [prev] | [next] | [standalone]

#3771

On Friday, August 11, 2017 at 8:58:26 AM UTC-6, Bill Chatfield wrote:
> I'm testing a Basic program that writes to a text file. For some test runs, the output is shorter than others. In that case, I see text at the end of the file left over from previous tests. I can't remember what the right solution for this is and Google doesn't seem to know either. I can surely delete the file every time before writing to it, but is there a better solution?
> 
> 10 LET D$=CHR$(4)
> 15 LET F$="STUFF"
> 20 PRINT D$;"OPEN ";F$
> 30 PRINT D$;"WRITE ";F$
> 40 PRINT "LINE 1"
> 45 PRINT "LINE 2"
> 50 PRINT D$;"CLOSE ";F$
> 
> RUN
> 45
> LIST
> 
> 10 LET D$=CHR$(4)
> 15 LET F$="STUFF"
> 20 PRINT D$;"OPEN ";F$
> 30 PRINT D$;"WRITE ";F$
> 40 PRINT "LINE 1"
> 50 PRINT D$;"CLOSE ";F$
> 
> RUN
> 
> The file STUFF still has both lines:
> 
> LINE 1
> LINE 2


It is a little easier to use ONERR and VERIFY

10 LET D$=CHR$(4)
15 LET F$="STUFF"
17 ONERR GOTO 24
20 PRINT D$;"VERIFY ";F$
22 PRIND D$;"DELETE ";F$

24 POKE 216,0
25 PRIND D$;"OPEN ";F$
30 PRINT D$;"WRITE ";F$
40 PRINT "LINE 1"
50 PRINT D$;"CLOSE ";F$

This only does the delete if the file exists and skips it if it doesn't.  This avoids the unnecessary opening of a file that doesn't exist.

[toc] | [prev] | [next] | [standalone]

#3772

On Friday, August 11, 2017 at 4:38:50 PM UTC-4, gid...@sasktel.net wrote:
> On Friday, August 11, 2017 at 8:58:26 AM UTC-6, Bill Chatfield wrote:
> > I'm testing a Basic program that writes to a text file. For some test runs, the output is shorter than others. In that case, I see text at the end of the file left over from previous tests. I can't remember what the right solution for this is and Google doesn't seem to know either. I can surely delete the file every time before writing to it, but is there a better solution?
> > 
> > 10 LET D$=CHR$(4)
> > 15 LET F$="STUFF"
> > 20 PRINT D$;"OPEN ";F$
> > 30 PRINT D$;"WRITE ";F$
> > 40 PRINT "LINE 1"
> > 45 PRINT "LINE 2"
> > 50 PRINT D$;"CLOSE ";F$
> > 
> > RUN
> > 45
> > LIST
> > 
> > 10 LET D$=CHR$(4)
> > 15 LET F$="STUFF"
> > 20 PRINT D$;"OPEN ";F$
> > 30 PRINT D$;"WRITE ";F$
> > 40 PRINT "LINE 1"
> > 50 PRINT D$;"CLOSE ";F$
> > 
> > RUN
> > 
> > The file STUFF still has both lines:
> > 
> > LINE 1
> > LINE 2
> 
> 
> It is a little easier to use ONERR and VERIFY
> 
> 10 LET D$=CHR$(4)
> 15 LET F$="STUFF"
> 17 ONERR GOTO 24
> 20 PRINT D$;"VERIFY ";F$
> 22 PRIND D$;"DELETE ";F$
> 
> 24 POKE 216,0
> 25 PRIND D$;"OPEN ";F$
> 30 PRINT D$;"WRITE ";F$
> 40 PRINT "LINE 1"
> 50 PRINT D$;"CLOSE ";F$
> 
> This only does the delete if the file exists and skips it if it doesn't.  This avoids the unnecessary opening of a file that doesn't exist.

That is a good improvement. +5 for finding a use for VERIFY. I thought that was useless. It's very interesting way to implement "if exists(file) then delete(file)".

[toc] | [prev] | [next] | [standalone]

#3775

On Friday, August 11, 2017 at 3:01:29 PM UTC-6, Bill Chatfield wrote:
> On Friday, August 11, 2017 at 4:38:50 PM UTC-4, gid...@sasktel.net wrote:
> > On Friday, August 11, 2017 at 8:58:26 AM UTC-6, Bill Chatfield wrote:
> > > I'm testing a Basic program that writes to a text file. For some test runs, the output is shorter than others. In that case, I see text at the end of the file left over from previous tests. I can't remember what the right solution for this is and Google doesn't seem to know either. I can surely delete the file every time before writing to it, but is there a better solution?
> > > 
> > > 10 LET D$=CHR$(4)
> > > 15 LET F$="STUFF"
> > > 20 PRINT D$;"OPEN ";F$
> > > 30 PRINT D$;"WRITE ";F$
> > > 40 PRINT "LINE 1"
> > > 45 PRINT "LINE 2"
> > > 50 PRINT D$;"CLOSE ";F$
> > > 
> > > RUN
> > > 45
> > > LIST
> > > 
> > > 10 LET D$=CHR$(4)
> > > 15 LET F$="STUFF"
> > > 20 PRINT D$;"OPEN ";F$
> > > 30 PRINT D$;"WRITE ";F$
> > > 40 PRINT "LINE 1"
> > > 50 PRINT D$;"CLOSE ";F$
> > > 
> > > RUN
> > > 
> > > The file STUFF still has both lines:
> > > 
> > > LINE 1
> > > LINE 2
> > 
> > 
> > It is a little easier to use ONERR and VERIFY
> > 
> > 10 LET D$=CHR$(4)
> > 15 LET F$="STUFF"
> > 17 ONERR GOTO 24
> > 20 PRINT D$;"VERIFY ";F$
> > 22 PRIND D$;"DELETE ";F$
> > 
> > 24 POKE 216,0
> > 25 PRIND D$;"OPEN ";F$
> > 30 PRINT D$;"WRITE ";F$
> > 40 PRINT "LINE 1"
> > 50 PRINT D$;"CLOSE ";F$
> > 
> > This only does the delete if the file exists and skips it if it doesn't.  This avoids the unnecessary opening of a file that doesn't exist.
> 
> That is a good improvement. +5 for finding a use for VERIFY. I thought that was useless. It's very interesting way to implement "if exists(file) then delete(file)".


Thanks!

Another thing you could do is use PRINT CHR$(0) as the end of text file marker, when writing to a text file.

Then when reading from the text file, just test for CHR$(0) to let you know that you are at the end of data of the text file, and ignore anything that comes after.

The file size will still be the size at which the most characters were stored, but if the text file is doing a lot of expanding and contracting, it is good to reserve a little extra space for it so for the most part, the file remains as contiguous sectors or blocks on disk.

[toc] | [prev] | [next] | [standalone]

#3776

On Saturday, August 12, 2017 at 12:41:51 AM UTC-6, gid...@sasktel.net wrote:
> On Friday, August 11, 2017 at 3:01:29 PM UTC-6, Bill Chatfield wrote:
> > On Friday, August 11, 2017 at 4:38:50 PM UTC-4, gid...@sasktel.net wrote:
> > > On Friday, August 11, 2017 at 8:58:26 AM UTC-6, Bill Chatfield wrote:
> > > > I'm testing a Basic program that writes to a text file. For some test runs, the output is shorter than others. In that case, I see text at the end of the file left over from previous tests. I can't remember what the right solution for this is and Google doesn't seem to know either. I can surely delete the file every time before writing to it, but is there a better solution?
> > > > 
> > > > 10 LET D$=CHR$(4)
> > > > 15 LET F$="STUFF"
> > > > 20 PRINT D$;"OPEN ";F$
> > > > 30 PRINT D$;"WRITE ";F$
> > > > 40 PRINT "LINE 1"
> > > > 45 PRINT "LINE 2"
> > > > 50 PRINT D$;"CLOSE ";F$
> > > > 
> > > > RUN
> > > > 45
> > > > LIST
> > > > 
> > > > 10 LET D$=CHR$(4)
> > > > 15 LET F$="STUFF"
> > > > 20 PRINT D$;"OPEN ";F$
> > > > 30 PRINT D$;"WRITE ";F$
> > > > 40 PRINT "LINE 1"
> > > > 50 PRINT D$;"CLOSE ";F$
> > > > 
> > > > RUN
> > > > 
> > > > The file STUFF still has both lines:
> > > > 
> > > > LINE 1
> > > > LINE 2
> > > 
> > > 
> > > It is a little easier to use ONERR and VERIFY
> > > 
> > > 10 LET D$=CHR$(4)
> > > 15 LET F$="STUFF"
> > > 17 ONERR GOTO 24
> > > 20 PRINT D$;"VERIFY ";F$
> > > 22 PRIND D$;"DELETE ";F$
> > > 
> > > 24 POKE 216,0
> > > 25 PRIND D$;"OPEN ";F$
> > > 30 PRINT D$;"WRITE ";F$
> > > 40 PRINT "LINE 1"
> > > 50 PRINT D$;"CLOSE ";F$
> > > 
> > > This only does the delete if the file exists and skips it if it doesn't.  This avoids the unnecessary opening of a file that doesn't exist.
> > 
> > That is a good improvement. +5 for finding a use for VERIFY. I thought that was useless. It's very interesting way to implement "if exists(file) then delete(file)".
> 
> 
> Thanks!
> 
> Another thing you could do is use PRINT CHR$(0) as the end of text file marker, when writing to a text file.
> 
> Then when reading from the text file, just test for CHR$(0) to let you know that you are at the end of data of the text file, and ignore anything that comes after.
> 
> The file size will still be the size at which the most characters were stored, but if the text file is doing a lot of expanding and contracting, it is good to reserve a little extra space for it so for the most part, the file remains as contiguous sectors or blocks on disk.


I should add though, that I believe this only works when using the GET routine to read a text file and not the INPUT routine.

[toc] | [prev] | [next] | [standalone]

#3773

<gids.rs@sasktel.net> wrote:
> On Friday, August 11, 2017 at 8:58:26 AM UTC-6, Bill Chatfield wrote:
>> I'm testing a Basic program that writes to a text file. For some test
>> runs, the output is shorter than others. In that case, I see text at the
>> end of the file left over from previous tests. I can't remember what the
>> right solution for this is and Google doesn't seem to know either. I can
>> surely delete the file every time before writing to it, but is there a better solution?
>> 
>> 10 LET D$=CHR$(4)
>> 15 LET F$="STUFF"
>> 20 PRINT D$;"OPEN ";F$
>> 30 PRINT D$;"WRITE ";F$
>> 40 PRINT "LINE 1"
>> 45 PRINT "LINE 2"
>> 50 PRINT D$;"CLOSE ";F$
>> 
>> RUN
>> 45
>> LIST
>> 
>> 10 LET D$=CHR$(4)
>> 15 LET F$="STUFF"
>> 20 PRINT D$;"OPEN ";F$
>> 30 PRINT D$;"WRITE ";F$
>> 40 PRINT "LINE 1"
>> 50 PRINT D$;"CLOSE ";F$
>> 
>> RUN
>> 
>> The file STUFF still has both lines:
>> 
>> LINE 1
>> LINE 2
> 
> 
> It is a little easier to use ONERR and VERIFY
> 
> 10 LET D$=CHR$(4)
> 15 LET F$="STUFF"
> 17 ONERR GOTO 24
> 20 PRINT D$;"VERIFY ";F$
> 22 PRIND D$;"DELETE ";F$
> 
> 24 POKE 216,0
> 25 PRIND D$;"OPEN ";F$
> 30 PRINT D$;"WRITE ";F$
> 40 PRINT "LINE 1"
> 50 PRINT D$;"CLOSE ";F$
> 
> This only does the delete if the file exists and skips it if it doesn't. 
> This avoids the unnecessary opening of a file that doesn't exist.
> 

Nice!

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3779

On Friday, August 11, 2017 at 3:38:50 PM UTC-5, gid...@sasktel.net wrote:
> 
> 
> It is a little easier to use ONERR and VERIFY
> 
> 10 LET D$=CHR$(4)
> 15 LET F$="STUFF"
> 17 ONERR GOTO 24
> 20 PRINT D$;"VERIFY ";F$
> 22 PRIND D$;"DELETE ";F$
> 
> 24 POKE 216,0
> 25 PRIND D$;"OPEN ";F$
> 30 PRINT D$;"WRITE ";F$
> 40 PRINT "LINE 1"
> 50 PRINT D$;"CLOSE ";F$
> 
> This only does the delete if the file exists and skips it if it doesn't.  This avoids the unnecessary opening of a file that doesn't exist.

You might want to look a little more closely at lines 22 and 25 (SYNTAX ERROR).

It might be worth noting that if the file is LOCKED or the diskette is WRITE PROTECTED, the VERIFY will fail, the ONERR will trigger, and of course the file will not be deleted.

If the VERIFY fails for other reasons (e.g., I/O ERROR), the file will also not be deleted.

By the way, it is possible to check the ONERR code with PEEK(222) to see if it is 6 (FILE NOT FOUND).

Tommy

[toc] | [prev] | [next] | [standalone]

#3780

On Saturday, August 12, 2017 at 9:54:43 AM UTC-5, ewe...@msn.com wrote:

> It might be worth noting that if the file is LOCKED or the diskette is WRITE PROTECTED, the VERIFY will fail, the ONERR will trigger, and of course the file will not be deleted.
> 

Correction:
The VERIFY will succeed but the DELETE will cause the ONERR to trigger.

[toc] | [prev] | [next] | [standalone]

#3785

On Saturday, August 12, 2017 at 9:00:45 AM UTC-6, ewe...@msn.com wrote:
> On Saturday, August 12, 2017 at 9:54:43 AM UTC-5, ewe...@msn.com wrote:
> 
> > It might be worth noting that if the file is LOCKED or the diskette is WRITE PROTECTED, the VERIFY will fail, the ONERR will trigger, and of course the file will not be deleted.
> > 
> 
> Correction:
> The VERIFY will succeed but the DELETE will cause the ONERR to trigger.


You're trying too hard and not thinking clearly.  You wouldn't try to write to a locked text file.

[toc] | [prev] | [next] | [standalone]

#3798

On Saturday, August 12, 2017 at 2:29:50 PM UTC-5, gid...@sasktel.net wrote:
> 
> You're trying too hard and not thinking clearly.  You wouldn't try to write to a locked text file.

Ok, let me try thinking more clearly.

Removing line 20 (the VERIFY command) from the program does the following:

1. Makes the BASIC program smaller.
2. Makes it more readable.
3. Makes it more efficient when the file already exists.
4. Doesn't make it less efficient when the file doesn't exist.
5. Accomplishes the same task as when it is in the program.

Point 3 above is especially true if the file is very large.

The early part of the code that "verifies" the file exists is nearly identical to the processing that takes place during the early part of the DELETE processing. When the file doesn't exist, both execute almost the exact same amount of code.  When the file exists, the VERIFY reads every disk sector of the file.

Tommy

[toc] | [prev] | [next] | [standalone]

#3799

<ewerst@msn.com> wrote:
> On Saturday, August 12, 2017 at 2:29:50 PM UTC-5, gid...@sasktel.net wrote:
>> 
>> You're trying too hard and not thinking clearly.  You wouldn't try to
>> write to a locked text file.
> 
> Ok, let me try thinking more clearly.
> 
> Removing line 20 (the VERIFY command) from the program does the following:
> 
> 1. Makes the BASIC program smaller.
> 2. Makes it more readable.
> 3. Makes it more efficient when the file already exists.
> 4. Doesn't make it less efficient when the file doesn't exist.
> 5. Accomplishes the same task as when it is in the program.
> 
> Point 3 above is especially true if the file is very large.
> 
> The early part of the code that "verifies" the file exists is nearly
> identical to the processing that takes place during the early part of the
> DELETE processing. When the file doesn't exist, both execute almost the
> exact same amount of code.  When the file exists, the VERIFY reads every
> disk sector of the file.
> 
> Tommy
> 

Good point. 

The only thing necessary is to trap (and ignore) any error in DELETE. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3803

On Sunday, August 13, 2017 at 10:11:52 AM UTC-6, ewe...@msn.com wrote:
> On Saturday, August 12, 2017 at 2:29:50 PM UTC-5, gid...@sasktel.net wrote:
> > 
> > You're trying too hard and not thinking clearly.  You wouldn't try to write to a locked text file.
> 
> Ok, let me try thinking more clearly.
> 
> Removing line 20 (the VERIFY command) from the program does the following:
> 
> 1. Makes the BASIC program smaller.
> 2. Makes it more readable.
> 3. Makes it more efficient when the file already exists.
> 4. Doesn't make it less efficient when the file doesn't exist.
> 5. Accomplishes the same task as when it is in the program.
> 
> Point 3 above is especially true if the file is very large.
> 
> The early part of the code that "verifies" the file exists is nearly identical to the processing that takes place during the early part of the DELETE processing. When the file doesn't exist, both execute almost the exact same amount of code.  When the file exists, the VERIFY reads every disk sector of the file.
> 
> Tommy


That is a good start, so now let me counter with

Brian makes a good point below about a file types.  The Verify command doesn't just verify the filename, but can also verify the file type to make absolutely it is a text file that is being deleted.

So the Verify command is a must.

[toc] | [prev] | [next] | [standalone]

#3806

On Sunday, August 13, 2017 at 5:41:23 PM UTC-6, gid...@sasktel.net wrote:
> On Sunday, August 13, 2017 at 10:11:52 AM UTC-6, ewe...@msn.com wrote:
> > On Saturday, August 12, 2017 at 2:29:50 PM UTC-5, gid...@sasktel.net wrote:
> > > 
> > > You're trying too hard and not thinking clearly.  You wouldn't try to write to a locked text file.
> > 
> > Ok, let me try thinking more clearly.
> > 
> > Removing line 20 (the VERIFY command) from the program does the following:
> > 
> > 1. Makes the BASIC program smaller.
> > 2. Makes it more readable.
> > 3. Makes it more efficient when the file already exists.
> > 4. Doesn't make it less efficient when the file doesn't exist.
> > 5. Accomplishes the same task as when it is in the program.
> > 
> > Point 3 above is especially true if the file is very large.
> > 
> > The early part of the code that "verifies" the file exists is nearly identical to the processing that takes place during the early part of the DELETE processing. When the file doesn't exist, both execute almost the exact same amount of code.  When the file exists, the VERIFY reads every disk sector of the file.
> > 
> > Tommy
> 
> 
> That is a good start, so now let me counter with
> 
> Brian makes a good point below about a file types.  The Verify command doesn't just verify the filename, but can also verify the file type to make absolutely it is a text file that is being deleted.
> 
> So the Verify command is a must.


After posting this I started thinking that maybe the DELETE command can also verify the file type with its command.

PRINT CHR$(4) "DELETE "FILENAME$",TTXT"

This may work as well.  But I still think the VERIFY command should still stand as it can also give other information about a file that may be important before deleting it, such as Date/time, size of file etc.

That way there can be IF statements between the Verify and Delete to make sure it really is ok to Delete.

[toc] | [prev] | [next] | [standalone]

#3808

On Sunday, August 13, 2017 at 6:41:23 PM UTC-5, gid...@sasktel.net wrote:
> 
> Brian makes a good point below about a file types.  The Verify command doesn't just verify the filename,
...
> So the Verify command is a must.


Earlier you wrote:
"You're trying too hard and not thinking clearly.  You wouldn't try to write to a locked file."  

You also wouldn't try to write to a non-text file.

We can write the program under various assumptions.

One assumption is that we don't have any clue what kind of files we might encounter on the disk and we need to make our program bullet proof.

The other assumption is that this is one user writing a program for their own use and they know what files are on the disk.  And they know that from previously running the program an unlocked text file is created and that to execute the program properly a second time the file needs to be deleted.

With your initial response I was under the second assumption based on "hey they don't know if the file exists, but if it does they know it isn't locked".

In that context, they don't need the VERIFY command.

Also the VERIFY command for DOS3.3(1983) does not have the functionality to check "other" information like type, date/time, size, etc.

[toc] | [prev] | [next] | [standalone]

#3809

On Sunday, August 13, 2017 at 8:08:15 PM UTC-6, ewe...@msn.com wrote:
> On Sunday, August 13, 2017 at 6:41:23 PM UTC-5, gid...@sasktel.net wrote:
> > 
> > Brian makes a good point below about a file types.  The Verify command doesn't just verify the filename,
> ...
> > So the Verify command is a must.
> 
> 
> Earlier you wrote:
> "You're trying too hard and not thinking clearly.  You wouldn't try to write to a locked file."  
> 
> You also wouldn't try to write to a non-text file.

These are two different things, so I don't appreciate being mis-quoted.
Locking a text file that you plan on editing is different than accidentally typing in a filename entry that happens to be of a different file type and might be accidentally deleted.


> We can write the program under various assumptions.
> 
> One assumption is that we don't have any clue what kind of files we might encounter on the disk and we need to make our program bullet proof.

This is where an experienced programmer learns to cover all their bases.  I like the saying that "a computer program is only as smart as the person who programmed it."


> The other assumption is that this is one user writing a program for their own use and they know what files are on the disk.  And they know that from previously running the program an unlocked text file is created and that to execute the program properly a second time the file needs to be deleted.

When writing programs for your own personal use and in a way you can understand, feel free to make all the assumptions you want.  I don't judge.  But if you plan on sharing your programs at some point, it would be nice, on my end anyways, if the program was more polished.

You are also missing one assumption.  What if a file does exist, but you don't want to over write it and it is not locked.


> With your initial response I was under the second assumption based on "hey they don't know if the file exists, but if it does they know it isn't locked".

That is ok if you only have one or two text files and are learning how to use them, you can keep track of them and know what is locked or what isn't.  But try that with 100's of text files, some are backups, some are duplicates, some locked, some unlocked, some have additional data, some are current, some are old.

 
> In that context, they don't need the VERIFY command.
> 
> Also the VERIFY command for DOS3.3(1983) does not have the functionality to check "other" information like type, date/time, size, etc.

I was hoping to show newbies some of the power of Prodos commands without telling them, they should create their applesoft programs based around Prodos.  But I guess "Verify" doesn't quite have that wow factor.

Look into the future a little bit.  What do you see once you learn how to use text files?

For me, I saw a very easy way to keep notes, have them sorted in folders, have an easy way to identify which ones have the most current and up-to-date information.  Verify helps to make sure the files are where they are supposed to be and duplicates are not over-written.  The potential I saw was my inspiration to writing good software.

This is what "VERIFY" can do for them under Prodos.

[toc] | [prev] | [next] | [standalone]

#3793

On 2017-08-12 10:00, ewerst@msn.com wrote:
> The VERIFY will succeed but the DELETE will cause the ONERR to trigger.

This is one of the reasons that i prefer the OPEN,DELETE,OPEN method; it 
will err for more relevant reasons--including a type mismatch.  I also 
just plain hate trapping errors; AppleSoft's error trap plumbing is 
clumsy, even before having to deal with its bugs.  (Would RESUME NEXT 
have been too much to ask for?)

On that note, it would be really sweet if there was a mode (perhaps 
invoked by a special prefix to a DOS command) wherein errors, instead of 
stopping the programme, would just set the error code.  Then error 
trapping could be almost as easy as it is in unixoid shell scripts.

e.g.

42 PRINT D$ ".OPEN" F$ : IF PEEK(222)>0 THEN PRINT "Unable to open " F$ 
: END

[toc] | [prev] | [next] | [standalone]

#3801

On Sunday, August 13, 2017 at 2:53:17 AM UTC-7, Brian Patrie wrote:
> > The VERIFY will succeed but the DELETE will cause the ONERR to trigger.
> 
> This is one of the reasons that i prefer the OPEN,DELETE,OPEN method; it 
> will err for more relevant reasons--including a type mismatch.  I also 
> just plain hate trapping errors; AppleSoft's error trap plumbing is 
> clumsy, even before having to deal with its bugs.  (Would RESUME NEXT 
> have been too much to ask for?)
> 
> On that note, it would be really sweet if there was a mode (perhaps 
> invoked by a special prefix to a DOS command) wherein errors, instead of 
> stopping the programme, would just set the error code.  Then error 
> trapping could be almost as easy as it is in unixoid shell scripts.
> 
> e.g.
> 
> 42 PRINT D$ ".OPEN" F$ : IF PEEK(222)>0 THEN PRINT "Unable to open " F$ 
> : END

It would be easy to delete files using a small assembly routine which called the ProDOS MLI and returned an error code.

BTW: Seems like the sequence should be unlock, then delete unless you want prevent locked files from being deleted.

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web