Advanced Programming in the UNIX Environment, 3rd Edition

Author: W. Richard Stevens, Stephen A. Rago
All Stack Overflow 13
This Year Hacker News 2
This Month Stack Overflow 1


by anonymous   2018-01-07
I recommend you get a book about Unix (or rather POSIX) systems programming, and read that. It should tell you all you need to know. I haven't read the latest edition, but I heartily recommend [Advanced Programming in the UNIX environment](
by anonymous   2017-12-11
I suggest any of these 3 books (1 is enough to start with; you can get the others later): W Richard Stevens, Stephen A Rago [Advanced Programming in the Unix Environment, 3rd Edn]( — Marc J Rochkind [Advanced Unix Programming, 2nd Edn]( — Michael Kerrisk [The Linux Programming Interface: A Linux and Unix System Programming Handbook](
by techjuice   2017-08-20
If you want to become a professional and not just a dabbler I would recommend reading some of the following books I have in my bookshelf:

[0] RHCSA & RHCE Training and Exam Preparation Guide by Asghar Ghori. This book will help insure you know your stuff as your system engineer/administrator wise.

[1] A Practical Guide to Linux Commands, Editor and Shell Programming Third Edition. This book will cover the majority of what you would need and want to know when connecting to a remote linux system over ssh.

If you want to get under the hood and become an expert, the following books should help get you started:

[2] Advanced Programming in the UNIX Environment

[3] The Linux Programming Interface: A Linux and UNIX System Programming Handbook

[4] Linux Kernel Development 3rd Edition

To get a nice general overview and get up and going quickly:

[5] How Linux works: What every superuser should know

[6] The Linux Command Line

[7] Python Crash Course

[8] Automate the boring stuff with Python. This is a great book to help you think about how to automate most of the repetitive things you will end up doing on a regular basis.










by generic_user   2017-08-20
Its a bit tricky I think.

> A secure coding standard form CERT should focus entirely on describing conventions and program properties that do not already follow from the standard as a matter of correctness.

from CERT 1.7 "The wiki also contains two platform-specific annexes at the time of this writing; one annex for POSIX and one for Windows. These annexes have been omitted from this standard because they are not part of the core standard."

So while the CERT does use some examples from system interfaces its not a standard for programming the system interfaces for POSIX or Windows. It looks like there trying to limit the standard to ISO C. The examples you gave fall into the system interface category. POSIX is huge and the same for Windows, much bigger then ISO C.

I think in order to explain conventions for a system interface you really need a longer form publication like a book. So you can take 50 pages to describe an interface and how to use it and show examples etc.

The best way that I have found to figure this stuff out is the standard way. You get a copy of all the relevant standards as a foundation, ISO, POSIX, Window and stuff like CERT. Then you you get some of the system programming books (listed below). Then you find get some good reference code that show best practice. usually code from the operating system or utilities. Lastly read all the compiler docs and tool docs to set up the best code analysis framework you can.

These are a few system programming books that I use.

(best intro book) GNU/Linux Application Programming

UNIX Systems Programming

Advanced Programming in the UNIX Environment

Windows System Programming

The Linux Programming Interface

edit: I'm not sure your skill level, you may have seen all of those but I posted them regardless. There is a lot of security and convention in those books.

by AviewAnew   2017-08-20

Reference Style - All Levels



Above Intermediate

Uncategorized Additional C Programming Books

by anonymous   2017-08-20

It may be simplest to use the expect program; it does most of the necessary work for you.

The necessary work is fiddly. It involves using pseudo-ttys, which are devices that look to programs like terminals. If you're going to roll your own, then the POSIX system calls you need to know about are:

The posix_openpt() interface is relatively new (Issue 6, compared with Issue 4, Version 2 for the other functions listed). If your system doesn't have posix_openpt(), you need to get yourself one of the Unix books (Stevens or Rochkind, probably) to find out how else to do open the master side of a pty, or read your system manuals rather carefully. However, the rationale for posix_openpt() at the link above may also help — it also has guidelines for using the other functions. Linux has posix_openpt(); so does Mac OS X and by inference the BSD systems generally.


by anonymous   2017-08-20

Userspace open function is what you are thinking of, that is a system call which returns a file descriptor int. Plenty of good references for that, such as APUE 3.3.

Device driver "open method" is a function within file_operations structure. It is different than userspace "file open". With the device driver installed, when user code does open of the device (e.g. accessing /dev/scull0), this "open method" would then get called.

by anonymous   2017-08-20

The nohup command is the poor man's way of running a process as a daemon. As Bruno Ranschaert noted, when you run a command in an interactive shell, it has a controlling terminal and will receive a SIGHUP (hangup) signal when the controlling process (typically your login shell) exits. The nohup command arranges for input to come from /dev/null, and for both output and errors to go to nohup.out, and for the program to ignore interrupts, quit signals, and hangups. It actually still has the same controlling terminal - it just ignores the terminals controls. Note that if you want the process to run in the background, you have to tell the shell to run it in the background - at least on Solaris (that is, you type 'nohup sleep 20 &'; without the ampersand, the process runs synchronously in the foreground).

Typically, a process run via nohup is something that takes time, but which does not hang around waiting for interaction from elsewhere.

Typically (which means if you try hard, you can find exceptions to these rules), a daemon process is something which lurks in the background, disconnected from any terminal, but waiting to respond to some input of some sort. Network daemons wait for connection requests or UDP messages to arrive over the network, do the appropriate work and send a response back again. Think of a web server, for example, or a DBMS.

When a process fully daemonizes itself, it goes through some of the steps that the nohup code goes through; it rearranges its I/O so it is not connected to any terminal, detaches itself from the process group, ignores appropriate signals (which might mean it doesn't ignore any signals, since there is no terminal to send it any of the signals generated via a terminal). Typically, it forks once, and the parent exits successfully. The child process usually forks a second time, after fixing its process group and session ID and so on; the child then exits too. The grandchild process is now autonomous and won't show up in the ps output for the the terminal where it was launched.

You can look at Advanced Programming in the Unix Environment, 3rd Edn by W Richard Stevens and Stephen A Rago, or at Advanced Unix Programming, 2nd Edn by Marc J Rochkind for discussions of daemonization.

I have a program daemonize which will daemonize a program that doesn't know how to daemonize itself (properly). It was written to work around the defects in a program which was supposed to daemonize itself but didn't do the job properly. Contact me if you want it - see my profile.