Talk:End-of-file

message: "ASCII control characters are out-of-band non-printing characters". Actually, ASCII control characters are in-band. -- 18:47, 13 November 2006 84.165.168.107
----
This article requires cleanup. Like so many people care how to get this symbol by typing into a DOS console or what C thinks EOF is... the bottom line that EOF is ASCII symbol #26 isn't even mentioned.--89.212.75.6 18:28, 24 November 2006 (UTC)
replies: text: People who care about the subject matter of the article would often be interested in the details.  And EOF is not ASCII character 26 (Ctrl-Z) -- rather, one (unofficial) interpretation of ASCII character 26 (Ctrl-Z) is as having the EOF function.  However, other entities can also symbolize "EOF" in other contexts, including 255 (i.e. -1), 4 (i.e. control-D), etc. AnonMoos 19:12, 24 November 2006 (UTC)
replies: text: I do not understand this comment. Ctrl-Z is actually a key combination rather than a character. And as far as I know end-of-file is character 26 (0x1a) in ASCII. So I added it to the article. Rbakels (talk) 04:33, 23 May 2012 (UTC)
replies: text: I think the terms you're looking for are signal and software interrupt. Using CTRL-D will invoke an interrupt to send SIGQUIT in a *nix system. The ASCII character is obtained by using a CTRL-V CTRL-D sequence. I'm not terribly sure that the character code is all that relevant. Xe7al (talk) 07:51, 26 November 2013 (UTC)
thread_title: November 2006

message: I came across the phrase end-of-stream (EOS) a couple of times while reading about streams, for example here. Is it correct that end-of-stream is synonymous to end-of-file and if yes, would mentioning EOS in this article be good? --Abdull 19:03, 8 May 2007 (UTC)
thread_title:  end-of-stream 

message: I'd suggest that Tape Marks as EOF indicators and file separators belongs in this article, but the details of the implementation
belong in the 7 track & 9 track articles (and QIC, DDS, Exabyte, ....).
RDBrown (talk) 22:42, 31 March 2008 (UTC)
replies: text: Perhaps. The beginning of the article discusses what is EOF in Unix etc. which are details of a particular implemetantion, in fact. There would not be much left. Do those articles have the info what the tape marks are? Maybe a separate article on tape mark? Jmath666 (talk) 22:52, 31 March 2008 (UTC)
thread_title:  Tape mark implementation 

message: Question: Somewhere in the dark cobwebs of my memory I seem to remember some word processing stuff that if not required, then strongly recommended putting a eof at the "end of the file".  Maybe a Unix app, a Wordstar early incantation, or maybe even old edlin.  It's not important, just wondered. Ched (talk) 01:51, 4 January 2009 (UTC)
replies: text: Under CP/M, all files whose exact effective length was not indicated by the binary structuring of the data itself had to use some marker (generally ASCII 26, Ctrl-Z) to indicate the end of data within the file, since file lengths were only recorded by the CP/M filesystem in terms of 128-byte blocks.  This persisted in various contexts in MS-DOS for reasons of backward compatibility (but not very often in Unix, as far as I've ever heard).  This is explained in the article itself. AnonMoos (talk) 09:32, 4 January 2009 (UTC)
thread_title:  word processors 

message: There is one piece of evidence which would clearly settle the matter -- that, is, if you were to find any explicit and positive indication that the record-size and file-size fields of the File Control Block were not present, or were not accessible to programmer manipulation, in DOS version 1.  (I strongly suspect that that's not the case, since the whole point of DOS 2.0 was to supersede the FCB calls, so there would be no reason to bulk up the FCB calls in DOS 2.0 or later.)  Until and unless you find evidence to that effect, the current situation strongly indicates that programmers could specify exact file sizes in DOS version 1 (but would have to go slightly beyond the default CP/M-compatible way of doing things to accomplish this).  I have no reason to doubt that your DOS 1 programming shop (which by your admission did things in a quick-and-dirty way) went along with the CP/M-compatible defaults (and so generated files with lengths which were invariably multiples of 128) -- and it might have been very difficult to do otherwise with the particular language compiler or programming tools used.  But that doesn't change the publicly-available facts about how there were other ways to do things even under DOS 1... AnonMoos (talk) 06:39, 7 December 2009 (UTC)
replies: text: Sorry, it is up to you to find a way to change these values, other than a quote that says "not recommended by Norton". It was not possible. I went through all the INT 21 calls and there is none. It is your job to find it.Spitzak (talk) 18:34, 7 December 2009 (UTC)
replies: text: Unfortunately for you, there is no such "call", and never has been any such "call", as I previously already explained at length in great detail above.  The onus and burden is really on you to provide detailed specific valid documented evidence that that the record-size and file-size fields of the File Control Block were not present, or were not accessible to programmer manipulation, in DOS version 1.  Absent such documentation, your contention that programmers in DOS 1 had no way to specify file sizes which were not multiples of 128 by9tes is simply unsupported by the availble facts, whether you like it or not. AnonMoos (talk) 22:56, 7 December 2009 (UTC)

text: I have no idea why the code I have seems to indicate that setting this field before Close does not work. However I now suspect the problem was not MSDOS 1., but other software that did not read the file-length field. They would instead always read 128 byte blocks and if the last block was short MSDOS put garbage (or unchanged data) in the end and the program would think it was on the end of the file. Therefore our software had to always pad out to the next 128 byte boundary with ^Z to get the files to be correctly read by other software. This is not MSDOS's 1 fault. The Unix-style calls returned the length and I think made us assume other programmers would read the files correctly.Spitzak (talk) 03:12, 23 December 2009 (UTC)
thread_title: How to settle the matter

message: I consulted the article in vain to find whether Unicode files may contain and end-of-file character as well. Google tells me that the answer probably is "no" - but it seems that is just as redundant as it is for plain ASCII files and they do (occasionally) have an EOF, so programs should better be prepared to handle them. Rbakels (talk) 04:37, 23 May 2012 (UTC)
replies: text: Yes it is perfectly legal for a Unicode file to contain the Unicode code point 26.Spitzak (talk) 02:33, 26 May 2012 (UTC)
thread_title:  Unicode 

message: How did CP/M distinguish a valid data byte whose value was 26 from the one denoted the end-of-file mark?
108.1.140.108 (talk) 00:42, 9 July 2014 (UTC)
replies: text: Most programs did not. They would stop reading the file at the first ^Z. It would be possible to detect that the ^Z is not in the last block of the file and assume it is not the eof. I think also some programs tried to make sure that all the trailing bytes in the last block were ^Z, which would allow a ^Z that was not at the end of the file to be detected. However most programs did not obey this.Spitzak (talk) 04:50, 9 July 2014 (UTC)

text: 108.1.140.108 -- for non-operating-system files, CP/M just did whatever the currently-running program told it to do.  For programs that used structured binary data files, the end of data was at the end of the last internally-defined field, and Ctrl-Z didn't matter.  It was text and quasi-text (WordStar) files that needed the Ctrl-Z convention... AnonMoos (talk) 04:57, 9 July 2014 (UTC)
thread_title:  Ctrl-Z in CP/M