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
$SHELLexistente e / ou da configuração deluit(que também usa$SHELLde uma maneira diferente) para decidir se o comando será ter sucesso. - se você disser "comando xterm" (sem
-eoption), 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
-eem um caso (do ProcessBuilder) e não no outro, pode haver algum problema lá. - Ou o seu
$SHELLpode 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
luitinesperadamente. Por exemplo, se o xterm tentar usarluit, mas o recursolocaleFilterestiver definido como um caminho relativo, isso resultará em erro.