aaron@ux.acs.umn.edu (Aaron Y.T. Cheung) (10/22/90)
We have:
1. Suns running Sun OS 4.1 and OpenWindows 2.0
2. NCD X-terminals under the control of xdm
Now we want to run the OpenWindows environment (except the NeWS stuffs)
on the X-terminals, and with xdm as the login front end. Most of the
stuffs work except shelltool/cmdtool.
Whenever a cmdtool/shelltool is started from _within_ the Olwm pop up
menu (stuffs from .openwin-menu), it get stucked. A cmdtool/shelltool
window will pop up and what you type will be echoed, but nothing from
the system. I do a "ps ux" from another terminal and see that the
/bin/csh process that was spawned by the shelltool was in T (stopped)
state. I tried "kill -CONT pid" but no good.
If I login to another terminal, "setenv DISPLAY ncd:0; shelltool",
everything works fine.
Actually, I think the same thing happen if I use the olwm/shelltool
distributed by MIT. However, they worked alright back in the days of
Sun OS 4.0.3.
All in all, shelltool/cmdtool (MIT and OpenWindows) screw up when
called up from within Olwm, on Sun OS 4.1.
Any help will be very much appreciated.
PS: Xdm reports the following when the problem occurred:
ttysw-TIOCSPGRP: Interrupted system callmic@ut-emx.uucp (Mic Kaczmarczik) (10/23/90)
In article <2522@ux.acs.umn.edu> aaron@ux.acs.umn.edu (Aaron Y.T. Cheung) writes: >We have: > >1. Suns running Sun OS 4.1 and OpenWindows 2.0 >2. NCD X-terminals under the control of xdm > > Now we want to run the OpenWindows environment (except the NeWS stuffs) >on the X-terminals, and with xdm as the login front end. Most of the >stuffs work except shelltool/cmdtool. I found an answer to this problem last week. The problem is that SunOS 4.1 uses POSIX job control, which changes the way programs need to dissociate themselves from the controlling terminal. Shelltool and cmdtool don't do this quite the way they need to under 4.1; I guess the OpenWindows developers never tried invoking these programs on an X terminal. According to the SunOS 4.1 release notes, the program /usr/etc/setsid can be used as a ``wrapper'' for programs that have this problem; if you change your shelltool/cmdtool invocation to /usr/etc/setsid -b ${OPENWINHOM}/bin/xview/shelltool [args] the problem should go away. On our systems, I even went so far as to make a shell script wrapper for these programs, so I wouldn't have to change any menu files; a shell archive of what I did is enclosed. Enjoy, --mic-- -------------------------------------------------------------------- #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh <file", e.g.. If this archive is complete, you # will see the following message at the end: # "End of shell archive." # Contents: README cmdtool.sh # Wrapped by mic@emx.utexas.edu on Mon Oct 22 13:33:00 1990 PATH=/bin:/usr/bin:/usr/ucb ; export PATH if test -f 'README' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'README'\" else echo shar: Extracting \"'README'\" \(993 characters\) sed "s/^X//" >'README' <<'END_OF_FILE' XDescription: X XIf you want to run cmdtool or shelltool via rsh(1) or from xdm(X11), Xyou need to establish a controlling terminal for the program to dissociate Xthe tty subwindow from. Otherwise, the program reports TIOCSPGRP errors, Xand the doesn't see any keyboard input. X XThe shell script in this directory uses setsid(2V) to establish a terminal Xsession ID for cmdtool/shelltool, which seems to do the trick. At least Xnow I can invoke shelltool from my window manager when logging in via Xxdm. X XInstallation: X XInstalling this hack requires that you move the cmdtool binary somewhere Xother than $OPENWINHOME/bin/xview. I put it in the subdirectory .bin for Xconvenience. X X cp cmdtool.sh $OPENWINHOME/bin/xview # copy the wrapper X mkdir $OPENWINHOME/bin/xview/.bin # create area for real binary X cd $OPENWINHOME/bin/xview/.bin # go there X mv ../cmdtool . # save real cmdtool X mv ../cmdtool.sh cmdtool # replace it with cmdtool.sh X ln -s cmdtool shelltool # remake symlink for shelltool END_OF_FILE if test 993 -ne `wc -c <'README'`; then echo shar: \"'README'\" unpacked with wrong size! fi # end of 'README' fi if test -f 'cmdtool.sh' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'cmdtool.sh'\" else echo shar: Extracting \"'cmdtool.sh'\" \(339 characters\) sed "s/^X//" >'cmdtool.sh' <<'END_OF_FILE' X#!/bin/sh X# X# @(#)cmdtool.sh 1.2 10/16/90 (cc.utexas.edu) /tmp_mnt/usr/share/src/public/sun/fixes/remote-cmdtool/SCCS/s.cmdtool.sh X# X# Wrapper for cmdtool and shelltool that establishes a session leader for X# the process. See setsid(8V) for details. X# Xexec /usr/etc/setsid -b ${OPENWINHOME-/usr/openwin}/bin/xview/.bin/`basename $0` "$@" END_OF_FILE if test 339 -ne `wc -c <'cmdtool.sh'`; then echo shar: \"'cmdtool.sh'\" unpacked with wrong size! fi # end of 'cmdtool.sh' fi echo shar: End of shell archive. exit 0 -- Mic Kaczmarczik gripe@{emx,ix1,ccwf} (Unix consulting, 1-0251) Unix / VMS / Cyber Services ...!cs.utexas.edu!ut-emx!mic (UUCP) UT Austin Computation Center mic@emx.utexas.edu (Internet) mic@utaivc (BITNET)
janssen@parc.xerox.com (Bill Janssen) (10/23/90)
> I found an answer to this problem last week. The problem is that > SunOS 4.1 uses POSIX job control, which changes the way programs need > to dissociate themselves from the controlling terminal. Shelltool and > cmdtool don't do this quite the way they need to under 4.1; I guess > the OpenWindows developers never tried invoking these programs on an X > terminal. I'd be very grateful if someone who knows what the right fixes to the code of cmdtool, Andrew typescript, and xterm are to make them all POSIX-compliant would post said fixes... Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
db@sunbim.be (Danny Backx) (10/24/90)
There have been several messages about the shelltool/cmdtool problem on
X-terminals. There are 2 solutions.
1. Use /usr/etc/setsid.
This involves making a little script that replaces your executable,
and actually calls it. E.g. :
#!/bin/csh -f
/usr/etc/setsid -b /home/openwin/bin/xview/cmdtool $*
[ this is actually Sun's solution - proposed for others than this also]
2. Fix the bug.
The bug is not in cmdtool or shelltool, rather in XView. It can be
found in ${XVIEWSRC}/lib/libxvol/ttysw/tty_init.c . I changed the
stuff around line 580 to look like this :
gotpty:
line[strlen("/dev/")] = 't';
#ifdef POSIX
(void) setsid(); /* For SunOS 4.1 */
#else
tt = open("/dev/tty", O_RDWR);
if (tt > 0) {
(void) ioctl(tt, TIOCNOTTY, 0);
(void) close(tt);
}
#endif
tty = open(line, O_RDWR);
You would have to compile with -DPOSIX in order to get this to work.
Note: read SunOS 4.1 Release Manual (pp. 52-54).
Danny Backx
BIM Networks System Engineer
E-Mail: db@sunbim.be (or uunet!mcsun!ub4b!sunbim!db)
Telephone: +32(2)759.59.25 Fax : +32(2)759.47.95
Postal Mail :
Danny Backx
BIM
Kwikstraat 4
3078 Everberg
Belgium