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