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;
}







1















$ 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.










share|improve this question




















  • 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


















1















$ 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.










share|improve this question




















  • 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














1












1








1


2






$ 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.










share|improve this question
















$ 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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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". Try cat > file <<< END in bash.

    – Weijun Zhou
    21 mins ago














  • 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








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










1 Answer
1






active

oldest

votes


















5














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.






share|improve this answer


























  • 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












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
});


}
});














draft saved

draft discarded


















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









5














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.






share|improve this answer


























  • 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
















5














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.






share|improve this answer


























  • 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














5












5








5







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








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



















  • 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


















draft saved

draft discarded




















































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














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





















































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







Popular posts from this blog

Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

Nicolae Petrescu-Găină Cuprins Biografie | Opera | In memoriam | Varia | Controverse, incertitudini...