Advanced Programming in the UNIX Environment, Second Edition (Addison-Wesley Professional Computing Series)

The shell echoes everything you type, so when you type ^C, that too gets echoed (and in your case intercepted by your signal handler). The command stty -echo may or may not be useful to you depending on your needs/constraints, see the man page for stty for more information.

Of course much more goes on at a lower level, anytime you communicate with a system via peripherals device drivers (such as the keyboard driver that you use to generate the ^C signal, and the terminal driver that displays everything) are involved. You can dig even deeper at the level of assembly/machine language, registers, lookup tables etc. If you want a more detailed, in-depth level of understanding the books below are a good place to start:

The Design of the Unix OS is a good reference for these sort of things. Two more classic references: Unix Programming Environment and Advanced Programming in the UNIX Environment

Nice summary here in this SO question How does Ctrl-C terminate a child process?

"when youre run a program, for example find, the shell:

• the shell fork itself
• and for the child set the default signal handling
• replace the child with the given command (e.g. with find)
• when you press CTRL-C, parent shell handle this signal but the child will receive it - with the default action - terminate. (the child can implement signal handling too)"

Yes, this is possible.

The Unix way to do this is via fcntl or lockf. Whatever you choose, make sure to use only it and not mix the two. Have a look at this question (with answer) about it: fcntl, lockf, which is better to use for file locking?.

If you can, have a look at section 14.3 in Advanced Programming in the UNIX Environment.

Edited because I had to leave a meeting when I originally submitted this, but wanted to complete the information

Half of that material is learning about development in a Unix-like environment, and for that, I'd recommend a book since it's tougher to filter out useful information from the start.

I'd urge you to go to a bookstore and browse through these books:

• Advanced Programming in the Unix Environment by Stevens and Rago - this book covers threads, networking, IPC, signals, files, process management
• Unix Network Programming, Volume 1 by Stevens - This book is focused on network programming techniques, design - you might not need this until much later

• Unix/Linux System Administration - This book covers the more system administrator side of stuff, like directory structure of most Unix and Linux file systems (Linux distributions are more diverse than their Unix-named counterparts in how they might structure their file system)

  Other information accessible online:

• GCC Online Manual - the comprehensive GNU GCC documentation

• Beej's network programming guide - A really well written tutorial to network programming with the use of the BSD API. If you have done work with winsock, this should be mostly familiar to you.
• Red Hat Enterprise Linux 5's Deployment Guide - talks specifically about Red Hat EL 5's basic administrative/deployment, like installing with package manager, a Red Hat system's directory structure...
• make - Wikipedia article that will have links to the various make documentation out there
• binutils - These are the Linux tools used for manipulating object/binaries.
• GNU Build System - Wikipedia article about the traditional build system of GNU software, using autoconf/automake/autogen

Additionally, you will want to learn about ldd, which is like dependency walker in Windows. It lists a target binary's dependencies, if it has any.

And for Debugging, check out this StackOverflow thread which talks about a well written GDB tutorial and also links to an IBM guide.

Happy reading.

The following are great books describing all you are asking about:

Unix Systems Programming, Robbins and Robbins.

Advanced Programming in the UNIX Environment, Stevens.

They both do a great job talking about SYSV and POSIX IPC approaches and are the staple in college curriculum for CS.

You want system administration knowledge, or programming knowledge?

For programming:

• Advanced Programming in the Unix Environment
• Unix Network Programming
• The Art of Unix Programming

For system administration:

• Automating Linux and System Administration
• Unix and Linux Administration Handbook

Advanced Programming in the Unix Environment, 2nd Edition is a fantastic resource for learning the details of Unix systems programming. It's extremely well-written (one of my favorite books in the English Language), the depth is excellent, and the focus on four common environments (at the time of publication) help ensure that it is well-rounded. It's not too badly out of date -- new features in newer operating systems may be fantastic for specific problems, but this book really covers the basics very well.

The downside, of course, is that APUE2nd misses out on some fantastic third-party tools such as libevent, which can make programming sockets-based servers significantly easier. (And automatically picks the 'best' of select(2), poll(2), epoll(4), kpoll, and Windows event handling, for the platform.)

As for choosing between threads and processes, it comes down to: how much memory sharing do you want / need between tasks? If each process can run relatively isolated, processes provide better memory protection and no speed penalty. If processes need to interact with each other's objects, or objects 'owned' by a single thread, then threads provide better primitives for sharing data. (But many would argue that the shared memory of threads is an invitation to fun and exciting bugs. It Depends.)