Echo to file descriptor overwrites the file?
1
I am having trouble understanding what is happening when I try to write to a file descriptor? It appears to be overwriting the original contents? Is this expected behaviour?
I have replicated this in the example below:
$ echo "The quick brown fox ..." > example.txt
$ echo "The quick brown fox ..." >> example.txt
$ cat example.txt
The quick brown fox ...
The quick brown fox ...
$ exec 88<>example.txt
$ cat example.txt
The quick brown fox ...
The quick brown fox ...
$ echo "jumped" >&88
$ cat example.txt
jumped
ck brown fox ...
The quick brown fox ...
$ echo "jumped" >&88
$ cat example.txt
jumped
jumped
n fox ...
The quick brown fox ...
bash files exec
edited 1 hour ago
Community♦
1
asked 3 hours ago
ZoonoseZoonose
83
New contributor
Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
1
I am having trouble understanding what is happening when I try to write to a file descriptor? It appears to be overwriting the original contents? Is this expected behaviour?
I have replicated this in the example below:
$ echo "The quick brown fox ..." > example.txt
$ echo "The quick brown fox ..." >> example.txt
$ cat example.txt
The quick brown fox ...
The quick brown fox ...
$ exec 88<>example.txt
$ cat example.txt
The quick brown fox ...
The quick brown fox ...
$ echo "jumped" >&88
$ cat example.txt
jumped
ck brown fox ...
The quick brown fox ...
$ echo "jumped" >&88
$ cat example.txt
jumped
jumped
n fox ...
The quick brown fox ...
bash files exec
edited 1 hour ago
Community♦
1
asked 3 hours ago
ZoonoseZoonose
83
New contributor
Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
1
1
1
3
I am having trouble understanding what is happening when I try to write to a file descriptor? It appears to be overwriting the original contents? Is this expected behaviour?
I have replicated this in the example below:
$ echo "The quick brown fox ..." > example.txt
$ echo "The quick brown fox ..." >> example.txt
$ cat example.txt
The quick brown fox ...
The quick brown fox ...
$ exec 88<>example.txt
$ cat example.txt
The quick brown fox ...
The quick brown fox ...
$ echo "jumped" >&88
$ cat example.txt
jumped
ck brown fox ...
The quick brown fox ...
$ echo "jumped" >&88
$ cat example.txt
jumped
jumped
n fox ...
The quick brown fox ...
bash files exec
edited 1 hour ago
Community♦
1
asked 3 hours ago
ZoonoseZoonose
83
New contributor
Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I am having trouble understanding what is happening when I try to write to a file descriptor? It appears to be overwriting the original contents? Is this expected behaviour?
I have replicated this in the example below:
$ echo "The quick brown fox ..." > example.txt
$ echo "The quick brown fox ..." >> example.txt
$ cat example.txt
The quick brown fox ...
The quick brown fox ...
$ exec 88<>example.txt
$ cat example.txt
The quick brown fox ...
The quick brown fox ...
$ echo "jumped" >&88
$ cat example.txt
jumped
ck brown fox ...
The quick brown fox ...
$ echo "jumped" >&88
$ cat example.txt
jumped
jumped
n fox ...
The quick brown fox ...
bash files exec
bash files exec
edited 1 hour ago
Community♦
1
asked 3 hours ago
ZoonoseZoonose
83
New contributor
Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 1 hour ago
Community♦
1
asked 3 hours ago
ZoonoseZoonose
83
New contributor
Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 1 hour ago
Community♦
1
edited 1 hour ago
Community♦
1
edited 1 hour ago
Community♦
1
1
asked 3 hours ago
ZoonoseZoonose
83
New contributor
Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 3 hours ago
ZoonoseZoonose
83
asked 3 hours ago
ZoonoseZoonose
83
83
New contributor
Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
3
Because you hadn't done any reads on descriptor 88, the current seek position was "0", and so the write took place at that point.
If, instead, you'd read the file before then, then appends happen:
bash-4.2$ cat <&88
The quick brown fox ...
The quick brown fox ...
bash-4.2$ echo hello >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
bash-4.2$ echo more >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
more
answered 2 hours ago
Stephen HarrisStephen Harris
26.1k24577
Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt
– Zoonose
1 hour ago
Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!
– Zoonose
1 hour ago
@Zoonose: When you executecat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you executeexec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.
– P Daddy
20 mins ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Zoonose is a new contributor. Be nice, and check out our Code of Conduct.
draft saved
draft discarded
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%2funix.stackexchange.com%2fquestions%2f501266%2fecho-to-file-descriptor-overwrites-the-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
3
Because you hadn't done any reads on descriptor 88, the current seek position was "0", and so the write took place at that point.
If, instead, you'd read the file before then, then appends happen:
bash-4.2$ cat <&88
The quick brown fox ...
The quick brown fox ...
bash-4.2$ echo hello >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
bash-4.2$ echo more >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
more
answered 2 hours ago
Stephen HarrisStephen Harris
26.1k24577
Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt
– Zoonose
1 hour ago
Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!
– Zoonose
1 hour ago
@Zoonose: When you executecat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you executeexec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.
– P Daddy
20 mins ago
add a comment |
3
Because you hadn't done any reads on descriptor 88, the current seek position was "0", and so the write took place at that point.
If, instead, you'd read the file before then, then appends happen:
bash-4.2$ cat <&88
The quick brown fox ...
The quick brown fox ...
bash-4.2$ echo hello >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
bash-4.2$ echo more >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
more
answered 2 hours ago
Stephen HarrisStephen Harris
26.1k24577
Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt
– Zoonose
1 hour ago
Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!
– Zoonose
1 hour ago
@Zoonose: When you executecat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you executeexec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.
– P Daddy
20 mins ago
add a comment |
3
3
3
Because you hadn't done any reads on descriptor 88, the current seek position was "0", and so the write took place at that point.
If, instead, you'd read the file before then, then appends happen:
bash-4.2$ cat <&88
The quick brown fox ...
The quick brown fox ...
bash-4.2$ echo hello >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
bash-4.2$ echo more >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
more
answered 2 hours ago
Stephen HarrisStephen Harris
26.1k24577
Because you hadn't done any reads on descriptor 88, the current seek position was "0", and so the write took place at that point.
If, instead, you'd read the file before then, then appends happen:
bash-4.2$ cat <&88
The quick brown fox ...
The quick brown fox ...
bash-4.2$ echo hello >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
bash-4.2$ echo more >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
more
answered 2 hours ago
Stephen HarrisStephen Harris
26.1k24577
answered 2 hours ago
Stephen HarrisStephen Harris
26.1k24577
answered 2 hours ago
Stephen HarrisStephen Harris
26.1k24577
answered 2 hours ago
Stephen HarrisStephen Harris
26.1k24577
26.1k24577
Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt
– Zoonose
1 hour ago
Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!
– Zoonose
1 hour ago
@Zoonose: When you executecat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you executeexec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.
– P Daddy
20 mins ago
add a comment |
Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt
– Zoonose
1 hour ago
Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!
– Zoonose
1 hour ago
@Zoonose: When you executecat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you executeexec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.
– P Daddy
20 mins ago
Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt
– Zoonose
1 hour ago
Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt
– Zoonose
1 hour ago
Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!
– Zoonose
1 hour ago
Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!
– Zoonose
1 hour ago
@Zoonose: When you execute
cat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you execute exec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.– P Daddy
20 mins ago
@Zoonose: When you execute
cat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you execute exec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.– P Daddy
20 mins ago
add a comment |
Zoonose is a new contributor. Be nice, and check out our Code of Conduct.
draft saved
draft discarded
Zoonose is a new contributor. Be nice, and check out our Code of Conduct.
Zoonose is a new contributor. Be nice, and check out our Code of Conduct.
Zoonose is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Unix & Linux 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.
draft saved
draft discarded
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%2funix.stackexchange.com%2fquestions%2f501266%2fecho-to-file-descriptor-overwrites-the-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
