Tag Info

The new process will be created within the fork() call, and will start by returning from it just like the parent. The return value (which you stored in retval) from fork() will be: 0 in the child process The PID of the child in the parent process -1 in the parent if there was a failure (there is no child, naturally) Your testing code works correctly; it ...

The POSIX 2008 standard has a section describing "Shell and Utilities". Generally, if you stick to that your scripts should be fairly future-proof, except possibly for deprecations, but those hardly happen overnight so you should have plenty of time to update your scripts. In some cases where output format for a single utility varies widely across ...

I'll try to answer from my experience. Commands don't really adhere to a formal specification, but they do adhere to a requirement to consume and generate line-oriented text. Yes, of course. Before the GNU utilities became a de facto standard, a lot of vendors would have quirky output, especially with respect to ps and ls. This caused a lot of pain. ...

I thought that fork() creates a same process, so I initially that that in that program, the fork() call would be recursively called forever. I guess that new process created from fork() starts after the fork() call? Yes. Let's number the lines: int main (int argc, char **argv) { int retval; /* 1 */ ...

First, very brief answers to your questions: Formal standardization of input/output conventions: no Breakage in the past due to changing output: yes Absolutely impossible to break future filters: no How can I protect myself against changes: be conservative When you say "API", you're using a term that (for good or ill) implies too much formality around ...

A new file descriptor always occupies the lowest integer not already in use. $ cat >test.c main(){exit(open("/dev/null",0));} ^D $ cc test.c $ ./a.out; echo $? 3 $ ./a.out <&-; echo $? 0 $ ./a.out >&-; echo $? 1 The system doesn't care about "standard file descriptors" or anything like that. If file descriptor 0 is closed, then a new ...

ntfs-3g can read alternate data streams in NTFS. From its manpage: Alternate Data Streams (ADS) NTFS stores all data in streams. Every file has exactly one unnamed data stream and can have many named data streams. The size of a file is the size of its unnamed data stream. By default, ntfs-3g will only read the ...

You can simply do something like this: $ TZ=Europe/Moscow date Thu Jun 9 08:34:46 MSD 2011 $ TZ=America/NewYork date Thu Jun 9 04:34:48 America 2011 You can find the zone names in /usr/share/zoneinfo. Of course, this requires that the machine you run this on has the correct time set. (You can't really get the time by country, because a lot of countries ...

If you just want the timezone, then timezones are stored in /usr/share/zoneinfo. If you want to be able to retrieve the current time for a number of different cities or countries, then you can pull them from the Date and Time Gateway.

Only covering 1) of your question. Naturally APIs can always change at the will of their creators, and thusly break dependent software, in any language. That said, the great idea of the Unix tools' I/O "APIs" is that there is practically none (maybe 0x0a as line end). A good script filters data with the Unix tools instead of creating it. That means that ...

Here is a link to libnetfilter_conntrack. You would have to re-write your program in a language that can support calling C functions from a library directly. But I think this library will have the hooks you need to get the data you want much faster than parsing through that text file. This is what the iptstate program uses to accomplish its task.

There are only de facto IO standards — whitespace and null separated output. As for compatibility, we usually revert to checking version numbers of individual filters. Not that they change much, but when you want to use a brand new feature and still want the script to run on older versions, you have to "ifdef" it out somehow. There is practically no ...