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 controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
cp-m
asked Jan 11 at 0:29
Duke DougalDuke Dougal
1825
|
show 2 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 controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
cp-m
asked Jan 11 at 0:29
Duke DougalDuke Dougal
1825
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
2 days ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
2 days ago
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
2 days ago
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
2 days ago
1
@manassehkatz Thank you for the correction of my misconception.
– RichF
2 days ago
|
show 2 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 controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
cp-m
asked Jan 11 at 0:29
Duke DougalDuke Dougal
1825
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 controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
cp-m
cp-m
asked Jan 11 at 0:29
Duke DougalDuke Dougal
1825
asked Jan 11 at 0:29
Duke DougalDuke Dougal
1825
edited Jan 11 at 0:36
Duke Dougal
asked Jan 11 at 0:29
Duke DougalDuke Dougal
1825
asked Jan 11 at 0:29
Duke DougalDuke Dougal
1825
asked Jan 11 at 0:29
Duke DougalDuke Dougal
1825
1825
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
2 days ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
2 days ago
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
2 days ago
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
2 days ago
1
@manassehkatz Thank you for the correction of my misconception.
– RichF
2 days ago
|
show 2 more comments
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
2 days ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
2 days ago
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
2 days ago
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
2 days ago
1
@manassehkatz Thank you for the correction of my misconception.
– RichF
2 days ago
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
2 days ago
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
2 days ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
2 days ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
@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
2 days ago
1
1
@manassehkatz Thank you for the correction of my misconception.
– RichF
2 days ago
@manassehkatz Thank you for the correction of my misconception.
– RichF
2 days ago
|
show 2 more comments
2 Answers
2
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 2 days ago
Community♦
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
46.7k5104189
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
2 days ago
@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
2 days ago
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
2 days ago
add a comment |
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.
edited 2 days ago
Community♦
1
answered Jan 11 at 1:01
Will HartungWill Hartung
3,769821
2
This is a comment on Raffzahn's answer rather than an answer in its own right. And worse it is wrong. The meaning of ^Z is part of the interpretation of the file by application programs (including bundled utilities), it is not an aspect of filesystem or operating system itself, which makes no distinction of file type.
– Chris Stratton
2 days ago
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
2 Answers
2
active
oldest
votes
2 Answers
2
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 2 days ago
Community♦
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
46.7k5104189
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
2 days ago
@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
2 days ago
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
2 days ago
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 2 days ago
Community♦
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
46.7k5104189
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
2 days ago
@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
2 days ago
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
2 days ago
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 2 days ago
Community♦
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
46.7k5104189
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 2 days ago
Community♦
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
46.7k5104189
edited 2 days ago
Community♦
1
edited 2 days ago
Community♦
1
edited 2 days ago
Community♦
1
1
answered Jan 11 at 0:37
RaffzahnRaffzahn
46.7k5104189
answered Jan 11 at 0:37
RaffzahnRaffzahn
46.7k5104189
answered Jan 11 at 0:37
RaffzahnRaffzahn
46.7k5104189
46.7k5104189
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
2 days ago
@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
2 days ago
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
2 days ago
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
2 days ago
@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
2 days ago
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
2 days ago
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
2 days ago
The same misconception is also false about MS/PC/DR-DOS. jdebp.uk./FGA/dos-character-26-is-not-special.html
– JdeBP
2 days ago
@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
2 days ago
@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
2 days ago
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
2 days ago
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
2 days ago
add a comment |
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.
edited 2 days ago
Community♦
1
answered Jan 11 at 1:01
Will HartungWill Hartung
3,769821
2
This is a comment on Raffzahn's answer rather than an answer in its own right. And worse it is wrong. The meaning of ^Z is part of the interpretation of the file by application programs (including bundled utilities), it is not an aspect of filesystem or operating system itself, which makes no distinction of file type.
– Chris Stratton
2 days ago
add a comment |
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.
edited 2 days ago
Community♦
1
answered Jan 11 at 1:01
Will HartungWill Hartung
3,769821
2
This is a comment on Raffzahn's answer rather than an answer in its own right. And worse it is wrong. The meaning of ^Z is part of the interpretation of the file by application programs (including bundled utilities), it is not an aspect of filesystem or operating system itself, which makes no distinction of file type.
– Chris Stratton
2 days ago
add a comment |
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.
edited 2 days ago
Community♦
1
answered Jan 11 at 1:01
Will HartungWill Hartung
3,769821
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.
edited 2 days ago
Community♦
1
answered Jan 11 at 1:01
Will HartungWill Hartung
3,769821
edited 2 days ago
Community♦
1
edited 2 days ago
Community♦
1
edited 2 days ago
Community♦
1
1
answered Jan 11 at 1:01
Will HartungWill Hartung
3,769821
answered Jan 11 at 1:01
Will HartungWill Hartung
3,769821
answered Jan 11 at 1:01
Will HartungWill Hartung
3,769821
3,769821
2
This is a comment on Raffzahn's answer rather than an answer in its own right. And worse it is wrong. The meaning of ^Z is part of the interpretation of the file by application programs (including bundled utilities), it is not an aspect of filesystem or operating system itself, which makes no distinction of file type.
– Chris Stratton
2 days ago
add a comment |
2
This is a comment on Raffzahn's answer rather than an answer in its own right. And worse it is wrong. The meaning of ^Z is part of the interpretation of the file by application programs (including bundled utilities), it is not an aspect of filesystem or operating system itself, which makes no distinction of file type.
– Chris Stratton
2 days ago
2
2
This is a comment on Raffzahn's answer rather than an answer in its own right. And worse it is wrong. The meaning of ^Z is part of the interpretation of the file by application programs (including bundled utilities), it is not an aspect of filesystem or operating system itself, which makes no distinction of file type.
– Chris Stratton
2 days ago
This is a comment on Raffzahn's answer rather than an answer in its own right. And worse it is wrong. The meaning of ^Z is part of the interpretation of the file by application programs (including bundled utilities), it is not an aspect of filesystem or operating system itself, which makes no distinction of file type.
– Chris Stratton
2 days ago
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
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
2 days ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
2 days ago
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
2 days ago
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
2 days ago
1
@manassehkatz Thank you for the correction of my misconception.
– RichF
2 days ago