Rather reasonable and entertaining reading as the same time.
In the future I will certainly refer people to his page, whenever I will happen to find an opportunity.
I am available for hire as a software freelancer – telecommuting, Europe, the Americas, Middle East, … My blog is *my* blog. You have to be either rather nice for your comments to get through here - or *rather* beautiful.
ABSTRACT
Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file. This ambiguity is a source of confusion, especially since some shells work overtime to present a consistent view from programs such as pwd, while other programs and the kernel itself do nothing about the problem.
Plan 9 has no symbolic links but it does have other mechanisms that produce the same difficulty. Moreover, Plan 9 is founded on the ability to control a program’s environment by manipulating its name space. Ambiguous names muddle the result of operations such as copying a name space across the network.
To address these problems, the Plan 9 kernel has been modified to maintain an accurate path name for every active file (open file, working directory, mount table entry) in the system. The definition of ‘accurate’ is that the path name for a file is guaranteed to be the rooted, absolute name the program used to acquire it. These names are maintained by an efficient method that combines lexical processing—such as evaluating .. by just removing the last path name element of a directory—with local operations within the file system to maintain a consistently, easily understood view of the name system. Ambiguous situations are resolved by examining the lexically maintained names themselves.
A new kernel call, fd2path, returns the file name associated with an open file, permitting the use of reliable names to improve system services ranging from pwd to debugging. Although this work was done in Plan 9, Unix systems could also benefit from the addition of a method to recover the accurate name of an open file or the current directory.
The pipegrep program greps the output of a series of commands. The difficulty with doing this using the normal grep program is that you lose track of which file was being processed. This program prints out the command it was executing at the time, including the filename. The command, which is a single argument, will be executed once for each file in the list. If you give the string {} anywhere in the command, the filename will be substituted at that point. Otherwise the filename will be added on to the end of the command. This program has one option, -l, which causes it to list the files containing the pattern.
there is crontab entry, that did not get executed, because we exceeded the maximum number of … – maybe you want to fix something hereI suppose, similar limits exist in every UNIX flavour.
Welcome to the Unix Reconstruction Project.
Our goal is quite simply to reimplement the classic Unix command set in pure Perl, and to have as much fun as we can doing so.