How does cat > file << “END” work?How do you use output redirection in combination with...
Independent, post-Brexit Scotland - would there be a hard border with England?
Upside-Down Pyramid Addition...REVERSED!
What was the design of the Macintosh II's MMU replacement?
I drew a randomly colored grid of points with tikz, how do I force it to remember the first grid from then on?
Understanding trademark infringements in a world where many dictionary words are trademarks?
Can hackers enable the camera after the user disabled it?
How can modem speed be 10 times slower than router?
Using column size much larger than necessary
Are there any Final Fantasy Spirits in Super Smash Bros Ultimate?
Why doesn't WotC use established keywords on all new cards?
Create a launchpad button that opens the content and makes the current context a specific folder
Should I replace my bicycle tires if they have not been inflated in multiple years
Why do only some White Walkers shatter into ice chips?
How did Shepard's and Grissom's speeds compare with orbital velocity?
What are the differences between credential stuffing and password spraying?
If I readied a spell with the trigger "When I take damage", do I have to make a constitution saving throw to avoid losing Concentration?
Why do people keep telling me that I am a bad photographer?
Does a card have a keyword if it has the same effect as said keyword?
Why did the Apollo 13 crew extend the LM landing gear?
Shantae Dance Matching
Why are prions in animal diets not destroyed by the digestive system?
Position of past participle and extent of the Verbklammer
Out of scope work duties and resignation
Why didn't the check-in agent recognize my long term visa?
How does cat > file
How do you use output redirection in combination with here-documents and cat?Why the inconsistency with using cat vs. echo piped to this sed command?How do you use output redirection in combination with here-documents and cat?How to echo variables using cat into file?How does `cat <> file` work?cat to stderr while reading to end of file markerredirecting output of a command as if it was file inputcat-redirect a file, but with variable expansionsHere-document with catcat on big files does not workWhy use cat to view a file?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
$ cat > file << "END"
> asdf
> qwerty
> END
$ cat file
asdf
qwerty
$
Not sure how does the above trick work.
cat > file
is somewhat understandable for me, it means that the output of cat
is being redirected and written to file
.
How does this << "END"
part work? I’d at least assume that it means that the string END
should be treated as input to cat
– thus, if anything, I’d assume that in the end file
should contain only one line with three letters: END
. How possible that this means “accept input from console and redirect it to cat
until the user types this string, which should be treated as a delimiter“ is beyond me.
shell io-redirection cat here-document
add a comment |
$ cat > file << "END"
> asdf
> qwerty
> END
$ cat file
asdf
qwerty
$
Not sure how does the above trick work.
cat > file
is somewhat understandable for me, it means that the output of cat
is being redirected and written to file
.
How does this << "END"
part work? I’d at least assume that it means that the string END
should be treated as input to cat
– thus, if anything, I’d assume that in the end file
should contain only one line with three letters: END
. How possible that this means “accept input from console and redirect it to cat
until the user types this string, which should be treated as a delimiter“ is beyond me.
shell io-redirection cat here-document
4
read on here-documents
– don_crissti
Feb 9 '17 at 20:18
2
How do you use output redirection in combination with here-documents and cat?
– don_crissti
Feb 9 '17 at 20:19
Do you want to know what it does or how it is implemented?
– icarus
Feb 9 '17 at 21:19
"I’d at least assume that it means that the string END should be treated as input to cat – thus, if anything, I’d assume that in the end file should contain only one line with three letters: END". Trycat > file <<< END
in bash.
– Weijun Zhou
21 mins ago
add a comment |
$ cat > file << "END"
> asdf
> qwerty
> END
$ cat file
asdf
qwerty
$
Not sure how does the above trick work.
cat > file
is somewhat understandable for me, it means that the output of cat
is being redirected and written to file
.
How does this << "END"
part work? I’d at least assume that it means that the string END
should be treated as input to cat
– thus, if anything, I’d assume that in the end file
should contain only one line with three letters: END
. How possible that this means “accept input from console and redirect it to cat
until the user types this string, which should be treated as a delimiter“ is beyond me.
shell io-redirection cat here-document
$ cat > file << "END"
> asdf
> qwerty
> END
$ cat file
asdf
qwerty
$
Not sure how does the above trick work.
cat > file
is somewhat understandable for me, it means that the output of cat
is being redirected and written to file
.
How does this << "END"
part work? I’d at least assume that it means that the string END
should be treated as input to cat
– thus, if anything, I’d assume that in the end file
should contain only one line with three letters: END
. How possible that this means “accept input from console and redirect it to cat
until the user types this string, which should be treated as a delimiter“ is beyond me.
shell io-redirection cat here-document
shell io-redirection cat here-document
edited Feb 19 '17 at 13:01
Jeff Schaller♦
45.4k1165148
45.4k1165148
asked Feb 9 '17 at 20:15
gaazkamgaazkam
4031615
4031615
4
read on here-documents
– don_crissti
Feb 9 '17 at 20:18
2
How do you use output redirection in combination with here-documents and cat?
– don_crissti
Feb 9 '17 at 20:19
Do you want to know what it does or how it is implemented?
– icarus
Feb 9 '17 at 21:19
"I’d at least assume that it means that the string END should be treated as input to cat – thus, if anything, I’d assume that in the end file should contain only one line with three letters: END". Trycat > file <<< END
in bash.
– Weijun Zhou
21 mins ago
add a comment |
4
read on here-documents
– don_crissti
Feb 9 '17 at 20:18
2
How do you use output redirection in combination with here-documents and cat?
– don_crissti
Feb 9 '17 at 20:19
Do you want to know what it does or how it is implemented?
– icarus
Feb 9 '17 at 21:19
"I’d at least assume that it means that the string END should be treated as input to cat – thus, if anything, I’d assume that in the end file should contain only one line with three letters: END". Trycat > file <<< END
in bash.
– Weijun Zhou
21 mins ago
4
4
read on here-documents
– don_crissti
Feb 9 '17 at 20:18
read on here-documents
– don_crissti
Feb 9 '17 at 20:18
2
2
How do you use output redirection in combination with here-documents and cat?
– don_crissti
Feb 9 '17 at 20:19
How do you use output redirection in combination with here-documents and cat?
– don_crissti
Feb 9 '17 at 20:19
Do you want to know what it does or how it is implemented?
– icarus
Feb 9 '17 at 21:19
Do you want to know what it does or how it is implemented?
– icarus
Feb 9 '17 at 21:19
"I’d at least assume that it means that the string END should be treated as input to cat – thus, if anything, I’d assume that in the end file should contain only one line with three letters: END". Try
cat > file <<< END
in bash.– Weijun Zhou
21 mins ago
"I’d at least assume that it means that the string END should be treated as input to cat – thus, if anything, I’d assume that in the end file should contain only one line with three letters: END". Try
cat > file <<< END
in bash.– Weijun Zhou
21 mins ago
add a comment |
1 Answer
1
active
oldest
votes
Your problem seems not to be how here-documents work, as you have correctly described their use in script files. It seems that you don’t understand their interactive use. The following is a (much simplified) crash course which will hopefully clarify the matter for you.
Shells, like all Unix processes in general, have input and output streams to read and write data, to and fro. They have at least one input stream (called stdin
) and two output streams (stdout
and stderr
), but they can open and close as many as they want, for reading and for writing (mostly, to read from files or write to them). What processes do with their streams depends on them. cat
, for instance, when called without arguments, copies its stdin
to stdout
. Shells usually interpret their input streams as commands to be executed (and set up input and output streams for those commands according to some syntax).
Where do input data come from? They can come from other processes sending them, they can be read from files, or they can be typed directly by the user, which is the most normal situation for a shell’s stdin
. In this case, there must be another program taking the user input and loading it into the stream. Such a program is called a tty
and in this case we say that the stream is attached to a tty
(the tty
is different from the terminal emulation program which provides a window for it, but you can also, broadly speaking, say that the stream is attached to a terminal.)
Shells know when their stdin
is attached to a tty
and behave differently, for instance printing a prompt when waiting for input, but there are really not many other differences. A prompt is usually something like user@host:current_path$
. Its exact contents can be defined by altering the variable PS1
. A usual convention is that it ends with $
when you are a normal user, and with #
when you are root
.
When you execute a script, the shell attaches an input stream to the file containing it, and reads commands from it. If one of the commands contains a here-document, that is, something like <<END
, this means: from now on, up to a line containing exactly only this terminator, stop interpreting the stream data as commands and pass them on to the stdin
of the command you are going to execute (cat
in your case), possibly with some mangling that will not bother us now. This is what you already know, albeit possibly in another perspective.
When input is attached to a tty
, a here-document means the same: stop interpreting the stream data as commands and pass them on to the stdin
of the command you are going to execute, up to the terminator. The only difference is, print a prompt when waiting for input; this prompt is different from the one the shell would print if it were going to interpret the input data as commands, just to let you know that they will be passed on. It is defined by the variable PS2
and its value defaults to >
. You see it at the beginning of every line after typing cat file > file << "END"
, until the terminator is read, when the shell resumes its normal behavior, prints its PS1
-prompt and waits for input to be interpreted as commands.
It is a good answer alright (+1). Although, since it is newbie-oriented, i'd add one or two sentences more about the prompt. The beginning of the third paragraph may be confusing to a newbie because he will not know that the>
character is actually a PS2 prompt.
– grochmal
Feb 10 '17 at 0:33
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
});
}
});
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%2f343825%2fhow-does-cat-file-end-work%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
Your problem seems not to be how here-documents work, as you have correctly described their use in script files. It seems that you don’t understand their interactive use. The following is a (much simplified) crash course which will hopefully clarify the matter for you.
Shells, like all Unix processes in general, have input and output streams to read and write data, to and fro. They have at least one input stream (called stdin
) and two output streams (stdout
and stderr
), but they can open and close as many as they want, for reading and for writing (mostly, to read from files or write to them). What processes do with their streams depends on them. cat
, for instance, when called without arguments, copies its stdin
to stdout
. Shells usually interpret their input streams as commands to be executed (and set up input and output streams for those commands according to some syntax).
Where do input data come from? They can come from other processes sending them, they can be read from files, or they can be typed directly by the user, which is the most normal situation for a shell’s stdin
. In this case, there must be another program taking the user input and loading it into the stream. Such a program is called a tty
and in this case we say that the stream is attached to a tty
(the tty
is different from the terminal emulation program which provides a window for it, but you can also, broadly speaking, say that the stream is attached to a terminal.)
Shells know when their stdin
is attached to a tty
and behave differently, for instance printing a prompt when waiting for input, but there are really not many other differences. A prompt is usually something like user@host:current_path$
. Its exact contents can be defined by altering the variable PS1
. A usual convention is that it ends with $
when you are a normal user, and with #
when you are root
.
When you execute a script, the shell attaches an input stream to the file containing it, and reads commands from it. If one of the commands contains a here-document, that is, something like <<END
, this means: from now on, up to a line containing exactly only this terminator, stop interpreting the stream data as commands and pass them on to the stdin
of the command you are going to execute (cat
in your case), possibly with some mangling that will not bother us now. This is what you already know, albeit possibly in another perspective.
When input is attached to a tty
, a here-document means the same: stop interpreting the stream data as commands and pass them on to the stdin
of the command you are going to execute, up to the terminator. The only difference is, print a prompt when waiting for input; this prompt is different from the one the shell would print if it were going to interpret the input data as commands, just to let you know that they will be passed on. It is defined by the variable PS2
and its value defaults to >
. You see it at the beginning of every line after typing cat file > file << "END"
, until the terminator is read, when the shell resumes its normal behavior, prints its PS1
-prompt and waits for input to be interpreted as commands.
It is a good answer alright (+1). Although, since it is newbie-oriented, i'd add one or two sentences more about the prompt. The beginning of the third paragraph may be confusing to a newbie because he will not know that the>
character is actually a PS2 prompt.
– grochmal
Feb 10 '17 at 0:33
add a comment |
Your problem seems not to be how here-documents work, as you have correctly described their use in script files. It seems that you don’t understand their interactive use. The following is a (much simplified) crash course which will hopefully clarify the matter for you.
Shells, like all Unix processes in general, have input and output streams to read and write data, to and fro. They have at least one input stream (called stdin
) and two output streams (stdout
and stderr
), but they can open and close as many as they want, for reading and for writing (mostly, to read from files or write to them). What processes do with their streams depends on them. cat
, for instance, when called without arguments, copies its stdin
to stdout
. Shells usually interpret their input streams as commands to be executed (and set up input and output streams for those commands according to some syntax).
Where do input data come from? They can come from other processes sending them, they can be read from files, or they can be typed directly by the user, which is the most normal situation for a shell’s stdin
. In this case, there must be another program taking the user input and loading it into the stream. Such a program is called a tty
and in this case we say that the stream is attached to a tty
(the tty
is different from the terminal emulation program which provides a window for it, but you can also, broadly speaking, say that the stream is attached to a terminal.)
Shells know when their stdin
is attached to a tty
and behave differently, for instance printing a prompt when waiting for input, but there are really not many other differences. A prompt is usually something like user@host:current_path$
. Its exact contents can be defined by altering the variable PS1
. A usual convention is that it ends with $
when you are a normal user, and with #
when you are root
.
When you execute a script, the shell attaches an input stream to the file containing it, and reads commands from it. If one of the commands contains a here-document, that is, something like <<END
, this means: from now on, up to a line containing exactly only this terminator, stop interpreting the stream data as commands and pass them on to the stdin
of the command you are going to execute (cat
in your case), possibly with some mangling that will not bother us now. This is what you already know, albeit possibly in another perspective.
When input is attached to a tty
, a here-document means the same: stop interpreting the stream data as commands and pass them on to the stdin
of the command you are going to execute, up to the terminator. The only difference is, print a prompt when waiting for input; this prompt is different from the one the shell would print if it were going to interpret the input data as commands, just to let you know that they will be passed on. It is defined by the variable PS2
and its value defaults to >
. You see it at the beginning of every line after typing cat file > file << "END"
, until the terminator is read, when the shell resumes its normal behavior, prints its PS1
-prompt and waits for input to be interpreted as commands.
It is a good answer alright (+1). Although, since it is newbie-oriented, i'd add one or two sentences more about the prompt. The beginning of the third paragraph may be confusing to a newbie because he will not know that the>
character is actually a PS2 prompt.
– grochmal
Feb 10 '17 at 0:33
add a comment |
Your problem seems not to be how here-documents work, as you have correctly described their use in script files. It seems that you don’t understand their interactive use. The following is a (much simplified) crash course which will hopefully clarify the matter for you.
Shells, like all Unix processes in general, have input and output streams to read and write data, to and fro. They have at least one input stream (called stdin
) and two output streams (stdout
and stderr
), but they can open and close as many as they want, for reading and for writing (mostly, to read from files or write to them). What processes do with their streams depends on them. cat
, for instance, when called without arguments, copies its stdin
to stdout
. Shells usually interpret their input streams as commands to be executed (and set up input and output streams for those commands according to some syntax).
Where do input data come from? They can come from other processes sending them, they can be read from files, or they can be typed directly by the user, which is the most normal situation for a shell’s stdin
. In this case, there must be another program taking the user input and loading it into the stream. Such a program is called a tty
and in this case we say that the stream is attached to a tty
(the tty
is different from the terminal emulation program which provides a window for it, but you can also, broadly speaking, say that the stream is attached to a terminal.)
Shells know when their stdin
is attached to a tty
and behave differently, for instance printing a prompt when waiting for input, but there are really not many other differences. A prompt is usually something like user@host:current_path$
. Its exact contents can be defined by altering the variable PS1
. A usual convention is that it ends with $
when you are a normal user, and with #
when you are root
.
When you execute a script, the shell attaches an input stream to the file containing it, and reads commands from it. If one of the commands contains a here-document, that is, something like <<END
, this means: from now on, up to a line containing exactly only this terminator, stop interpreting the stream data as commands and pass them on to the stdin
of the command you are going to execute (cat
in your case), possibly with some mangling that will not bother us now. This is what you already know, albeit possibly in another perspective.
When input is attached to a tty
, a here-document means the same: stop interpreting the stream data as commands and pass them on to the stdin
of the command you are going to execute, up to the terminator. The only difference is, print a prompt when waiting for input; this prompt is different from the one the shell would print if it were going to interpret the input data as commands, just to let you know that they will be passed on. It is defined by the variable PS2
and its value defaults to >
. You see it at the beginning of every line after typing cat file > file << "END"
, until the terminator is read, when the shell resumes its normal behavior, prints its PS1
-prompt and waits for input to be interpreted as commands.
Your problem seems not to be how here-documents work, as you have correctly described their use in script files. It seems that you don’t understand their interactive use. The following is a (much simplified) crash course which will hopefully clarify the matter for you.
Shells, like all Unix processes in general, have input and output streams to read and write data, to and fro. They have at least one input stream (called stdin
) and two output streams (stdout
and stderr
), but they can open and close as many as they want, for reading and for writing (mostly, to read from files or write to them). What processes do with their streams depends on them. cat
, for instance, when called without arguments, copies its stdin
to stdout
. Shells usually interpret their input streams as commands to be executed (and set up input and output streams for those commands according to some syntax).
Where do input data come from? They can come from other processes sending them, they can be read from files, or they can be typed directly by the user, which is the most normal situation for a shell’s stdin
. In this case, there must be another program taking the user input and loading it into the stream. Such a program is called a tty
and in this case we say that the stream is attached to a tty
(the tty
is different from the terminal emulation program which provides a window for it, but you can also, broadly speaking, say that the stream is attached to a terminal.)
Shells know when their stdin
is attached to a tty
and behave differently, for instance printing a prompt when waiting for input, but there are really not many other differences. A prompt is usually something like user@host:current_path$
. Its exact contents can be defined by altering the variable PS1
. A usual convention is that it ends with $
when you are a normal user, and with #
when you are root
.
When you execute a script, the shell attaches an input stream to the file containing it, and reads commands from it. If one of the commands contains a here-document, that is, something like <<END
, this means: from now on, up to a line containing exactly only this terminator, stop interpreting the stream data as commands and pass them on to the stdin
of the command you are going to execute (cat
in your case), possibly with some mangling that will not bother us now. This is what you already know, albeit possibly in another perspective.
When input is attached to a tty
, a here-document means the same: stop interpreting the stream data as commands and pass them on to the stdin
of the command you are going to execute, up to the terminator. The only difference is, print a prompt when waiting for input; this prompt is different from the one the shell would print if it were going to interpret the input data as commands, just to let you know that they will be passed on. It is defined by the variable PS2
and its value defaults to >
. You see it at the beginning of every line after typing cat file > file << "END"
, until the terminator is read, when the shell resumes its normal behavior, prints its PS1
-prompt and waits for input to be interpreted as commands.
edited 23 mins ago
Community♦
1
1
answered Feb 9 '17 at 22:03
DarioDario
31126
31126
It is a good answer alright (+1). Although, since it is newbie-oriented, i'd add one or two sentences more about the prompt. The beginning of the third paragraph may be confusing to a newbie because he will not know that the>
character is actually a PS2 prompt.
– grochmal
Feb 10 '17 at 0:33
add a comment |
It is a good answer alright (+1). Although, since it is newbie-oriented, i'd add one or two sentences more about the prompt. The beginning of the third paragraph may be confusing to a newbie because he will not know that the>
character is actually a PS2 prompt.
– grochmal
Feb 10 '17 at 0:33
It is a good answer alright (+1). Although, since it is newbie-oriented, i'd add one or two sentences more about the prompt. The beginning of the third paragraph may be confusing to a newbie because he will not know that the
>
character is actually a PS2 prompt.– grochmal
Feb 10 '17 at 0:33
It is a good answer alright (+1). Although, since it is newbie-oriented, i'd add one or two sentences more about the prompt. The beginning of the third paragraph may be confusing to a newbie because he will not know that the
>
character is actually a PS2 prompt.– grochmal
Feb 10 '17 at 0:33
add a comment |
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.
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%2f343825%2fhow-does-cat-file-end-work%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
4
read on here-documents
– don_crissti
Feb 9 '17 at 20:18
2
How do you use output redirection in combination with here-documents and cat?
– don_crissti
Feb 9 '17 at 20:19
Do you want to know what it does or how it is implemented?
– icarus
Feb 9 '17 at 21:19
"I’d at least assume that it means that the string END should be treated as input to cat – thus, if anything, I’d assume that in the end file should contain only one line with three letters: END". Try
cat > file <<< END
in bash.– Weijun Zhou
21 mins ago