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 deluit
(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 usarluit
, mas o recursolocaleFilter
estiver definido como um caminho relativo, isso resultará em erro.