Terminal – Using Ctrl+D to End Line Input

catcommand lineterminal

If I do

$ cat > file.txt

textCtrl–DCtrl–D

Question 1: If I don't press enter, why do I have to press Ctrl–D twice?

If I do

$ cat > file.txt

pa bam pshhhCtrl–Z

[2]+  Stopped         cat > file.txt
$ cat file.txt
$ cat > file.txt

pa bam pshhh

Ctrl–Z

[2]+  Stopped         cat > file.txt
$ cat file.txt
pa bam pshhh

Why is the second time the file with 1 line?

Best Answer

In Unix, most objects you can read and write - ordinary files, pipes, terminals, raw disk drives - are all made to resemble files.

A program like cat reads from its standard input like this:

n = read(0, buffer, 512);

which asks for 512 bytes. n is the number of bytes actually read, or -1 if there's an error.

If you did this repeatedly with an ordinary file, you'd get a bunch of 512-byte reads, then a somewhat shorter read at the tail end of the file, then 0 if you tried to read past the end of the file. So, cat will run until n is <= 0.

Reading from a terminal is slightly different. After you type in a line, terminated by the Enter key, read returns just that line.

There are a few special characters you can type. One is Ctrl-D. When you type this, the operating system sends all of the current line that you've typed (but not the Ctrl-D itself) to the program doing the read. And here's the serendipitous thing: if Ctrl-D is the first character on the line, the program is sent a line of length 0 - just like the program would see if it just got to the end of an ordinary file. cat doesn't need to do anything differently, whether it's reading from an ordinary file or a terminal.

Another special character is Ctrl-Z. When you type it, anywhere in a line, the operating system discards whatever you've typed up until that point and sends a SIGTSTP signal to the program, which normally stops (pauses) it and returns control to the shell.

So in your example

$ cat > file.txt
pa bam pshhh<Ctrl+Z>
[2]+  Stopped         cat > file.txt

you typed some characters that were discarded, then cat was stopped without having written anything to its output file.

$ cat > file.txt
pa bam pshhh
<Ctrl+Z>
[2]+  Stopped         cat > file.txt

you typed in one line, which cat read and wrote to its output file, and then the Ctrl-Z stopped cat.

Related Solutions

Bash – Bind Ctrl-\ in inputrc

Ctrl+\ is one of the control characters that cause the terminal to send a signal (SIGQUIT), like Ctrl+C (SIGINT) and Ctrl+Z (SIGTSTP). You can run stty -a to show what characters have a special meaning to the terminal; see Clear / erase a mistyped invisible password on a shell / terminal in Linux for more details. The upshot is that when you press Ctrl+\, bash doesn't see a character on its standard input, it sees a signal, and that doesn't go through the key bindings mechanisms.

You can switch off the meaning for the character in the terminal with the command stty quit undef. If you do that, bash will see the character as input and your key binding will take effect.

To arrange for Ctrl+\ to be a bash binding but have its normal terminal binding when running a command, change the terminal settings before and after running a command.

preexec () {
  stty quit '^\'
}
precmd () {
  stty quit undef
}

preexec_invoke_exec () {
    [ -n "$COMP_LINE" ] && return  # do nothing if completing
    [ "$BASH_COMMAND" = "$PROMPT_COMMAND" ] && return # don't cause a preexec for $PROMPT_COMMAND
    local this_command=`HISTTIMEFORMAT= history 1 | sed -e "s/^[ ]*[0-9]*[ ]*//"`;
    preexec "$this_command"
}
trap 'preexec_invoke_exec' DEBUG
PROMPT_COMMAND='precmd'

Rather than make the key type fg and a newline, bind the key to a shell command. You can't do that from .inputrc, which applies to all readline applications, not just to bash. Instead, define a bash binding in your .bashrc:

bind -x '"\C-\\": "fg"'

Does the cat command pass back a file or the contents of the file

In your first example

cat f.txt | grep "someText"

grep doesn't get a filename argument, only a string to search for. In that case grep will read the text to search from standard input. In this case that standard input is piped in from the output of cat f.txt, which outputs the content of the file not the filename.
What you also could have done to make grep read from stdin is to use:

< f.txt grep "someText"

Using cat is quite often redundant on its own (independent of grep) and can be replaced by the input redirection as above. I would always use the second form in your example, unless you have to do some preprocessing on the input.

Best Answer

Related Solutions

Bash – Bind Ctrl-\ in inputrc

Does the cat command pass back a file or the contents of the file

Related Question