Hello,
Is there anything special that I need to do to commit a file to disk after I have written to it? My old Pascal book says to use...
CLOSE(FILEHANDLE,LOCK);
...which gpc complains about. I have tried...
CLOSE(FILEHANDLE);
...which compiles okay, but doesn't seem to commit the data (I wind up with a zero-length file.
I've tried including the filename in the program parameters, which is suggested by the book, but gpc didn't seem to like that either.
I'm also not sure whether I need to pass the file handle as a parameter to the procedure that's doing the writing, or how I would do that (I did try, but without success).
This is my first Pascal program... http://grex.cyberspace.org/~ball/test5.pas
- Andy.
Andy Ball wrote:
Is there anything special that I need to do to commit a file to disk after I have written to it? My old Pascal book says to use...
CLOSE(FILEHANDLE,LOCK);
Just FMI, which Pascal compiler is this? We've seen various syntaxes in this area, but I can't remember seeing this one.
...which gpc complains about. I have tried...
CLOSE(FILEHANDLE);
That's ok. You can even omit it entirely (according to standard Pascal, files are closed automatically).
When I compile with a recent GPC (gpc-20030830), I get the:
warning: `RecordSave' defined but not used
(Hint! :-)
I'm also not sure whether I need to pass the file handle as a parameter to the procedure that's doing the writing, or how I would do that (I did try, but without success).
Since it's a global variable, you don't have to pass it, but you can (`procedure Foo (var NewMaster: StudentRecordFile)' where `StudentRecordFile' is defined as `file of StudentRecord').
Frank
ih8mj@fjf.gnu.de wrote:
Andy Ball wrote:
Is there anything special that I need to do to commit a file to disk after I have written to it? My old Pascal book says to use...
CLOSE(FILEHANDLE,LOCK);
Just FMI, which Pascal compiler is this? We've seen various syntaxes in this area, but I can't remember seeing this one.
UCSD P-system unless my memory fails me.
david@tcs01.demon.co.uk wrote:
ih8mj@fjf.gnu.de wrote:
Andy Ball wrote:
Is there anything special that I need to do to commit a file to disk after I have written to it? My old Pascal book says to use...
CLOSE(FILEHANDLE,LOCK);
Just FMI, which Pascal compiler is this? We've seen various syntaxes in this area, but I can't remember seeing this one.
UCSD P-system unless my memory fails me.
Yes, UCSD Pascal, e.g. see the description on page 28-29 of the Apple II UCSD Pascal Language Reference.
CLOSE ( FILEID [, OPTION] )
where OPTION may be one of the following: NORMAL, LOCK, PURGE or CRUNCH.
Regards,
Adriaan van Os
Adriaan van Os wrote:
david@tcs01.demon.co.uk wrote:
ih8mj@fjf.gnu.de wrote:
Andy Ball wrote:
Is there anything special that I need to do to commit a file to disk after I have written to it? My old Pascal book says to use...
CLOSE(FILEHANDLE,LOCK);
Just FMI, which Pascal compiler is this? We've seen various syntaxes in this area, but I can't remember seeing this one.
UCSD P-system unless my memory fails me.
Yes, UCSD Pascal, e.g. see the description on page 28-29 of the Apple II UCSD Pascal Language Reference.
CLOSE ( FILEID [, OPTION] )
where OPTION may be one of the following: NORMAL, LOCK, PURGE or CRUNCH.
As an informational note, Apple did not carry this feature forward into their Macintosh Pascal language implementation. For the Macintosh Pascal language implementation, CLOSE(file-variable) is the only thing supported.
Gale Paeper gpaeper@empirenet.com
----- Original Message ----- From: david@tcs01.demon.co.uk To: gpc@gnu.de Sent: Sunday, April 18, 2004 8:16 AM Subject: Re: Closing a file
ih8mj@fjf.gnu.de wrote:
Andy Ball wrote:
Is there anything special that I need to do to commit a file to disk after I have written to it? My old Pascal book says to use...
CLOSE(FILEHANDLE,LOCK);
Just FMI, which Pascal compiler is this? We've seen various syntaxes in this area, but I can't remember seeing this one.
UCSD P-system unless my memory fails me.
UCSD has the form:
close(filename, option)
Where option is a "word":
normal lock purge crunch
Note that a filename (not handle or var file reference) is used, and that "word" as option pretty much requires close to be a compiler built-in statement.
From "The UCSD Pascal Handbook", Clark & Koehler.
You will find similar constructs in other compilers, since many compilers copied UCSD, including Apple.
Scott Moore wrote:
UCSD has the form:
close(filename, option)
Where option is a "word":
normal lock purge crunch
Note that a filename (not handle or var file reference) is used, and that "word" as option pretty much requires close to be a compiler built-in statement.
Ugh. So they are not even predefined constants?
Also the filename seems problematic to me. What if several files are opened to the same file name? Then add the problems if directories were changed (as discussed recently in a similar situation). I don't think we want to emulate this ...
Frank
Scott Moore wrote:
UCSD has the form:
close(filename, option)
Where option is a "word":
normal lock purge crunch
Note that a filename (not handle or var file reference) is used, and that "word" as option pretty much requires close to be a compiler built-in statement.
Ugh. So they are not even predefined constants?
Also the filename seems problematic to me. What if several files are opened to the same file name? Then add the problems if directories were changed (as discussed recently in a similar situation). I don't think we want to emulate this ...
UCSD was interpretive, so using the name string has the primary method of identifying a file was not a speed problem. Its a pretty good example of how implementation assumptions don't generalize well.
Using "word symbols" is actually the recommended method to use (standardwise) to prevent polluting the reserved tolken space. For example, "forward" and "external" are "word symbols". There are, or were, whole languages that work like that, leading to lots of ambiguous constructs.
Scott Moore wrote:
Also the filename seems problematic to me. What if several files are opened to the same file name? Then add the problems if directories were changed (as discussed recently in a similar situation). I don't think we want to emulate this ...
UCSD was interpretive, so using the name string has the primary method of identifying a file was not a speed problem. Its a pretty good example of how implementation assumptions don't generalize well.
Yes, but I wasn't talking just about speed, also about ambiguities (both with several files open for the same name and with changed directories).
Using "word symbols" is actually the recommended method to use (standardwise) to prevent polluting the reserved tolken space. For example, "forward" and "external" are "word symbols". There are, or were, whole languages that work like that, leading to lots of ambiguous constructs.
Well, constants don't pollute this space either, since they're not reserved. Otherwise, a magic integer (or char or whatever) value would have served quite well. Personally I find it quite gross to introduce a "word symbol" (which is outside the regular syntax, i.e. it can't be defined by Pascal code, and it requires special parsing) just for one single routine.
BTW, I don't find evidence of this as a "recommended method" in the standards. In fact, they say: "No identifier shall have the same spelling as any word-symbol." So a "word-symbol" is (the standard's terminology for) a reserved word. The standards mention directives (if you mean these), but "A directive shall only occur in a procedure-declaration or a function-declaration. The only directive shall be the required directive `forward'". `external' is also non-standard, there's only a note that says: "Many processors provide, as an extension, the directive `external' [...]".
Scott Moore wrote:
A table follows, listing the actions caused by certain characters in that first position of a printed line...
Symbol Action ----------- --------------------------------- blank space advance one line before printing 0 (zero) advance two lines before printing 1 skip to top of next page before printing + do not advance (will overprint)
This is the original print line convention proposed by Wirth. It was discarded for the ISO standard.
Thank God! (For fear of getting into another flamewar about CR/LF conventions and the corresponding C syntax, I'll leave it at that. ;-)
Frank
Scott Moore wrote:
Scott Moore wrote:
UCSD has the form:
close(filename, option)
Where option is a "word":
normal lock purge crunch
Note that a filename (not handle or var file reference) is used, and that "word" as option pretty much requires close to be a compiler built-in statement.
Ugh. So they are not even predefined constants?
[snip]
Using "word symbols" is actually the recommended method to use (standardwise) to prevent polluting the reserved tolken space. For example, "forward" and "external" are "word symbols". There are, or were, whole languages that work like that, leading to lots of ambiguous constructs.
Scott, I think you're getting your terminology mixed up. Word-symbol is the term both ISO standards use for those token spellings which are reserved solely for language syntatic use, e.g., "begin", "end", etc. are word-symbols. For "forward" (ISO 7185 and 10206), "interface" and "implementation" (ISO 10206), both standards use the term directive to refer to those spellings which have special language significance only in specified syntax slots and are spellings available for user defined uses outside those specified syntax slots.
Therefore, 'Using "word symbols"' is not the recommended method (standardwise) since it does pollute 'the reserved tolken space'.
Gale Paeper gpaeper@empirenet.com
Scott Moore wrote:
UCSD has the form:
close(filename, option)
Where option is a "word":
normal lock purge crunch
Note that a filename (not handle or var file reference) is used, and that "word" as option pretty much requires close to be a compiler built-in statement.
Ugh. So they are not even predefined constants?
Also the filename seems problematic to me. What if several files are opened to the same file name? Then add the problems if directories were changed (as discussed recently in a similar situation). I don't think we want to emulate this ...
Frank
I was incorrect. The book calls it a "filename", but I was looking through some old UCSD source programs, and close(file, lock) clearly uses "file" as in "file of text", ie, the file, not its name.
Sorry 'bout that.
Scott Moore wrote:
Scott Moore wrote:
UCSD has the form:
close(filename, option)
Where option is a "word":
normal lock purge crunch
Note that a filename (not handle or var file reference) is used, and that "word" as option pretty much requires close to be a compiler built-in statement.
Ugh. So they are not even predefined constants?
Also the filename seems problematic to me. What if several files are opened to the same file name? Then add the problems if directories were changed (as discussed recently in a similar situation). I don't think we want to emulate this ...
I was incorrect. The book calls it a "filename", but I was looking through some old UCSD source programs, and close(file, lock) clearly uses "file" as in "file of text", ie, the file, not its name.
OK, much better then. :-) So except for the 2nd parameter it's the same as in the other dialects I know.
BTW (don't kill me ;-), if someone really wants to use it like this it in GPC, they can use the preprocessor (except it will then accept *anything* for the 2nd parameter).
{$define Close(f, x) Close (f)}
Frank
Frank Heckenbach wrote:
Scott Moore wrote:
Scott Moore wrote:
UCSD has the form:
close(filename, option)
Where option is a "word":
normal lock purge crunch
Note that a filename (not handle or var file reference) is used, and that "word" as option pretty much requires close to be a compiler built-in statement.
Ugh. So they are not even predefined constants?
Also the filename seems problematic to me. What if several files are opened to the same file name? Then add the problems if directories were changed (as discussed recently in a similar situation). I don't think we want to emulate this ...
I was incorrect. The book calls it a "filename", but I was looking through some old UCSD source programs, and close(file, lock) clearly uses "file" as in "file of text", ie, the file, not its name.
OK, much better then. :-) So except for the 2nd parameter it's the same as in the other dialects I know.
BTW (don't kill me ;-), if someone really wants to use it like this it in GPC, they can use the preprocessor (except it will then accept *anything* for the 2nd parameter).
{$define Close(f, x) Close (f)}
The program wouldn't behave as expected, because the second parameter isn't meaningless, e.g. x=CRUNCH sets the end-of-file to the point of last access. So, I guess, it is better to change UCSD Pascal source code when porting to GPC (or to another Pascal).
Regards,
Adriaan
Adriaan van Os wrote:
{$define Close(f, x) Close (f)}
The program wouldn't behave as expected, because the second parameter isn't meaningless, e.g. x=CRUNCH sets the end-of-file to the point of last access. So, I guess, it is better to change UCSD Pascal source code when porting to GPC (or to another Pascal).
Does it allow seeking while writing? Or "crunching" a read-only file? Otherwise the point of last access would be the end of a (sequential) writing sequence.
But anyway, my suggestion wasn't meant too seriously.
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
{$define Close(f, x) Close (f)}
The program wouldn't behave as expected, because the second parameter isn't meaningless, e.g. x=CRUNCH sets the end-of-file to the point of last access. So, I guess, it is better to change UCSD Pascal source code when porting to GPC (or to another Pascal).
Does it allow seeking while writing? Or "crunching" a read-only file? Otherwise the point of last access would be the end of a (sequential) writing sequence.
Apple II UCSD Pascal has a SEEK procedure and it allows random-access IO, except on TEXT files. The concept of read-only files however, doesn't exist. CBFalconer already noted that the UCSD-Pascal Operating System has a rather simple file-system, designed for use with 5.25-inch diskettes on single-user computers, way back in 1978. Also, it doesn't have a set-end-of-file procedure.
But anyway, my suggestion wasn't meant too seriously.
Still, the problem at hand is an interesting one. How do you replace an existing file on disk with a new one (assuming sequential IO) ? Some possibilities:
1. delete the old one, then write a new one with the same name 2. write a new file (using some unique name), remove the old one, rename the new one 3. open the file for writing, write to it, close it with a "crunch" option 4. open the file for writing, write to it, set the end-of-file to the point-of-current-access, close it.
Regards,
Adriaan van Os
Adriaan van Os wrote:
But anyway, my suggestion wasn't meant too seriously.
Still, the problem at hand is an interesting one. How do you replace an existing file on disk with a new one (assuming sequential IO) ? Some possibilities:
- delete the old one, then write a new one with the same name
Not recommended. If it crashes underway, you might lose everything. (Assuming the new contents are derived from the old ones. Otherwise, you basically want to rewrite a file, and if you don't care aboutfile ownership/permissions, deleting and recreating is roughly equivalent.)
- write a new file (using some unique name), remove the old one,
rename the new one
That's what I usually do, especially for text files where in-place updating (except for appending) is not possible.
In fact, if you omit the removing, since moving with overwriting is an atomic operation (in GPC use `FileMove' with `True' as the 2nd argument, because `Rename' refuses to overwrite, BP compatible), it will guarantee that at any point in time the name refers to a valid (complete) file.
- open the file for writing, write to it, close it with a "crunch"
option 4. open the file for writing, write to it, set the end-of-file to the point-of-current-access, close it.
So crunching would be equivalent in GPC (and BP) to `Truncate' and `Close'.
Frank
Scott Moore wrote:
Scott Moore wrote:
UCSD has the form:
close(filename, option)
Where option is a "word":
normal lock purge crunch
Note that a filename (not handle or var file reference) is used, and that "word" as option pretty much requires close to be a compiler built-in statement.
Ugh. So they are not even predefined constants?
Also the filename seems problematic to me. What if several files are opened to the same file name? Then add the problems if directories were changed (as discussed recently in a similar situation). I don't think we want to emulate this ...
I was incorrect. The book calls it a "filename", but I was looking through some old UCSD source programs, and close(file, lock) clearly uses "file" as in "file of text", ie, the file, not its name.
That whole business had its roots in the ultra primitive UCSD file 'system', in which the file size was specified on opening (or seized the remainder of the disk) and the gyrations allowed releasing all, some, none, of the space allocated. USCD files were always some contiguous section of the disc, there was no such idea as allocation units.
Scott Moore wrote:
UCSD has the form:
close(filename, option)
Where option is a "word":
normal lock purge crunch
Note that a filename (not handle or var file reference) is used, and that "word" as option pretty much requires close to be a compiler built-in statement.
From "The UCSD Pascal Handbook", Clark & Koehler.
You will find similar constructs in other compilers, since many compilers copied UCSD, including Apple.
In Apple II UCSD Pascal, the first parameter is not a filename but "the identifier of a perviously declared file". Also, the second parameter is optional. See page 28 of the Apple II UCSD Pascal Language Reference. Also, the description doesn't state that option parameter is a "word".
Regards,
Adriaan van Os
Hello Frank,
FH> Just FMI, which Pascal compiler is this? We've seen > various syntaxes in this area, but I can't remember > seeing this one.
The book doesn't appear to say. It's...
Chirlian, Paul M. Pascal Beaverton, OR, USA: Matrix, 1980 ISBN 0-916460-28-2
Here are some quoted sections both to provide flavour and perhaps some clues as to the platform that the author was using (I hope that the author would consider this "fair use")...
"This text discusses the running of programs both from a terminal and also via batch processing."
[skipping some stuff about punched cards and bubble memory]
"There is another form of input and output device called a /terminal/. The input is transmitted through a keyboard that resembles an ordinary typewriter keyboard. The programmer types in his program and the terminal generates electrical signals which supply the information to the computer Output from the computer is typed on the terminal by the computer. This typing can be actually printed on a paper or it can appear on a video screen."
I found this part interesting, and it may provide a clue as to the platform that the author was using...
"Note that we have always used a blank space as the first character printed on a line (after the first quote). On many, but not all, computers this first character is /not/ printed, but is used as a /carriage control character/. That is, it controls the spacing between lines. Typically, if the first character is a blank, then the printer will advance one line before printing."
A table follows, listing the actions caused by certain characters in that first position of a printed line...
Symbol Action ----------- --------------------------------- blank space advance one line before printing 0 (zero) advance two lines before printing 1 skip to top of next page before printing + do not advance (will overprint)
This is one of several places in the book where the author is careful to point out things that may be platform-specific (without mentioning his platform. ;-) Another is when he discusses file names. An example given is...
REWRITE(INFO,'#9:INT.DATA');
"INFO is the name of the file as far as the program is concerned. #9:INT.DATA is its destination. The form of the destination will vary from computer to computer... #9 refers to a particular floppy disk drive, INT.DATA is the name we have chosen to assign to the particular file on the floppy disk."
----- Original Message ----- From: "Andy Ball" andy.ball@earthlink.net To: gpc@gnu.de Sent: Sunday, April 18, 2004 9:59 AM Subject: Re: Closing a file
Hello Frank,
FH> Just FMI, which Pascal compiler is this? We've seen > various syntaxes in this area, but I can't remember > seeing this one.
The book doesn't appear to say. It's...
Chirlian, Paul M. Pascal Beaverton, OR, USA: Matrix, 1980 ISBN 0-916460-28-2
Here are some quoted sections both to provide flavour and perhaps some clues as to the platform that the author was using (I hope that the author would consider this "fair use")...
"This text discusses the running of programs both from a terminal and also via batch processing."
[skipping some stuff about punched cards and bubble memory]
"There is another form of input and output device called a /terminal/. The input is transmitted through a keyboard that resembles an ordinary typewriter keyboard. The programmer types in his program and the terminal generates electrical signals which supply the information to the computer Output from the computer is typed on the terminal by the computer. This typing can be actually printed on a paper or it can appear on a video screen."
I found this part interesting, and it may provide a clue as to the platform that the author was using...
"Note that we have always used a blank space as the first character printed on a line (after the first quote). On many, but not all, computers this first character is /not/ printed, but is used as a /carriage control character/. That is, it controls the spacing between lines. Typically, if the first character is a blank, then the printer will advance one line before printing."
A table follows, listing the actions caused by certain characters in that first position of a printed line...
Symbol Action ----------- --------------------------------- blank space advance one line before printing 0 (zero) advance two lines before printing 1 skip to top of next page before printing + do not advance (will overprint)
This is the original print line convention proposed by Wirth. It was discarded for the ISO standard.
This is one of several places in the book where the author is careful to point out things that may be platform-specific (without mentioning his platform. ;-) Another is when he discusses file names. An example given is...
REWRITE(INFO,'#9:INT.DATA');
"INFO is the name of the file as far as the program is concerned. #9:INT.DATA is its destination. The form of the destination will vary from computer to computer... #9 refers to a particular floppy disk drive, INT.DATA is the name we have chosen to assign to the particular file on the floppy disk."
Scott Moore a écrit:
----- Original Message ----- From: "Andy Ball" andy.ball@earthlink.net
A table follows, listing the actions caused by certain characters in that first position of a printed line...
Symbol Action
blank space advance one line before printing 0 (zero) advance two lines before printing 1 skip to top of next page before printing
do not advance (will overprint)
This is the original print line convention proposed by Wirth. It was discarded for the ISO standard.
It was in use for 132 lines printers, FORTRAN driven, in these times
Maurice