Why does Ctrl-D (EOF) exit the shell?
Clash Royale CLAN TAG#URR8PPP
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
add a comment |
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
stackoverflow.com/questions/1516122/…
– Yogi
Jan 21 '14 at 10:56
6
FYI, in bash you can doset -o ignoreeof
to change that behavior.
– Keith
Jan 21 '14 at 11:15
add a comment |
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
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
shell escape-characters
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 doset -o ignoreeof
to change that behavior.
– Keith
Jan 21 '14 at 11:15
add a comment |
stackoverflow.com/questions/1516122/…
– Yogi
Jan 21 '14 at 10:56
6
FYI, in bash you can doset -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
add a comment |
2 Answers
2
active
oldest
votes
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
).
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
add a comment |
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
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
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%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
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
).
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
add a comment |
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
).
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
add a comment |
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
).
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
).
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
add a comment |
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
add a comment |
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
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
add a comment |
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
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
add a comment |
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
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
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
add a comment |
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
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f110240%2fwhy-does-ctrl-d-eof-exit-the-shell%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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