how to avoid blocking side effect of a menu shell command
Tony Balinski
ajbj at free.fr
Tue Aug 31 18:37:07 CEST 2004
Quoting "Jenô Balaskó (IJ/ETH)" <jeno.balasko at ericsson.com>:
> Hi all,
>
> could You help me, please.
> I should execute a command 'xclearcase' from Shell menu.
> I choosed dialog as output.
> Unfortunately the control is blocked by this application until
> it has been finished. Therefore the editing is stopped.
>
> -The usual umpersand-solution xclearcase & doesn't work.
> -To get back the control by pressing Ctrl-. is not user friendly.
> -To open a new window for output instead of dialog is a working solution
> but
> untitled files will opened.
>
> Is there any fancy solution like '&' to get back the control immediately ?
>
> Thanks
> Attila
Two things: firstly there was a problem in this area which was fixed
not so long ago, so I would encourage you to pick up the 5.5 release
candidate if you haven't already done so. (We're up to the second RC.)
Secondly, NEdit decides that it no longer needs to know about a
subprocess when it sees that all file descriptors with which it
communicates with the subprocess are closed. So the thing to do, in
your command, is to redirect the standard input, output and error
streams, eg
( your-command-goes-here ) < /dev/null >& /dev/null &
for csh.
If you use another shell for executing subprocesses (sh, ksh, bash or
whatever), this will not work (upto version 5.4) - that was the bug that
was fixed - because NEdit did not close all unneeded file descriptors
linked to the subprocess. You could make it work by explicitly closing
all file descriptors (maybe using something like
command 0</dev/null 1>/dev/null 2>&1 3>&1 4>&1 5>&1 ... 9>&1
- in sh or its variants - will do it).
Tony
More information about the Discuss
mailing list