xterm nenhum caminho absoluto encontrado para shell

2

Estou tentando executar um script no SUSE Linux Enterprise 12 usando java ProcessBuilder . Códigos para isso seguem:

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

então eu leio as mensagens de Process , ele está dizendo xterm: no absolute path found for shell: script_path

Então eu tentei do Gnome-Terminal que tenho no SUSE, e usei os comandos xterm script_path mas encontrei a mesma mensagem de erro. Eu tentei o formulário raiz e do usuário local. Estou completamente fora de pistas sobre esse erro.

E a condição principal é que eu tenho que ser capaz de rodar este código como root, já que meu código java tem que ser chamado apenas como root.

ATUALIZAÇÃO:

Eu tentei novamente e agora realmente tenho uma nova mensagem de erro do ProcessBuilder . A mensagem que recebo do errorstream segue:

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

O script que estou tentando executar é unZipper.sh :

#!/bin/bash
sudo unzip -o postgresql-9.4.6-linux-64.zip -d some_path/db/
sleep 3
    
por ShaDooW 12.03.2016 / 14:32

1 resposta

3

O xterm faz algumas verificações (diferentes) dos nomes de caminhos envolvidos na execução de um comando. Aqui está uma sinopse:

  • se você disser "comando xterm -e", o xterm dependerá da configuração $SHELL existente e / ou da configuração de luit (que também usa $SHELL de uma maneira diferente) para decidir se o comando será ter sucesso.
  • se você disser "comando xterm" (sem -e option), o xterm tratará isso como um caso especial, exigindo que seja um nome de caminho absoluto. É aqui que surge o problema habitual.

Nas alterações do patch # 301 em diante (e com exceção do especial no -e case) xterm verifica o $SHELL existente para garantir que esteja listado em /etc/shells . (Há uma longa história aqui, mas resumir, observando que é uma melhoria na segurança ..). Se você ler o changelog, verá que acertar o processo levou algumas tentativas para lidar com casos especiais.

A partir das informações fornecidas:

  • Como você está usando -e em um caso (do ProcessBuilder) e não no outro, pode haver algum problema lá.
  • Ou o seu $SHELL pode não estar listado em /etc/shells .
  • Finalmente, pode haver alguma configuração de recurso (combinada com variáveis de localidade incorretas) fazendo com que o programa execute luit inesperadamente. Por exemplo, se o xterm tentar usar luit , mas o recurso localeFilter estiver definido como um caminho relativo, isso resultará em erro.
por 12.03.2016 / 15:00