0

when I execute this script the terminals are opening and immediately closing, so I can't see the result.

Nothing that I know helps.

I'm using SunOS 5.9 and it's not my fault))

#!/bin/bash

if [ -z "$1" ]; then 
echo "enter command"
fi

if [ -z "$2" ]; then 
echo "enter command"
fi

if [ -z "$3" ]; then 
echo "enter command"
fi

xterm -e $1 | wait & 

xterm -e $2 | wait & 

xterm -e $3 | wait &
Masha Misery
  • 69
  • 1
  • 7

2 Answers2

1

The -hold option was added to XFree86 xterm in 1999 (patch 116). However, Sun continued to provide the "openwin" binary of xterm until Solaris 11 in 2011 (see the xterm FAQ Why can't I use the pageup/pagedown keys?). Until that point, Sun provided modern xterm on the freeware CDROM.

The usual recommendation for providing a "hold" feature involved a "read" command after the desired command. That assumes that the command to be executed runs in a shell. If one wants to run vi, the suggested fix does not work because the alternate screen may be involved. Also, it relies on having $SHELL set (and does not work for some, such as tcsh -- but does work for bash).

Here is an improved script which solves those problems:

#!/bin/bash
export SHELL=/bin/bash
while [ $# != 0 ]
do
    CMD="$1" \
    xterm -xrm '*titeInhibit:true' -e $SHELL -c '$SHELL -c "$CMD"; read'
    shift 1
done

All versions of xterm support the -xrm switch (it comes for free with Xt, the X Toolkit library).

The explicit titeInhibit resource addresses a problem with running full-screen applications such as vi. The terminal description provided for xterm in Solaris 11 uses the alternate screen for full-screen applications. This is discussed in the xterm FAQ Why doesn't the screen clear when running vi?. Without the resource setting, if one ran the script to vi several files, the screen would be cleared after exiting vi and while waiting for the user to press Enter to close the window. On other systems where this behavior is not the default, the xterm- or ncurses-sources have been patched to reflect packager's preferences. Likewise, the terminfo source for Solaris 9 had been patched. Nonetheless, failing to handle a commonly used behavior of xterm would be a problem.

Even with Solaris 9, for example, many users relied on ncurses to provide a workable color terminal description. Solaris (as noted in the xterm FAQ What $TERM should I use?) provided xtermc, but its function-keys were completely different from the actual xterm, making it a poor choice. The Sun freeware cdrom's terminfo (from ncurses) was not patched; people using that terminal database got the expected behavior with the alternate screen.

Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105
0

Assuming that you want to see what the command produced even if it failed, replace your commands with:

xterm -xrm '*hold: true' -e $1 &   # this is to keep xterm from closing
pid1=$!  # this is to save the pid, in case you want to close it
disown   # this is to prevent the finishing shell from closing the xterm

Alternatively, if the xterm does not support -xrm option:

CMD="$1" xterm -e $SHELL -c '$SHELL -c "$CMD"; read'

The two shells are to protect from syntax errors in the command, to keep the xterm open even in this case.

fork0
  • 3,401
  • 23
  • 23
  • Your xterm might be a strange thing which does not support `-xrm`. You may look into pausing the shell, which runs the command. I'll update the answer – fork0 Jul 26 '12 at 14:50
  • Both parts of the answer have problems (answer uses a feature of xterm not provided with Solaris 9, as well as suggesting an alternate solution which does not actually work). – Thomas Dickey Apr 01 '15 at 22:36
  • @ThomasDickey what part of the alternate solution does not work with Solaris 9? – fork0 Apr 06 '15 at 12:05
  • It did not work for applications that switch to the alternate screen of xterm. – Thomas Dickey Apr 06 '15 at 20:29
  • @ThomasDickey: hm. As you can see, the alternative solution is very straightforward in what it does. There is a problem with proper quoting of the shell metacharacters in $CMD (which is frankly easier to work around than fix), but aside from that I fail to see what these applications might need which the solution does not provide. And you're not exactly helping with analysis. What exactly does not work? – fork0 Apr 14 '15 at 20:02