Memory can fail. I thought there is a difference between ctrl-c and ctrl-d.
I checked with an old Redhat and it also behaved that way. Thanks. On Mon, Apr 15, 2013 at 4:13 AM, Bob Proulx <b...@proulx.com> wrote: > 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 -- Leow Hock Seng Tel:64463211 Mobile:96740759 http://www.oses.sg