In CP/M, how does control-Z (hex 1a decimal 26) not interfere with ordinary file storage?
Consider this - I have made a file called test.bin on a Windows machine. It is exactly 256 bytes long, and contains nothing more than 00 to ff in each byte.
What would happen if I transferred this file to a CP/M system? (in fact this is exactly what I am trying to do).
Since the CP/M end of file marker is control-Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
I would have thought that hex 1A can appear all over the place in binary files such as executable COM files. How is it that CP/M uses this for an end of file marker without constantly truncating files early?
Is usage of control-Z at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is control-Z actually enforced by the operating system in any way, or is it simply a convention?
cp-m
edited Jan 17 at 6:42
Leo B.
6,27432368
asked Jan 11 at 0:29
Duke DougalDuke Dougal
2025
|
show 3 more comments
Consider this - I have made a file called test.bin on a Windows machine. It is exactly 256 bytes long, and contains nothing more than 00 to ff in each byte.
What would happen if I transferred this file to a CP/M system? (in fact this is exactly what I am trying to do).
Since the CP/M end of file marker is control-Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
I would have thought that hex 1A can appear all over the place in binary files such as executable COM files. How is it that CP/M uses this for an end of file marker without constantly truncating files early?
Is usage of control-Z at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is control-Z actually enforced by the operating system in any way, or is it simply a convention?
cp-m
edited Jan 17 at 6:42
Leo B.
6,27432368
asked Jan 11 at 0:29
Duke DougalDuke Dougal
2025
To highlight what @Raffzahn said, the ^Z part is part and parcel to TEXT files. Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data. <!----->
– Will Hartung
Jan 11 at 1:01
1
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
Jan 11 at 3:03
2
Windows and MS-DOS is stopping too ... its just a matter of type of file access you can open file as text or as binary ... the text files access type interprets certain control codes (or escape codes) as commands and many text and file related routines adherse them ... for example that is why if you print/list binary file as text you hear sometimes the beeps, sometimes its cut down premature etc ...
– Spektre
Jan 11 at 9:14
2
@RichF CP/M, with the exception of executables, did not "understand" filename extensions - i.e., nothing magic about .txt (or .dat or .dbf etc.). ^Z was treated special in any program that used a file as "text" rather than "binary". But the file extension had nothing to do with it, except to assist lowly humans in identifying files.
– manassehkatz
Jan 11 at 15:12
1
@manassehkatz Thank you for the correction of my misconception.
– RichF
Jan 11 at 17:09
|
show 3 more comments
Consider this - I have made a file called test.bin on a Windows machine. It is exactly 256 bytes long, and contains nothing more than 00 to ff in each byte.
What would happen if I transferred this file to a CP/M system? (in fact this is exactly what I am trying to do).
Since the CP/M end of file marker is control-Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
I would have thought that hex 1A can appear all over the place in binary files such as executable COM files. How is it that CP/M uses this for an end of file marker without constantly truncating files early?
Is usage of control-Z at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is control-Z actually enforced by the operating system in any way, or is it simply a convention?
cp-m
edited Jan 17 at 6:42
Leo B.
6,27432368
asked Jan 11 at 0:29
Duke DougalDuke Dougal
2025
Consider this - I have made a file called test.bin on a Windows machine. It is exactly 256 bytes long, and contains nothing more than 00 to ff in each byte.
What would happen if I transferred this file to a CP/M system? (in fact this is exactly what I am trying to do).
Since the CP/M end of file marker is control-Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
I would have thought that hex 1A can appear all over the place in binary files such as executable COM files. How is it that CP/M uses this for an end of file marker without constantly truncating files early?
Is usage of control-Z at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is control-Z actually enforced by the operating system in any way, or is it simply a convention?
cp-m
cp-m
edited Jan 17 at 6:42
Leo B.
6,27432368
asked Jan 11 at 0:29
Duke DougalDuke Dougal
2025
edited Jan 17 at 6:42
Leo B.
6,27432368
asked Jan 11 at 0:29
Duke DougalDuke Dougal
2025
edited Jan 17 at 6:42
Leo B.
6,27432368
edited Jan 17 at 6:42
Leo B.
6,27432368
edited Jan 17 at 6:42
Leo B.
6,27432368
6,27432368
asked Jan 11 at 0:29
Duke DougalDuke Dougal
2025
asked Jan 11 at 0:29
Duke DougalDuke Dougal
2025
asked Jan 11 at 0:29
Duke DougalDuke Dougal
2025
2025
To highlight what @Raffzahn said, the ^Z part is part and parcel to TEXT files. Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data. <!----->
– Will Hartung
Jan 11 at 1:01
1
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
Jan 11 at 3:03
2
Windows and MS-DOS is stopping too ... its just a matter of type of file access you can open file as text or as binary ... the text files access type interprets certain control codes (or escape codes) as commands and many text and file related routines adherse them ... for example that is why if you print/list binary file as text you hear sometimes the beeps, sometimes its cut down premature etc ...
– Spektre
Jan 11 at 9:14
2
@RichF CP/M, with the exception of executables, did not "understand" filename extensions - i.e., nothing magic about .txt (or .dat or .dbf etc.). ^Z was treated special in any program that used a file as "text" rather than "binary". But the file extension had nothing to do with it, except to assist lowly humans in identifying files.
– manassehkatz
Jan 11 at 15:12
1
@manassehkatz Thank you for the correction of my misconception.
– RichF
Jan 11 at 17:09
|
show 3 more comments
To highlight what @Raffzahn said, the ^Z part is part and parcel to TEXT files. Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data. <!----->
– Will Hartung
Jan 11 at 1:01
1
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
Jan 11 at 3:03
2
Windows and MS-DOS is stopping too ... its just a matter of type of file access you can open file as text or as binary ... the text files access type interprets certain control codes (or escape codes) as commands and many text and file related routines adherse them ... for example that is why if you print/list binary file as text you hear sometimes the beeps, sometimes its cut down premature etc ...
– Spektre
Jan 11 at 9:14
2
@RichF CP/M, with the exception of executables, did not "understand" filename extensions - i.e., nothing magic about .txt (or .dat or .dbf etc.). ^Z was treated special in any program that used a file as "text" rather than "binary". But the file extension had nothing to do with it, except to assist lowly humans in identifying files.
– manassehkatz
Jan 11 at 15:12
1
@manassehkatz Thank you for the correction of my misconception.
– RichF
Jan 11 at 17:09
To highlight what @Raffzahn said, the ^Z part is part and parcel to TEXT files. Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data. <!----->
– Will Hartung
Jan 11 at 1:01
To highlight what @Raffzahn said, the ^Z part is part and parcel to TEXT files. Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data. <!----->
– Will Hartung
Jan 11 at 1:01
1
1
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
Jan 11 at 3:03
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
Jan 11 at 3:03
2
2
Windows and MS-DOS is stopping too ... its just a matter of type of file access you can open file as text or as binary ... the text files access type interprets certain control codes (or escape codes) as commands and many text and file related routines adherse them ... for example that is why if you print/list binary file as text you hear sometimes the beeps, sometimes its cut down premature etc ...
– Spektre
Jan 11 at 9:14
Windows and MS-DOS is stopping too ... its just a matter of type of file access you can open file as text or as binary ... the text files access type interprets certain control codes (or escape codes) as commands and many text and file related routines adherse them ... for example that is why if you print/list binary file as text you hear sometimes the beeps, sometimes its cut down premature etc ...
– Spektre
Jan 11 at 9:14
2
2
@RichF CP/M, with the exception of executables, did not "understand" filename extensions - i.e., nothing magic about .txt (or .dat or .dbf etc.). ^Z was treated special in any program that used a file as "text" rather than "binary". But the file extension had nothing to do with it, except to assist lowly humans in identifying files.
– manassehkatz
Jan 11 at 15:12
@RichF CP/M, with the exception of executables, did not "understand" filename extensions - i.e., nothing magic about .txt (or .dat or .dbf etc.). ^Z was treated special in any program that used a file as "text" rather than "binary". But the file extension had nothing to do with it, except to assist lowly humans in identifying files.
– manassehkatz
Jan 11 at 15:12
1
1
@manassehkatz Thank you for the correction of my misconception.
– RichF
Jan 11 at 17:09
@manassehkatz Thank you for the correction of my misconception.
– RichF
Jan 11 at 17:09
|
show 3 more comments
1 Answer
1
active
oldest
votes
What would happen if I transferred this file to a CP/M system?
Depends on your transfer utility and how it handles the data presented.
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
No, at least not the OS itself. CP/M does not handle CTRL-Z (or any content) specially. Your file transfer utility may do so.
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
No, it doesn't enforce anything. So it is a convention among text-based utilities.
How do I know when I have got to the end of the end of an executable file?
(from a comment)
You don't. At least not at byte level. Loading an executable is always done up to the next 128 byte record.
The long read
CP/M, up to and including 2.2 did not maintain a bytewise file length in its metadata (directory extent). Length was only noted as the number of 128 byte records of the last extent. At DOS level read and write operation were always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it only worked with 128 byte granularity.
To allow termination of a file holding ASCII data, CTRL-Z was used as an end marker within the last record. All text oriented utilities followed that scheme. But there is no hard provision.
CP/M 3.0 utilized a previously unused directory extent byte to note the bytes used within the last record. For compatibility a value of 128 is noted as zero.
*1 - Random access could operate at byte level, but the 128-byte record granularity was still to be observed.
edited Jan 11 at 10:23
Community♦
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
49.2k6111197
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
Jan 11 at 0:46
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
Jan 11 at 1:22
The same misconception is also false about MS/PC/DR-DOS. jdebp.uk./FGA/dos-character-26-is-not-special.html
– JdeBP
Jan 11 at 19:21
@JdeBP For MS-DOS it's more of a compatibility addition toward CP/M to make CTRL-Z work alike on the command line. After all, File length was now maintained on byte level.
– Raffzahn
Jan 11 at 19:35
PIP knows about Ctrl-Z being EOF (See option O) and MSDOS has binary options on the copy command (for copy a.txt+b.txt c.txt)
– PeterI
Jan 12 at 1:14
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8719%2fin-cp-m-how-does-control-z-hex-1a-decimal-26-not-interfere-with-ordinary-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
What would happen if I transferred this file to a CP/M system?
Depends on your transfer utility and how it handles the data presented.
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
No, at least not the OS itself. CP/M does not handle CTRL-Z (or any content) specially. Your file transfer utility may do so.
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
No, it doesn't enforce anything. So it is a convention among text-based utilities.
How do I know when I have got to the end of the end of an executable file?
(from a comment)
You don't. At least not at byte level. Loading an executable is always done up to the next 128 byte record.
The long read
CP/M, up to and including 2.2 did not maintain a bytewise file length in its metadata (directory extent). Length was only noted as the number of 128 byte records of the last extent. At DOS level read and write operation were always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it only worked with 128 byte granularity.
To allow termination of a file holding ASCII data, CTRL-Z was used as an end marker within the last record. All text oriented utilities followed that scheme. But there is no hard provision.
CP/M 3.0 utilized a previously unused directory extent byte to note the bytes used within the last record. For compatibility a value of 128 is noted as zero.
*1 - Random access could operate at byte level, but the 128-byte record granularity was still to be observed.
edited Jan 11 at 10:23
Community♦
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
49.2k6111197
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
Jan 11 at 0:46
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
Jan 11 at 1:22
The same misconception is also false about MS/PC/DR-DOS. jdebp.uk./FGA/dos-character-26-is-not-special.html
– JdeBP
Jan 11 at 19:21
@JdeBP For MS-DOS it's more of a compatibility addition toward CP/M to make CTRL-Z work alike on the command line. After all, File length was now maintained on byte level.
– Raffzahn
Jan 11 at 19:35
PIP knows about Ctrl-Z being EOF (See option O) and MSDOS has binary options on the copy command (for copy a.txt+b.txt c.txt)
– PeterI
Jan 12 at 1:14
add a comment |
What would happen if I transferred this file to a CP/M system?
Depends on your transfer utility and how it handles the data presented.
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
No, at least not the OS itself. CP/M does not handle CTRL-Z (or any content) specially. Your file transfer utility may do so.
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
No, it doesn't enforce anything. So it is a convention among text-based utilities.
How do I know when I have got to the end of the end of an executable file?
(from a comment)
You don't. At least not at byte level. Loading an executable is always done up to the next 128 byte record.
The long read
CP/M, up to and including 2.2 did not maintain a bytewise file length in its metadata (directory extent). Length was only noted as the number of 128 byte records of the last extent. At DOS level read and write operation were always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it only worked with 128 byte granularity.
To allow termination of a file holding ASCII data, CTRL-Z was used as an end marker within the last record. All text oriented utilities followed that scheme. But there is no hard provision.
CP/M 3.0 utilized a previously unused directory extent byte to note the bytes used within the last record. For compatibility a value of 128 is noted as zero.
*1 - Random access could operate at byte level, but the 128-byte record granularity was still to be observed.
edited Jan 11 at 10:23
Community♦
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
49.2k6111197
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
Jan 11 at 0:46
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
Jan 11 at 1:22
The same misconception is also false about MS/PC/DR-DOS. jdebp.uk./FGA/dos-character-26-is-not-special.html
– JdeBP
Jan 11 at 19:21
@JdeBP For MS-DOS it's more of a compatibility addition toward CP/M to make CTRL-Z work alike on the command line. After all, File length was now maintained on byte level.
– Raffzahn
Jan 11 at 19:35
PIP knows about Ctrl-Z being EOF (See option O) and MSDOS has binary options on the copy command (for copy a.txt+b.txt c.txt)
– PeterI
Jan 12 at 1:14
add a comment |
What would happen if I transferred this file to a CP/M system?
Depends on your transfer utility and how it handles the data presented.
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
No, at least not the OS itself. CP/M does not handle CTRL-Z (or any content) specially. Your file transfer utility may do so.
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
No, it doesn't enforce anything. So it is a convention among text-based utilities.
How do I know when I have got to the end of the end of an executable file?
(from a comment)
You don't. At least not at byte level. Loading an executable is always done up to the next 128 byte record.
The long read
CP/M, up to and including 2.2 did not maintain a bytewise file length in its metadata (directory extent). Length was only noted as the number of 128 byte records of the last extent. At DOS level read and write operation were always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it only worked with 128 byte granularity.
To allow termination of a file holding ASCII data, CTRL-Z was used as an end marker within the last record. All text oriented utilities followed that scheme. But there is no hard provision.
CP/M 3.0 utilized a previously unused directory extent byte to note the bytes used within the last record. For compatibility a value of 128 is noted as zero.
*1 - Random access could operate at byte level, but the 128-byte record granularity was still to be observed.
edited Jan 11 at 10:23
Community♦
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
49.2k6111197
What would happen if I transferred this file to a CP/M system?
Depends on your transfer utility and how it handles the data presented.
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
No, at least not the OS itself. CP/M does not handle CTRL-Z (or any content) specially. Your file transfer utility may do so.
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
No, it doesn't enforce anything. So it is a convention among text-based utilities.
How do I know when I have got to the end of the end of an executable file?
(from a comment)
You don't. At least not at byte level. Loading an executable is always done up to the next 128 byte record.
The long read
CP/M, up to and including 2.2 did not maintain a bytewise file length in its metadata (directory extent). Length was only noted as the number of 128 byte records of the last extent. At DOS level read and write operation were always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it only worked with 128 byte granularity.
To allow termination of a file holding ASCII data, CTRL-Z was used as an end marker within the last record. All text oriented utilities followed that scheme. But there is no hard provision.
CP/M 3.0 utilized a previously unused directory extent byte to note the bytes used within the last record. For compatibility a value of 128 is noted as zero.
*1 - Random access could operate at byte level, but the 128-byte record granularity was still to be observed.
edited Jan 11 at 10:23
Community♦
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
49.2k6111197
edited Jan 11 at 10:23
Community♦
1
edited Jan 11 at 10:23
Community♦
1
edited Jan 11 at 10:23
Community♦
1
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
49.2k6111197
answered Jan 11 at 0:37
RaffzahnRaffzahn
49.2k6111197
answered Jan 11 at 0:37
RaffzahnRaffzahn
49.2k6111197
49.2k6111197
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
Jan 11 at 0:46
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
Jan 11 at 1:22
The same misconception is also false about MS/PC/DR-DOS. jdebp.uk./FGA/dos-character-26-is-not-special.html
– JdeBP
Jan 11 at 19:21
@JdeBP For MS-DOS it's more of a compatibility addition toward CP/M to make CTRL-Z work alike on the command line. After all, File length was now maintained on byte level.
– Raffzahn
Jan 11 at 19:35
PIP knows about Ctrl-Z being EOF (See option O) and MSDOS has binary options on the copy command (for copy a.txt+b.txt c.txt)
– PeterI
Jan 12 at 1:14
add a comment |
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
Jan 11 at 0:46
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
Jan 11 at 1:22
The same misconception is also false about MS/PC/DR-DOS. jdebp.uk./FGA/dos-character-26-is-not-special.html
– JdeBP
Jan 11 at 19:21
@JdeBP For MS-DOS it's more of a compatibility addition toward CP/M to make CTRL-Z work alike on the command line. After all, File length was now maintained on byte level.
– Raffzahn
Jan 11 at 19:35
PIP knows about Ctrl-Z being EOF (See option O) and MSDOS has binary options on the copy command (for copy a.txt+b.txt c.txt)
– PeterI
Jan 12 at 1:14
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
Jan 11 at 0:46
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
Jan 11 at 0:46
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
Jan 11 at 1:22
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
Jan 11 at 1:22
The same misconception is also false about MS/PC/DR-DOS. jdebp.uk./FGA/dos-character-26-is-not-special.html
– JdeBP
Jan 11 at 19:21
The same misconception is also false about MS/PC/DR-DOS. jdebp.uk./FGA/dos-character-26-is-not-special.html
– JdeBP
Jan 11 at 19:21
@JdeBP For MS-DOS it's more of a compatibility addition toward CP/M to make CTRL-Z work alike on the command line. After all, File length was now maintained on byte level.
– Raffzahn
Jan 11 at 19:35
@JdeBP For MS-DOS it's more of a compatibility addition toward CP/M to make CTRL-Z work alike on the command line. After all, File length was now maintained on byte level.
– Raffzahn
Jan 11 at 19:35
PIP knows about Ctrl-Z being EOF (See option O) and MSDOS has binary options on the copy command (for copy a.txt+b.txt c.txt)
– PeterI
Jan 12 at 1:14
PIP knows about Ctrl-Z being EOF (See option O) and MSDOS has binary options on the copy command (for copy a.txt+b.txt c.txt)
– PeterI
Jan 12 at 1:14
add a comment |
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8719%2fin-cp-m-how-does-control-z-hex-1a-decimal-26-not-interfere-with-ordinary-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
To highlight what @Raffzahn said, the ^Z part is part and parcel to TEXT files. Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data. <!----->
– Will Hartung
Jan 11 at 1:01
1
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
Jan 11 at 3:03
2
Windows and MS-DOS is stopping too ... its just a matter of type of file access you can open file as text or as binary ... the text files access type interprets certain control codes (or escape codes) as commands and many text and file related routines adherse them ... for example that is why if you print/list binary file as text you hear sometimes the beeps, sometimes its cut down premature etc ...
– Spektre
Jan 11 at 9:14
2
@RichF CP/M, with the exception of executables, did not "understand" filename extensions - i.e., nothing magic about .txt (or .dat or .dbf etc.). ^Z was treated special in any program that used a file as "text" rather than "binary". But the file extension had nothing to do with it, except to assist lowly humans in identifying files.
– manassehkatz
Jan 11 at 15:12
1
@manassehkatz Thank you for the correction of my misconception.
– RichF
Jan 11 at 17:09