bug#14190: cat command bug

[Bob Proulx]

hockseng leow wrote:
> >> Ctrl-c is behaving like Ctrl-d.

In the context you describe, yes, by necessity.  It always has.

> >> When redirecting from standard-in to an existing file, Ctrl-c empties
> >> out the old file contents. In the past, Ctrl-c just aborts cat and
> >> leave the existing file unchanged.
>
> $ cat abc.txt
> abc
> $ cat >abc.txt
> def
> ^C
> $ cat abc.txt
> def

That is the test case explanation you needed to have included before!
It explains what you are seeing and thinking.  Let's walk through it
line by line.

  $ cat abc.txt
  abc

A file has existing contents.

  $ cat >abc.txt

The shell has immediately truncated the contents of the file to a zero
lenth file.  The previous contents are gone.  If you check at that
point you will find that the file is empty.

  def

You typed in "def" followed by enter which generated a newline and cat
copied that to the file.  (Sometimes programs will buffer output and
in general libc's stdio buffering will cache up small writes into
larger writes for performance reasons.  But here it is going to write
it line by line because it is coming from your terminal.)

  ^C

You typed in control-C which generated a SIGINT sent to the cat
process.  The cat process exited due to that signal.  If you check the
exit code using the wait(2) macros WIFEXITED(status) and others you
will find it is exiting non-zero due WIFSIGNALED(status).  The shell
usually maps this to 130 which is a bit-mapped value for exiting
because of SIGINT.  "echo $?" will show this as "130".

Because the program has exited the operation system will close all of
the processes open file descriptors.  The stdout for that process was
redirected to the file by the shell.  When the process exited any open
file descriptors are closed by the operating system.

That may have a result similar to a control-D but the reasoning is
completely different.  With a C-d the stty driver would answer the
cat process' read(2) call by sending a zero byte result.  The cat
program would interpret that as an end of file and then it would close
the output itself and exit with a success exit code 0 just as if it
had come to the end of a file.

C-c interrupts the process and results in a non-zero failure exit
code.  C-d is a normal operation and results in the process closing
the output file normally and exiting with a zero success exit code.
The two things are different things.

> >> It happens in Fedora 17.

And it also happens on every Unix and GNU operating system dating back
to 1970.  That is the way things work.  Anything else would be
incorrect operation.  Starting with the shell truncating the file
immediately upon seeing the redirection of stdout to it with
">abc.txt".  Immediately upon doing the redirection that file is
truncated to zero.

Hope that explanation helps.

Bob