home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / os2 / misc / 41635 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  3.1 KB

  1. Path: sparky!uunet!stanford.edu!rutgers!njitgw.njit.edu!hertz.njit.edu!dic5340
  2. From: dic5340@hertz.njit.edu (David Charlap)
  3. Newsgroups: comp.os.os2.misc
  4. Subject: Re: Detach command.
  5. Message-ID: <1993Jan8.165832.26918@njitgw.njit.edu>
  6. Date: 8 Jan 93 16:58:32 GMT
  7. References: <1ii3r8INNfea@iskut.ucs.ubc.ca> <1993Jan7.230727.1343@njitgw.njit.edu> <1993Jan08.075225.9277@kub.nl>
  8. Sender: news@njit.edu
  9. Organization: New Jersey Institute of Technology, Newark, N.J.
  10. Lines: 49
  11. Nntp-Posting-Host: hertz.njit.edu
  12.  
  13. In article <1993Jan08.075225.9277@kub.nl> hoppie@kub.nl (Jeroen Hoppenbrouwers) writes:
  14. >Eh? I always thought that being able to push a running UNIX process in the background
  15. >with Ctrl-Z and call it back later with FG, together with the BG and JOBS commands,
  16. >were UNIX *shell* commands, and thus implemented by the shell, not by the UNIX
  17. >kernel?!? If I'm wrong, please tell me.
  18.  
  19. Yes, but...
  20.  
  21. Unix programs (not counting x-apps) perform all console I/O by reading
  22. and writing the stdin/stdout/stderr devices.  These, in an ordinary
  23. shell, are connected to /dev/tty, but a program launcher (a shell) can
  24. connect them elsewhere - like into pipes.  The shell can then filter
  25. the I/O.  Since Unix has system calls to suspend and resume, this
  26. works fine.
  27.  
  28. OS/2 doesn't use a device-shell interface.  OS/2 apps (full-screen
  29. ones, anyway), make Vio* calls for I/O, which is a direct-to-device
  30. method.  The shell (in this case, CMD.EXE) never sees anything.  If
  31. all text-based apps used stdin/stdout/stderr (as IBM is now pushing),
  32. it could be possible for some form of "real" shell to be written, but
  33. at this time, there are very few apps that would work with it.
  34.  
  35. Also note that screen access would then have the same limitations that
  36. Unix has: no ability to read the display buffer without shadowing it
  37. in memory, and no direct-cursor/color control without ANSI sequences
  38. (or a library like curses to produce those sequences).  Even so, this
  39. may be acceptible, since the big push is for PM-based apps, with the
  40. text-mode only for non-i/o-based apps.
  41.  
  42. >In this case, just get an OS/2 port of a csh of some kind that has job control built-in.
  43. >I know that OS/2 has more types of sessions than UNIX, but without job control in the
  44. >shell, it wouldn't work anyway. If you just run OS/2 text mode aps, I can imagine the
  45. >shell arbitrating console access easily. And running other (PM) jobs from a shell
  46. >does not need BG/FG switching -- being an PM app.
  47.  
  48. As long as each app runs in an independant session, this could be
  49. problematic.  Note that GNU-Emacs gets apps to run in it's own window,
  50. but it must do this by starting the app in a separate session (that
  51. gets a minimized window for itself) and uses pipes (or something) to
  52. redirect the session's output into itself.  A few misplaced Vio*
  53. calls, and the output won't wind up in Emacs.
  54.  
  55. A shell can't use this technique and still be generic enough to run
  56. everything.
  57. -- 
  58.   |)  David Charlap          | .signature confiscated by FBI due to
  59.  /|_  dic5340@hertz.njit.edu | an ongoing investigation into the
  60. ((|,)                        | source of these .signature virusses
  61.  ~|~
  62.