I am trying to run a script in SUSE Linux Enterprise 12 from java using ProcessBuilder. Codes for this follows:

ProcessBuilder pb = new ProcessBuilder("xterm", "-e", "script_path");
Process pr = pb.start();

then I read the messages from Process, it is saying xterm: no absolute path found for shell: script_path

So I tried from the Gnome-Terminal I have in SUSE, and used the commands xterm script_path but found the same error message. I tried both form root and from local user. I am completely out of clues about this error.

And the main condition is I have to able to run this code as root as my java code has to be invoked as root only.


I have tried again and now I actually have a new error message from the ProcessBuilder. The message I get from the errorstream follows:

error extracting:: error message: Warning: This program is an suid-root program or is being run by the root user. 
The full text of the error or warning message cannot be safely formatted in this environment. 
You may get a more escriptive message by running the program as a non-root user or by removing the suid bit on the executable. 
xterm: Xt error: Can't open display: %s
xterm: DISPLAY is not set

The script I am trying to execute is unZipper.sh:

sudo unzip -o postgresql-9.4.6-linux-64.zip -d some_path/db/
sleep 3
  • What does xterm -v say? – Thomas Dickey Mar 12 '16 at 13:39
  • in ProcessBuilder or in the terminal? – ShaDooW Mar 12 '16 at 13:40
  • In the terminal. That would show the version of xterm. – Thomas Dickey Mar 12 '16 at 13:42
  • @thomas X.Org 7.7.0(308) – ShaDooW Mar 12 '16 at 13:42
  • The $DISPLAY variable is a different question (and has been asked several times). – Thomas Dickey Mar 12 '16 at 14:44

xterm makes a few (different) checks for the pathnames involved in executing a command. Here is a synposis:

  • if you say "xterm -e command", xterm will rely upon your existing $SHELL setting and/or the configuration of luit (which also uses $SHELL in a different way) to decide if the command will succeed.
  • if you say "xterm command" (no -e option), xterm treats that as a special case, requiring that it is an absolute pathname. This is where the usual problem arises.

In changes from patch #301 onward (and except for the special no -e case) xterm checks the existing $SHELL to ensure that it is listed in /etc/shells. (There's a long story here, but summarize by noting that it's an improvement in security..). If you read the changelog, you can see that getting it right took a few tries to handle special cases.

From the information given:

  • Since you're using -e in one case (from ProcessBuilder) and not in the other, there may be some problem there.
  • Or your $SHELL may not be listed in /etc/shells.
  • Finally, there could be some resource setting (combined with incorrect locale variables) causing the program to execute luit unexpectedly. For instance, if xterm tries to use luit but the localeFilter resource is set to a relative path, that would give this error.
  • 1
    my $SHELL is /bin/bash and it is in /etc/shells included. btw, I have updated my ques as I have a new error message. – ShaDooW Mar 12 '16 at 14:44
  • The usual practice is to start a new question if the information is not a clarification of the original question. – Thomas Dickey Mar 12 '16 at 14:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.