Let's suppose I am connecting to telnet server, where bash is running.
I am executing command cat > /tmp/qqq; typing some contents of a file and finally sending 0x0a 0x04 which meant EOF.

The question is: how and where that EOF would be processed?
Will it be transmitted as is to the cat application, maybe bash will close cat's STDIN upon receiving of EOF, or it is somehow processed by some driver before shell?

PS. original problem: I wrote java application doing described thing. It connects to telnet, runs cat, sends data finished with EOF. But when telnet account is operating under tcsh - EOF is eaten somewhere and cat continues to expect data after EOF. If sh is running on telnet account - cat command stopping after EOF. More details about that application is here.

EOF (Ctrl/D) is an action that causes stdin to be closed, which in turn causes cat to exit. It's not a character that's transmitted.
– roaimaJun 17 '15 at 20:57

Something is receiving it and processing, I am looking for that place - to understand why it behaves differently when I am connecting to sh or tcsh. EOF is transmitted to the server at least. Recently I checked "cat" implementation in GNU's coreutils source code and not found special usage of EOF. It seems that it is handled by shell or somewhere before.
– Mikhail TsaplinJun 18 '15 at 4:04

2

You would find the character representing EOF for a terminal defined in the TTY layer. See stty -a and particularly stty eof. It is interpreted and actioned by the TTY layer. Everything else just handles stdin being closed.
– roaimaJun 18 '15 at 7:11

What happens in that case: under socket layer, there is a tty layer, as you are saying, when it sees 0x04 it closes input stream of underlying program, right? But our next underlying program is a shell process - and if tty layer will close shell's input stream - it should stop working...
– Mikhail TsaplinJun 18 '15 at 7:47

This way - it seems that tty sends EOF to shell, and it closes STDIN of process it started.
– Mikhail TsaplinJun 18 '15 at 7:59