home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0066.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  4.5 KB  |  110 lines
  1. Submitted-by: peter@ferranti.com (peter da silva)
  2.  
  3. In article <1992Jan8.233116.25927@uunet.uu.net> brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein) writes:
  4. > Peter da Silva writes:
  5. > > Because the more things you can access via the open() system call, the more
  6. > > powerful an environemnt you have. For example, older programs become able to
  7. > > access more data sources and sinks without modification or recompiling.
  8.  
  9. > No. If you need a kludge to support non-UNIXy programs, use /dev/fd.
  10.  
  11. You say it's a kludge to support non-UNIXy programs. I say it's a natural
  12. extension to the existing file system to enhance normal, conventional, UNIX
  13. programs.
  14.  
  15. > > For a concrete example, in AmigaDOS this expectation is taken further:
  16.  
  17. > Fine. If you think that AmigaDOS features are appropriate for POSIX
  18. > standardization, then implement them in a UNIX system and wait for their
  19. > obvious advantages to win everyone over.
  20.  
  21. A lot of them are *copied* from UNIX systems to AmigaDOS, for example the
  22. (initially third-party, and freeware) PIPE: and RDF: devices.
  23.  
  24. > > Not very, but it's hard to create one from your ".mailrc" file.
  25.  
  26. > Hmmm? There are many programs running around (e.g., clientserver) which
  27. > do the same thing for network connections that the shell (via < and >)
  28. > does for the filesystem.
  29.  
  30. I see, and how do you specify them to a program that expects a filename?
  31.  
  32. > > > also bloating the kernel for something which the vast majority of
  33. > > > programs will never use.
  34. > > The challenge is on... let's look though my System III (because it's older
  35. > > and therefore more "pure") Xenix manual:
  36. > > accton, awk, bdiff, bfs, chgrp, chmod, chown, cmp, comm, cp, cron, cu, diff,
  37. > > diff3, ed, finger, join, ln, look, lpq, lpr, mail, make, more (and less),
  38. > > mv, nohup, pr, rm, sdiff, tee, touch, and uucp (etc).
  39.  
  40. > bdiff, cmp, comm, diff, diff3, join, look, more, nohup, pr, sdiff, tee,
  41. > and touch can be written to work with file descriptors under v7.
  42.  
  43. Yes... at the dual cost of spending time doing it, and reducing their
  44. utility in conventional shell scripts.
  45.  
  46. > Under
  47. > BSD, the syscalls for working with descriptors are more complete, so you
  48. > can do chgrp, chmod, chown, etc. without explicit filenames. I also
  49. > wonder what sense it makes to do a chmod on /dev/tcp/uunet.uu.net/ftp---
  50.  
  51. It makes sense to chmod /dev/tcp, though. Or /../xds13.
  52.  
  53. As for mv, rm, cp, etcetera... you need to re-invent those tools for each
  54. new name space you create (and deal with conflicts: is "3" a file name, a
  55. file descriptor number, or an IP port number?).
  56.  
  57. > And do you have a system where
  58. > accton works over the network?
  59.  
  60. Yes, you can specify a file on a remote machine.
  61.  
  62. > If so I'm sure crackers love your system.
  63.  
  64. Not really. Our network, as far as possible, looks like a single computer.
  65. Permissions are mirrored across it. It's as secure as a single, larger
  66. machine would be.
  67.  
  68. > Hardly. Adding new ways to create file descriptors involves thinking up
  69. > new ways to deal with security. Filesystem security is utterly
  70. > inappropriate for network connections, for example.
  71.  
  72. Expand?
  73.  
  74. > > > Finally, let's consider super-open()'s advantages for users. Certainly
  75. > > > it'd be nice for a user to be able to type something like, say,
  76. > > >    % cat #13@athena.mit.edu
  77. > > More like "cat /dev/telnet/athena.mit.edu/13".
  78.  
  79. > Whatever. The shell can still do it!
  80.  
  81. The shell can't do it for "cc" or "make".
  82.  
  83. > > then what do you do when you want to access this from "awk", or create a
  84. > > (sumbolic) link to it called "/dev/weather"?
  85. > 
  86. > The pure solution is to have every program keep a file descriptor around
  87. > for talking to the shell. Then requests for opening files can be
  88. > shuttled down that descriptor. The problem reduces once again to a small
  89. > matter of shell programming.
  90.  
  91. I see. The shell becomes the "super open" with its own address space. And
  92. you don't get a uniform namespace across applications. You have all the
  93. disadvantages you've claimed for a "super open", and none of the advantages.
  94.  
  95. > Less pure solutions involve /dev/fd or perhaps what Convex calls
  96. > ``watchdogs.'' Both of these are far cleaner mechanisms than
  97. > super-open(), and since they've at least been considered by the market,
  98. > they'd be far more appropriate for standardization.
  99.  
  100. "watchdogs" *are* an implementation of what I'm talking about.
  101. -- 
  102. -- Peter da Silva,  Ferranti International Controls Corporation
  103. -- Sugar Land, TX  77487-5012;  +1 713 274 5180
  104. -- "Have you hugged your wolf today?"
  105. -- grep -il 'sig.*virus' $*|xargs sed -n '/^-- /,$p'|post -n alt.fan.warlord
  106.  
  107.  
  108. Volume-Number: Volume 26, Number 77
  109.  
  110.