Why does Ctrl-D (EOF) exit the shell?

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












58















Are you literally "ending a file" by inputting this escape sequence, i.e. is the interactive shell session is seen as a real file stream by the shell, like any other file stream? If so, which file?



Or, is the Ctrl+D signal just a placeholder which means "the user has finished providing input and you may terminate"?










share|improve this question
























  • stackoverflow.com/questions/1516122/…

    – Yogi
    Jan 21 '14 at 10:56






  • 6





    FYI, in bash you can do set -o ignoreeof to change that behavior.

    – Keith
    Jan 21 '14 at 11:15















58















Are you literally "ending a file" by inputting this escape sequence, i.e. is the interactive shell session is seen as a real file stream by the shell, like any other file stream? If so, which file?



Or, is the Ctrl+D signal just a placeholder which means "the user has finished providing input and you may terminate"?










share|improve this question
























  • stackoverflow.com/questions/1516122/…

    – Yogi
    Jan 21 '14 at 10:56






  • 6





    FYI, in bash you can do set -o ignoreeof to change that behavior.

    – Keith
    Jan 21 '14 at 11:15













58












58








58


28






Are you literally "ending a file" by inputting this escape sequence, i.e. is the interactive shell session is seen as a real file stream by the shell, like any other file stream? If so, which file?



Or, is the Ctrl+D signal just a placeholder which means "the user has finished providing input and you may terminate"?










share|improve this question
















Are you literally "ending a file" by inputting this escape sequence, i.e. is the interactive shell session is seen as a real file stream by the shell, like any other file stream? If so, which file?



Or, is the Ctrl+D signal just a placeholder which means "the user has finished providing input and you may terminate"?







shell escape-characters






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 22 '14 at 7:51









Timo

4,7701826




4,7701826










asked Jan 21 '14 at 10:45









GeebGeeb

7931816




7931816












  • stackoverflow.com/questions/1516122/…

    – Yogi
    Jan 21 '14 at 10:56






  • 6





    FYI, in bash you can do set -o ignoreeof to change that behavior.

    – Keith
    Jan 21 '14 at 11:15

















  • stackoverflow.com/questions/1516122/…

    – Yogi
    Jan 21 '14 at 10:56






  • 6





    FYI, in bash you can do set -o ignoreeof to change that behavior.

    – Keith
    Jan 21 '14 at 11:15
















stackoverflow.com/questions/1516122/…

– Yogi
Jan 21 '14 at 10:56





stackoverflow.com/questions/1516122/…

– Yogi
Jan 21 '14 at 10:56




6




6





FYI, in bash you can do set -o ignoreeof to change that behavior.

– Keith
Jan 21 '14 at 11:15





FYI, in bash you can do set -o ignoreeof to change that behavior.

– Keith
Jan 21 '14 at 11:15










2 Answers
2






active

oldest

votes


















69














The ^D character (also known as 4 or 0x4, END OF TRANSMISSION in Unicode) is the default value for the eof special control character parameter of the terminal or pseudo-terminal driver in the kernel (more precisely of the tty line discipline attached to the serial or pseudo-tty device). That's the c_cc[VEOF] of the termios structure passed to the TCSETS/TCGETS ioctl one issues to the terminal device to affect the driver behaviour.



The typical command that sends those ioctls is the stty command.



To retrieve all the parameters:




$ stty -a
speed 38400 baud; rows 58; columns 191; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke


That eof parameter is only relevant when the terminal device is in icanon mode.



In that mode, the terminal driver (not the terminal emulator) implements a very simple line editor, where you can type Backspace to erase a character, Ctrl-U to erase the whole line... When an application reads from the terminal device, it sees nothing until you press Return at which point the read() returns the full line including the last LF character (by default, the terminal driver also translates the CR sent by your terminal upon Return to LF).



Now, if you want to send what you typed so far without pressing Enter, that's where you can enter the eof character. Upon receiving that character from the terminal emulator, the terminal driver submits the current content of the line, so that the application doing the read on it will receive it as is (and it won't include a trailing LF character).



Now, if the current line was empty, and provided the application will have fully read the previously entered lines, the read will return 0 character.



That signifies end of file to the application (when you read from a file, you read until there's nothing more to be read). That's why it's called the eof character, because sending it causes the application to see that no more input is available.



Now, modern shells, at their prompt do not set the terminal in icanon mode because they implement their own line editor which is much more advanced than the terminal driver built-in one. However, in their own line editor, to avoid confusing the users, they give the ^D character (or whatever the terminal's eof setting is with some) the same meaning (to signify eof).






share|improve this answer

























  • I knew once I began reading this comment that it was written by Stephane :) You, Stephane, are my Bash hero, and I am not being sarcastic. I'd love to have lunch with you and pick your brain if you're ever in NYC, I'm buying.

    – Gregg Leventhal
    Nov 17 '17 at 17:11











  • @GreggLeventhal. Thanks. Chances of me going to NYC anytime soon are pretty slim though.

    – Stéphane Chazelas
    Nov 18 '17 at 9:03


















8














CTRL_D is just a signal saying that this is the end of a text stream. You do not end a file with it, you end your input stream by typing it. Also CTRL_D does not stand for any character or byte as you can find out with the tool hexdump:



# cat >test.txt
asdf# hexdump -C test.txt
00000000 61 73 64 66 |asdf|
00000004
# ll test.txt
-rw-r--r-- 1 root root 4 Jan 21 11:55 test.txt





share|improve this answer


















  • 5





    And the reason that it ends the shell is that the shell is basically a process that accepts input and does stuff with it. When you tell it no more input is going to be coming, there's nothing more for the shell to do.

    – Jenny D
    Jan 21 '14 at 11:04











  • I realize that the EOF sequence is not contained by, say, a text file, and is generated by the OS to report that there is no more data to read. I think what I am really asking is if the interactive terminal session is seen as a real file stream by the shell, like any other file stream.

    – Geeb
    Jan 21 '14 at 11:25












  • Just edited the original question to clarify.

    – Geeb
    Jan 21 '14 at 11:32






  • 2





    yes, the stream that goes to bash is an input stream like any other. CTRL_D signals that the input stream is at its end and bash can quit.

    – Thorsten Staerk
    Jan 21 '14 at 11:42










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%2f110240%2fwhy-does-ctrl-d-eof-exit-the-shell%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









69














The ^D character (also known as 4 or 0x4, END OF TRANSMISSION in Unicode) is the default value for the eof special control character parameter of the terminal or pseudo-terminal driver in the kernel (more precisely of the tty line discipline attached to the serial or pseudo-tty device). That's the c_cc[VEOF] of the termios structure passed to the TCSETS/TCGETS ioctl one issues to the terminal device to affect the driver behaviour.



The typical command that sends those ioctls is the stty command.



To retrieve all the parameters:




$ stty -a
speed 38400 baud; rows 58; columns 191; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke


That eof parameter is only relevant when the terminal device is in icanon mode.



In that mode, the terminal driver (not the terminal emulator) implements a very simple line editor, where you can type Backspace to erase a character, Ctrl-U to erase the whole line... When an application reads from the terminal device, it sees nothing until you press Return at which point the read() returns the full line including the last LF character (by default, the terminal driver also translates the CR sent by your terminal upon Return to LF).



Now, if you want to send what you typed so far without pressing Enter, that's where you can enter the eof character. Upon receiving that character from the terminal emulator, the terminal driver submits the current content of the line, so that the application doing the read on it will receive it as is (and it won't include a trailing LF character).



Now, if the current line was empty, and provided the application will have fully read the previously entered lines, the read will return 0 character.



That signifies end of file to the application (when you read from a file, you read until there's nothing more to be read). That's why it's called the eof character, because sending it causes the application to see that no more input is available.



Now, modern shells, at their prompt do not set the terminal in icanon mode because they implement their own line editor which is much more advanced than the terminal driver built-in one. However, in their own line editor, to avoid confusing the users, they give the ^D character (or whatever the terminal's eof setting is with some) the same meaning (to signify eof).






share|improve this answer

























  • I knew once I began reading this comment that it was written by Stephane :) You, Stephane, are my Bash hero, and I am not being sarcastic. I'd love to have lunch with you and pick your brain if you're ever in NYC, I'm buying.

    – Gregg Leventhal
    Nov 17 '17 at 17:11











  • @GreggLeventhal. Thanks. Chances of me going to NYC anytime soon are pretty slim though.

    – Stéphane Chazelas
    Nov 18 '17 at 9:03















69














The ^D character (also known as 4 or 0x4, END OF TRANSMISSION in Unicode) is the default value for the eof special control character parameter of the terminal or pseudo-terminal driver in the kernel (more precisely of the tty line discipline attached to the serial or pseudo-tty device). That's the c_cc[VEOF] of the termios structure passed to the TCSETS/TCGETS ioctl one issues to the terminal device to affect the driver behaviour.



The typical command that sends those ioctls is the stty command.



To retrieve all the parameters:




$ stty -a
speed 38400 baud; rows 58; columns 191; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke


That eof parameter is only relevant when the terminal device is in icanon mode.



In that mode, the terminal driver (not the terminal emulator) implements a very simple line editor, where you can type Backspace to erase a character, Ctrl-U to erase the whole line... When an application reads from the terminal device, it sees nothing until you press Return at which point the read() returns the full line including the last LF character (by default, the terminal driver also translates the CR sent by your terminal upon Return to LF).



Now, if you want to send what you typed so far without pressing Enter, that's where you can enter the eof character. Upon receiving that character from the terminal emulator, the terminal driver submits the current content of the line, so that the application doing the read on it will receive it as is (and it won't include a trailing LF character).



Now, if the current line was empty, and provided the application will have fully read the previously entered lines, the read will return 0 character.



That signifies end of file to the application (when you read from a file, you read until there's nothing more to be read). That's why it's called the eof character, because sending it causes the application to see that no more input is available.



Now, modern shells, at their prompt do not set the terminal in icanon mode because they implement their own line editor which is much more advanced than the terminal driver built-in one. However, in their own line editor, to avoid confusing the users, they give the ^D character (or whatever the terminal's eof setting is with some) the same meaning (to signify eof).






share|improve this answer

























  • I knew once I began reading this comment that it was written by Stephane :) You, Stephane, are my Bash hero, and I am not being sarcastic. I'd love to have lunch with you and pick your brain if you're ever in NYC, I'm buying.

    – Gregg Leventhal
    Nov 17 '17 at 17:11











  • @GreggLeventhal. Thanks. Chances of me going to NYC anytime soon are pretty slim though.

    – Stéphane Chazelas
    Nov 18 '17 at 9:03













69












69








69







The ^D character (also known as 4 or 0x4, END OF TRANSMISSION in Unicode) is the default value for the eof special control character parameter of the terminal or pseudo-terminal driver in the kernel (more precisely of the tty line discipline attached to the serial or pseudo-tty device). That's the c_cc[VEOF] of the termios structure passed to the TCSETS/TCGETS ioctl one issues to the terminal device to affect the driver behaviour.



The typical command that sends those ioctls is the stty command.



To retrieve all the parameters:




$ stty -a
speed 38400 baud; rows 58; columns 191; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke


That eof parameter is only relevant when the terminal device is in icanon mode.



In that mode, the terminal driver (not the terminal emulator) implements a very simple line editor, where you can type Backspace to erase a character, Ctrl-U to erase the whole line... When an application reads from the terminal device, it sees nothing until you press Return at which point the read() returns the full line including the last LF character (by default, the terminal driver also translates the CR sent by your terminal upon Return to LF).



Now, if you want to send what you typed so far without pressing Enter, that's where you can enter the eof character. Upon receiving that character from the terminal emulator, the terminal driver submits the current content of the line, so that the application doing the read on it will receive it as is (and it won't include a trailing LF character).



Now, if the current line was empty, and provided the application will have fully read the previously entered lines, the read will return 0 character.



That signifies end of file to the application (when you read from a file, you read until there's nothing more to be read). That's why it's called the eof character, because sending it causes the application to see that no more input is available.



Now, modern shells, at their prompt do not set the terminal in icanon mode because they implement their own line editor which is much more advanced than the terminal driver built-in one. However, in their own line editor, to avoid confusing the users, they give the ^D character (or whatever the terminal's eof setting is with some) the same meaning (to signify eof).






share|improve this answer















The ^D character (also known as 4 or 0x4, END OF TRANSMISSION in Unicode) is the default value for the eof special control character parameter of the terminal or pseudo-terminal driver in the kernel (more precisely of the tty line discipline attached to the serial or pseudo-tty device). That's the c_cc[VEOF] of the termios structure passed to the TCSETS/TCGETS ioctl one issues to the terminal device to affect the driver behaviour.



The typical command that sends those ioctls is the stty command.



To retrieve all the parameters:




$ stty -a
speed 38400 baud; rows 58; columns 191; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke


That eof parameter is only relevant when the terminal device is in icanon mode.



In that mode, the terminal driver (not the terminal emulator) implements a very simple line editor, where you can type Backspace to erase a character, Ctrl-U to erase the whole line... When an application reads from the terminal device, it sees nothing until you press Return at which point the read() returns the full line including the last LF character (by default, the terminal driver also translates the CR sent by your terminal upon Return to LF).



Now, if you want to send what you typed so far without pressing Enter, that's where you can enter the eof character. Upon receiving that character from the terminal emulator, the terminal driver submits the current content of the line, so that the application doing the read on it will receive it as is (and it won't include a trailing LF character).



Now, if the current line was empty, and provided the application will have fully read the previously entered lines, the read will return 0 character.



That signifies end of file to the application (when you read from a file, you read until there's nothing more to be read). That's why it's called the eof character, because sending it causes the application to see that no more input is available.



Now, modern shells, at their prompt do not set the terminal in icanon mode because they implement their own line editor which is much more advanced than the terminal driver built-in one. However, in their own line editor, to avoid confusing the users, they give the ^D character (or whatever the terminal's eof setting is with some) the same meaning (to signify eof).







share|improve this answer














share|improve this answer



share|improve this answer








edited Mar 4 at 6:16









Basil Bourque

236314




236314










answered Jan 21 '14 at 12:47









Stéphane ChazelasStéphane Chazelas

309k57583945




309k57583945












  • I knew once I began reading this comment that it was written by Stephane :) You, Stephane, are my Bash hero, and I am not being sarcastic. I'd love to have lunch with you and pick your brain if you're ever in NYC, I'm buying.

    – Gregg Leventhal
    Nov 17 '17 at 17:11











  • @GreggLeventhal. Thanks. Chances of me going to NYC anytime soon are pretty slim though.

    – Stéphane Chazelas
    Nov 18 '17 at 9:03

















  • I knew once I began reading this comment that it was written by Stephane :) You, Stephane, are my Bash hero, and I am not being sarcastic. I'd love to have lunch with you and pick your brain if you're ever in NYC, I'm buying.

    – Gregg Leventhal
    Nov 17 '17 at 17:11











  • @GreggLeventhal. Thanks. Chances of me going to NYC anytime soon are pretty slim though.

    – Stéphane Chazelas
    Nov 18 '17 at 9:03
















I knew once I began reading this comment that it was written by Stephane :) You, Stephane, are my Bash hero, and I am not being sarcastic. I'd love to have lunch with you and pick your brain if you're ever in NYC, I'm buying.

– Gregg Leventhal
Nov 17 '17 at 17:11





I knew once I began reading this comment that it was written by Stephane :) You, Stephane, are my Bash hero, and I am not being sarcastic. I'd love to have lunch with you and pick your brain if you're ever in NYC, I'm buying.

– Gregg Leventhal
Nov 17 '17 at 17:11













@GreggLeventhal. Thanks. Chances of me going to NYC anytime soon are pretty slim though.

– Stéphane Chazelas
Nov 18 '17 at 9:03





@GreggLeventhal. Thanks. Chances of me going to NYC anytime soon are pretty slim though.

– Stéphane Chazelas
Nov 18 '17 at 9:03













8














CTRL_D is just a signal saying that this is the end of a text stream. You do not end a file with it, you end your input stream by typing it. Also CTRL_D does not stand for any character or byte as you can find out with the tool hexdump:



# cat >test.txt
asdf# hexdump -C test.txt
00000000 61 73 64 66 |asdf|
00000004
# ll test.txt
-rw-r--r-- 1 root root 4 Jan 21 11:55 test.txt





share|improve this answer


















  • 5





    And the reason that it ends the shell is that the shell is basically a process that accepts input and does stuff with it. When you tell it no more input is going to be coming, there's nothing more for the shell to do.

    – Jenny D
    Jan 21 '14 at 11:04











  • I realize that the EOF sequence is not contained by, say, a text file, and is generated by the OS to report that there is no more data to read. I think what I am really asking is if the interactive terminal session is seen as a real file stream by the shell, like any other file stream.

    – Geeb
    Jan 21 '14 at 11:25












  • Just edited the original question to clarify.

    – Geeb
    Jan 21 '14 at 11:32






  • 2





    yes, the stream that goes to bash is an input stream like any other. CTRL_D signals that the input stream is at its end and bash can quit.

    – Thorsten Staerk
    Jan 21 '14 at 11:42















8














CTRL_D is just a signal saying that this is the end of a text stream. You do not end a file with it, you end your input stream by typing it. Also CTRL_D does not stand for any character or byte as you can find out with the tool hexdump:



# cat >test.txt
asdf# hexdump -C test.txt
00000000 61 73 64 66 |asdf|
00000004
# ll test.txt
-rw-r--r-- 1 root root 4 Jan 21 11:55 test.txt





share|improve this answer


















  • 5





    And the reason that it ends the shell is that the shell is basically a process that accepts input and does stuff with it. When you tell it no more input is going to be coming, there's nothing more for the shell to do.

    – Jenny D
    Jan 21 '14 at 11:04











  • I realize that the EOF sequence is not contained by, say, a text file, and is generated by the OS to report that there is no more data to read. I think what I am really asking is if the interactive terminal session is seen as a real file stream by the shell, like any other file stream.

    – Geeb
    Jan 21 '14 at 11:25












  • Just edited the original question to clarify.

    – Geeb
    Jan 21 '14 at 11:32






  • 2





    yes, the stream that goes to bash is an input stream like any other. CTRL_D signals that the input stream is at its end and bash can quit.

    – Thorsten Staerk
    Jan 21 '14 at 11:42













8












8








8







CTRL_D is just a signal saying that this is the end of a text stream. You do not end a file with it, you end your input stream by typing it. Also CTRL_D does not stand for any character or byte as you can find out with the tool hexdump:



# cat >test.txt
asdf# hexdump -C test.txt
00000000 61 73 64 66 |asdf|
00000004
# ll test.txt
-rw-r--r-- 1 root root 4 Jan 21 11:55 test.txt





share|improve this answer













CTRL_D is just a signal saying that this is the end of a text stream. You do not end a file with it, you end your input stream by typing it. Also CTRL_D does not stand for any character or byte as you can find out with the tool hexdump:



# cat >test.txt
asdf# hexdump -C test.txt
00000000 61 73 64 66 |asdf|
00000004
# ll test.txt
-rw-r--r-- 1 root root 4 Jan 21 11:55 test.txt






share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 21 '14 at 10:58









Thorsten StaerkThorsten Staerk

2,26411323




2,26411323







  • 5





    And the reason that it ends the shell is that the shell is basically a process that accepts input and does stuff with it. When you tell it no more input is going to be coming, there's nothing more for the shell to do.

    – Jenny D
    Jan 21 '14 at 11:04











  • I realize that the EOF sequence is not contained by, say, a text file, and is generated by the OS to report that there is no more data to read. I think what I am really asking is if the interactive terminal session is seen as a real file stream by the shell, like any other file stream.

    – Geeb
    Jan 21 '14 at 11:25












  • Just edited the original question to clarify.

    – Geeb
    Jan 21 '14 at 11:32






  • 2





    yes, the stream that goes to bash is an input stream like any other. CTRL_D signals that the input stream is at its end and bash can quit.

    – Thorsten Staerk
    Jan 21 '14 at 11:42












  • 5





    And the reason that it ends the shell is that the shell is basically a process that accepts input and does stuff with it. When you tell it no more input is going to be coming, there's nothing more for the shell to do.

    – Jenny D
    Jan 21 '14 at 11:04











  • I realize that the EOF sequence is not contained by, say, a text file, and is generated by the OS to report that there is no more data to read. I think what I am really asking is if the interactive terminal session is seen as a real file stream by the shell, like any other file stream.

    – Geeb
    Jan 21 '14 at 11:25












  • Just edited the original question to clarify.

    – Geeb
    Jan 21 '14 at 11:32






  • 2





    yes, the stream that goes to bash is an input stream like any other. CTRL_D signals that the input stream is at its end and bash can quit.

    – Thorsten Staerk
    Jan 21 '14 at 11:42







5




5





And the reason that it ends the shell is that the shell is basically a process that accepts input and does stuff with it. When you tell it no more input is going to be coming, there's nothing more for the shell to do.

– Jenny D
Jan 21 '14 at 11:04





And the reason that it ends the shell is that the shell is basically a process that accepts input and does stuff with it. When you tell it no more input is going to be coming, there's nothing more for the shell to do.

– Jenny D
Jan 21 '14 at 11:04













I realize that the EOF sequence is not contained by, say, a text file, and is generated by the OS to report that there is no more data to read. I think what I am really asking is if the interactive terminal session is seen as a real file stream by the shell, like any other file stream.

– Geeb
Jan 21 '14 at 11:25






I realize that the EOF sequence is not contained by, say, a text file, and is generated by the OS to report that there is no more data to read. I think what I am really asking is if the interactive terminal session is seen as a real file stream by the shell, like any other file stream.

– Geeb
Jan 21 '14 at 11:25














Just edited the original question to clarify.

– Geeb
Jan 21 '14 at 11:32





Just edited the original question to clarify.

– Geeb
Jan 21 '14 at 11:32




2




2





yes, the stream that goes to bash is an input stream like any other. CTRL_D signals that the input stream is at its end and bash can quit.

– Thorsten Staerk
Jan 21 '14 at 11:42





yes, the stream that goes to bash is an input stream like any other. CTRL_D signals that the input stream is at its end and bash can quit.

– Thorsten Staerk
Jan 21 '14 at 11:42

















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%2f110240%2fwhy-does-ctrl-d-eof-exit-the-shell%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

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

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay