User Tools

Site Tools


systems:pdp7_unix

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
systems:pdp7_unix [2015/12/29 23:53] wktsystems:pdp7_unix [2015/12/29 23:54] wkt
Line 28: Line 28:
 The //link//  call took the form The //link//  call took the form
  
-<code>link(dir, file, newname)+<code> 
 +link(dir, file, newname)
  
 </file> </file>
Line 39: Line 40:
 ln ken x x ln ken x x
 rm ken rm ken
- 
 </code> </code>
  
Line 46: Line 46:
 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>
  
Line 90: Line 90:
 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>
  
Line 109: Line 109:
 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> </file>
Line 132: Line 133:
 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
systems/pdp7_unix.txt · Last modified: 2023/02/16 08:04 by admin