Hot answers tagged

19

W. Richard Stevens: Advanced Programming in the UNIX Environment


15

The Linux Programming Interface by Michael Kerrisk Note that the author is the current maintainer of the Linux man pages. And that it's not out yet so I can't actually say how good it is, but I've read the blog posts about it and it sounds like a good book. (and he is the maintainer of the man pages, and those are mostly well written and he ought to know ...


12

There are in fact three gradations in system calls. Some system calls return immediately. “Immediately” means that the only thing they need is a little processor time. There's no hard limit to how long they can take (except in real-time systems), but these calls return as soon as they've been scheduled for long enough. These calls are usually called ...


9

Linux Systems Programming you can refer this also link


8

$ man 2 read ... READ(2) Linux Programmer's Manual READ(2) NAME read - read from a file descriptor SYNOPSIS #include <unistd.h> ...


8

There is no such system call, or set of system calls. It's all done by convention. Back in the old days, when a "terminal" was a large clunky piece of equiment linked to a computer via a cable, "smart terminals" would do things like move the cursor, or draw a line, or fill in a polygon with colors. The smart terminal usually did this via "escape sequenes". ...


6

Free Openclassroom Full courses. Short Videos. Free for everyone, stanford.edu coursera Education company that partners with the top universities and organizations in the world to offer courses online for anyone to take, for free. MIT Open Courseware Massachusetts Institute of Technology Courses. Codecademy Learn to code interactively, for free. ...


6

C is fine for system programming. As a starting point you could take a look at the books from this questions. As system programming is a broad field, perhaps they give you a hint where you could start. The ultimate project would definitely be the linux kernel, but it's hard as your first project. A smoother entrance to the field would be, to rewrite some ...


5

For GNOME, you can check out devhelp or help.gnome.org. But as everyone has already stated, there is no single SDK for "Linux". You need to have some idea of what you want before we can recommend specific developer resources.


5

Here you can find a database of the best books to learn Linux: http://www.tldp.org/guides.html I'm currently reading Introduction to Linux - A Hands on Guide by Machtelt Garrels And I like it, the way it's written make it easy to understand.


5

A unified SDK implies a single source for all the core libraries. That just isn't the way open source operating systems work. Bits and pieces come from all over, and they're all separately documented. EDIT: If paper's not a problem for you, the closest thing to what you're asking for is Advanced Programming in the Unix Environment 2/e by Stevens and Rago. ...


5

There are various tools to do this (of which, other than daemontools and perp, I don't have much experience with): daemontools is more or less the "classic" implementation that spawned most of the other modern implementations supervisord minit s6 runit The one we have come to like at my workplace is perp, which was the best featured for our ...


5

He's saying it's bound by a 64-bit type, which has a maximum value of (2 ^ 64) - 1 unsigned, or (2 ^ 63) - 1 signed (1 bit holds the sign, +/-). The type is not FILE; it's what the implementation uses to track the offset into the file, namely off_t, which is a typedef for a signed 64-bit type.1 (2 ^ 63) - 1 = 9223372036854775807. If a terabyte is 1000 ^ ...


5

Ambition or a overly severe urge for purity can lead you to do in-line assembly. For example, on x86_64 systems, you can do an open(2) system call like this: #include <sys/syscall.h> int linux_open(const char *pathname, unsigned long flags, unsigned long mode) { long ret; asm volatile ("syscall" : "=a" (ret) : "a" (__NR_open), ...


4

Typically command history is saved to a hidden file in the user's home directory. Other than that, you can log to stderr or syslog.


4

Checkout tput. It is a wrapper around ANSI Escape sequences that are supported (the amount of support differs a lot) by almost all terminal emulators. tput will only output the sequence if it is supported by the terminal, therefore you don't have to worry about the support. Or at least you don't have to worry about strange characters being printed in the ...


3

In your system admin type work, does some task you do either puzzle you (How does that work?) or irritate you (Shouldn't that work better/faster?)? Find several of those tasks, identify the very basic feature that you don't understand, or that irritates or puzzles you. Try to implement the puzzling, irritating or slow feature in C. You will get a more ...


3

There are two aspects: the ways system calls signal that an error occurred, and the way what error occurred is reported. Most system calls signal that an error occurred by returning -1, but this is not completely universal (for example, some system calls are always successful, e.g. getpid). If you know an error occurred, the error code is always in errno¹. ...


3

MSDN only documents Microsoft technologies, and not other libraries or frameworks to use on Windows; it doesn't include documentation from other vendors. Now, linux distros use software from much more organisations & companies, so the documentation also tends to be more distributed and less uniform. (And sometimes documentation isn't done very well, ...


3

I'd recommend Bruce Molay's "Understanding Unix/Linux Programming" (http://wps.prenhall.com/esm_molay_UNIXProg_1/). I had him as an instructor at Harvard, and he was fantastic.


3

I second the Stevens recommendation. The only real alternative is Advanced UNIX Programming by M.J. Rochkind: http://basepath.com/aup/ ORA's POSIX Programmer's Guide (http://oreilly.com/catalog/9780937175736) may be useful, but I haven't read it myself.


3

Consider: two processes can have the same file open for reading & writing at the same time, so some kind of communication is possible between the two. When process A writes to the file, it first populates a buffer inside its own process-specific memory with some data, then calls write which copies that buffer into another buffer owned by the kernel (in ...


3

In order to do system calls you normally have to execute some functions on the CPU that are not part of the C language specification. The system calls are either written in assembly for the CPU, and linked against, or some CPU specific inline assembly within a C function is used. Within the Linux kernel there are various macros defined to support this, ...


3

Reasonable and prudent, provided there are clear warnings on what file is failing, and why, so the user can fix the permissions issue. bash probably dates from a more trusting (and prank-ridden) day. Note that user files can legitimately be group writable, if the site has a policy of each user going into a group that only that user is in, otherwise not. ...


2

If you're seeking after the end of the file, you have to write at least one byte at that position: write(fd, "", 1); to have the OS fill the hole with zeros. So if you want to create an empty file of a certain size 1000 with lseek, do: lseek(fd, 999, SEEK_SET); //<- err check write(fd, "", 1); //<- err check ftruncate is probably better and ...


2

A couple of things need to be clarified here: There is virtually no difference between a program being on the hard storage or in memory. If the kernel doesn't find the file already mapped into memory, mmap happens and from then on, the file is accessed through the memory pages, mapped into the virtual memory of a program. Note that this whole mechanism is ...


2

Most of the time your language of choice will provide functions (of some sort) that eventually map to the relevant syscalls. In those cases, just use those and call it a day; no need to consider syscall interfaces at all. In fact, I'd argue that unless you're writing a standard library, there should be no need to consider the lower-level details in the first ...


2

You might want to start with something a lot simpler to get started in this sort of thing, as it sounds as if you are new to it. Perhaps the old talk / talkd command line program and daemon would be more approachable? Some valuable resources include APUE, or Advanced Programming in the UNIX Environment (Stevens), UNP, or UNIX Network Programming (Also by ...


2

As mentioned in other answers, Dan Bernstein's daemontools began a whole family of toolsets that share the same raw mechanisms: Adam Sampson's freedt Bruce Guenter's daemontools-encore Laurent Bercot's s6 My nosh Gerrit Pape's runit Wayne Marshall's perp Under pretty much any of them, one writes a run program that runs/is the dæmon, and a service ...



Only top voted, non community-wiki answers of a minimum length are eligible