| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| systems:pdp7_unix [2015/12/29 23:53] – wkt | systems:pdp7_unix [2015/12/29 23:55] – wkt |
|---|
| The //link// call took the form | The //link// call took the form |
| |
| <code>link(dir, file, newname) | <code> |
| | link(dir, file, newname) |
| </file> | </code> |
| |
| where //dir// was a directory file in the current directory, //file// an existing entry in that directory, and //newname// the name of the link, which was added to the current directory. Because //dir// needed to be in the current directory, it is evident that today's prohibition against links to directories was not enforced; the PDP-7 Unix file system had the shape of a general directed graph. | where //dir// was a directory file in the current directory, //file// an existing entry in that directory, and //newname// the name of the link, which was added to the current directory. Because //dir// needed to be in the current directory, it is evident that today's prohibition against links to directories was not enforced; the PDP-7 Unix file system had the shape of a general directed graph. |
| ln ken x x | ln ken x x |
| rm ken | rm ken |
| |
| </code> | </code> |
| |
| The //dd// convention made the //chdir// command relatively convenient. It took multiple arguments, and switched the current directory to each named directory in turn. Thus | The //dd// convention made the //chdir// command relatively convenient. It took multiple arguments, and switched the current directory to each named directory in turn. Thus |
| |
| <code>chdir dd ken | <code> |
| | chdir dd ken |
| </code> | </code> |
| |
| Curiously, the primitives that became //wait// were considerably more general than the present scheme. A pair of primitives sent one-word messages between named processes: | Curiously, the primitives that became //wait// were considerably more general than the present scheme. A pair of primitives sent one-word messages between named processes: |
| |
| <code>smes(pid, message) | <code> |
| | smes(pid, message) |
| (pid, message) = rmes() | (pid, message) = rmes() |
| |
| </code> | </code> |
| |
| Another mismatch between the system as it had been and the new process control scheme took longer to become evident. Originally, the read/write pointer associated with each open file was stored within the process that opened the file. (This pointer indicates where in the file the next read or write will take place.) The problem with this organization became evident only when we tried to use command files. Suppose a simple command file contains | Another mismatch between the system as it had been and the new process control scheme took longer to become evident. Originally, the read/write pointer associated with each open file was stored within the process that opened the file. (This pointer indicates where in the file the next read or write will take place.) The problem with this organization became evident only when we tried to use command files. Suppose a simple command file contains |
| |
| <code>ls | <code> |
| | ls |
| who | who |
| |
| </code> | </code> |
| |
| and it is executed as follows: | and it is executed as follows: |
| |
| <code>sh comfile >output | <code> |
| | sh comfile>output |
| </file> | </code> |
| |
| The sequence of events was | The sequence of events was |
| The very convenient notation for IO redirection, using the `>' and `<' characters, was not present from the very beginning of the PDP-7 Unix system, but it did appear quite early. Like much else in Unix, it was inspired by an idea from Multics. Multics has a rather general IO redirection mechanism [3] embodying named IO streams that can be dynamically redirected to various devices, files, and even through special stream-processing modules. Even in the version of Multics we were familiar with a decade ago, there existed a command that switched subsequent output normally destined for the terminal to a file, and another command to reattach output to the terminal. Where under Unix one might say | The very convenient notation for IO redirection, using the `>' and `<' characters, was not present from the very beginning of the PDP-7 Unix system, but it did appear quite early. Like much else in Unix, it was inspired by an idea from Multics. Multics has a rather general IO redirection mechanism [3] embodying named IO streams that can be dynamically redirected to various devices, files, and even through special stream-processing modules. Even in the version of Multics we were familiar with a decade ago, there existed a command that switched subsequent output normally destined for the terminal to a file, and another command to reattach output to the terminal. Where under Unix one might say |
| |
| <code>ls >xx | <code>ls>xx |
| </code> | </code> |
| |
| to get a listing of the names of one's files in //xx//, on Multics the notation was | to get a listing of the names of one's files in //xx//, on Multics the notation was |
| |
| <code>iocall attach user_output file xx | <code> |
| | iocall attach user_output file xx |
| list | list |
| iocall attach user_output syn user_i/o | iocall attach user_output syn user_i/o |
| | </code> |
| </file> | |
| |
| Even though this very clumsy sequence was used often during the Multics days, and would have been utterly straightforward to integrate into the Multics shell, the idea did not occur to us or anyone else at the time. I speculate that the reason it did not was the sheer size of the Multics project: the implementors of the IO system were at Bell Labs in Murray Hill, while the shell was done at MIT. We didn't consider making changes to the shell (it was //their// program); correspondingly, the keepers of the shell may not even have known of the usefulness, albeit clumsiness, of //iocall//. (The 1969 Multics manual [4] lists //iocall// as an `author-maintained,' that is non-standard, command.) Because both the Unix IO system and its shell were under the exclusive control of Thompson, when the right idea finally surfaced, it was a matter of an hour or so to implement it. | Even though this very clumsy sequence was used often during the Multics days, and would have been utterly straightforward to integrate into the Multics shell, the idea did not occur to us or anyone else at the time. I speculate that the reason it did not was the sheer size of the Multics project: the implementors of the IO system were at Bell Labs in Murray Hill, while the shell was done at MIT. We didn't consider making changes to the shell (it was //their// program); correspondingly, the keepers of the shell may not even have known of the usefulness, albeit clumsiness, of //iocall//. (The 1969 Multics manual [4] lists //iocall// as an `author-maintained,' that is non-standard, command.) Because both the Unix IO system and its shell were under the exclusive control of Thompson, when the right idea finally surfaced, it was a matter of an hour or so to implement it. |
