How does cat > file << “END” work?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












$ 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














up vote
1
down vote

favorite












$ 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












up vote
1
down vote

favorite









up vote
1
down vote

favorite











$ 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

34.1k951113




34.1k951113










asked Feb 9 '17 at 20:15









gaazkam

3471513




3471513







  • 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












  • 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







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










2 Answers
2






active

oldest

votes

















up vote
4
down vote



accepted










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 readind 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 ouput 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 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. Only difference, 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.



Hope this helps.






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

















up vote
-3
down vote













THIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BAD






share|improve this answer








New contributor




Borja Guerrero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

















    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',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    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






























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    4
    down vote



    accepted










    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 readind 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 ouput 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 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. Only difference, 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.



    Hope this helps.






    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














    up vote
    4
    down vote



    accepted










    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 readind 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 ouput 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 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. Only difference, 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.



    Hope this helps.






    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












    up vote
    4
    down vote



    accepted







    up vote
    4
    down vote



    accepted






    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 readind 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 ouput 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 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. Only difference, 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.



    Hope this helps.






    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 readind 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 ouput 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 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. Only difference, 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.



    Hope this helps.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Feb 10 '17 at 8:07

























    answered Feb 9 '17 at 22:03









    Dario

    30115




    30115











    • 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












    up vote
    -3
    down vote













    THIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BAD






    share|improve this answer








    New contributor




    Borja Guerrero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





















      up vote
      -3
      down vote













      THIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BAD






      share|improve this answer








      New contributor




      Borja Guerrero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.



















        up vote
        -3
        down vote










        up vote
        -3
        down vote









        THIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BAD






        share|improve this answer








        New contributor




        Borja Guerrero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        THIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BADTHIS IS SO BAD







        share|improve this answer








        New contributor




        Borja Guerrero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        share|improve this answer



        share|improve this answer






        New contributor




        Borja Guerrero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        answered 14 mins ago









        Borja Guerrero

        1




        1




        New contributor




        Borja Guerrero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.





        New contributor





        Borja Guerrero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






        Borja Guerrero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.



























             

            draft saved


            draft discarded















































             


            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













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay