Problemas para configurar PATH para Java en Debian

Estoy tratando de hacer que la actualización 3 de Oracle Java 7 funcione correctamente en Debian 6. He descargado y configurado los archivos /usr/java/jre1.7.0_03. También he establecido las siguientes dos líneas al final de /etc/bash.bashrc:

export JAVA_HOME=/usr/java/jre1.7.0_03
export PATH=$PATH:$JAVA_HOME/bin

Iniciar sesión como otros usuarios y root está bien, Java se puede encontrar:

chris@mc:~$ java -version
java version "1.7.0_03"
Java(TM) SE Runtime Environment (build 1.7.0_03-b04)
Java HotSpot(TM) 64-Bit Server VM (build 22.1-b02, mixed mode)

Sin embargo, hay dos casos en los que Java no se puede encontrar como se detalla a continuación. Tenga en cuenta que ambos funcionaron bien cuando anteriormente instalé OpenJDK Java 6 a través de aptitude, pero necesito Oracle Java 7 por varias razones.

1. Lo más importante, no puedo ejecutar comandos como otro usuario a través su, a pesar de que la RUTA muestra que Java debería estar presente. El usuario fue creado conadduser chris

   root@mc:~# su chris -c "echo $PATH"
   /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/java/jre1.7.0_03/bin:/bin
   root@mc:~# su chris -c "java -version"
   bash: java: command not found
   root@mc:~# su chris -c "/usr/java/jre1.7.0_03/bin/java -version"
   java version "1.7.0_03"
   ...
   

   ¿Cómo puede estar en el PATHpero no se puede encontrar? Actualización 05/04/2012: explicada por Daniel, que tiene que ver con que es un shell no interactivo para que los archivos como /etc/profiley /etc/bash.bashrcno se ejecuten. Hacer un intercambio completo a ese usuario y ejecutar Java funciona:

   root@mc:~# su chris
   chris@mc:/root$ java -version
   java version "1.7.0_03"
   ...
   

2. Ejecuto un script en el inicio que muestra problemas similares pero ligeramente diferentes. El script se encuentra en /etc/init.d/start-mystuff.shy llama a un jar:

   #!/bin/bash
   # /etc/init.d/start-mystuff.sh
   java -jar /opt/Mars.jar
   

   Puedo confirmar que el script se ejecuta al inicio y que el código de salida es 127, lo que indica que no se encontró el comando. Insertar una línea para imprimir / guardar los PATHprogramas que es:

    /sbin:/usr/sbin:/bin:/usr/bin
   

   Este segundo problema no es tan importante porque puedo señalar directamente el ejecutable de Java en el script, ¡pero todavía tengo curiosidad!

He intentado configurar el completo PATHy JAVA_HOMEexplícitamente en el /etc/environmentque no ayudó. También he intentado configurarlos en los /etc/profileque tampoco parece ayudar. He intentado iniciar y cerrar sesión de nuevo después de configurar PATHen varias ubicaciones (¡duh!).

De todos modos, una publicación larga para lo que probablemente tendrá una solución simple de una línea :( Cualquier ayuda con esto sería muy apreciada, he pasado demasiado tiempo tratando de solucionarlo por mí mismo.

Motivación

El primer problema puede parecer oscuro, pero en mi sistema tengo usuarios a los que no se les permite el acceso SSH pero todavía quiero ejecutar procesos como ellos. Tengo un montón de scripts que funcionan de esta manera y no quiero tener que cambiarlos todos.

Ver: alternativas de actualización

Además: Debian generalmente desalienta a los desarrolladores que confían en las variables ENV, usted ha descubierto una razón por la cual.

No es que sean tabú, es solo que no se debe esperar que siempre estén disponibles.

Nota: Agregar su ruta java al final de la ruta existente significa que cualquier otra java se encontrará y usará primero.

(es decir, el (enlace simbólico) en / usr / bin)

entonces:

ls -lah /usr/bin/java

dice:

lrwxrwxrwx 1 root root 22 abr 22 2011 / usr / bin / java -> / etc / Alternatives / java

file $(which java)

/ usr / bin / java: enlace simbólico a `/ etc / Alternatives / java '

file /etc/alternatives/java

/ etc / alternativas / java: enlace simbólico a `/ usr / lib / jvm / java-6-openjdk-i386 / jre / bin / java '

** <problema secundario> y también sirve para demostrar por qué $ (exec en estilo subshell) es preferible, a "modo de ejecución de retroceso" o "evaluar esto".

((como `` '' y "" se vuelve demasiado confuso, al menos para mí, y no siempre funciona como se espera en todos los shells todo el tiempo. Investigue el modo POSIX AKA / bin / sh))

</ problema secundario> **

man update-alternatives explica por qué existe este sistema alternativo ...

mientras tanto

update-alternatives --config java 

puede ayudar.

/ usr / local / es un buen lugar para instalar paquetes de origen ...

También hay otras formas de pelar a tu gato.

Incluso:

• mano re-apuntando el enlace / usr / bin / java :)

(aunque ten cuidado con las actualizaciones o las instalaciones de dependencia que lo restablecen ... no es una gran opción pero funciona)

• establecer un alias para java por usuario [1]

• anteponiendo $ PATH en los usuarios .bashrc

(puede obtener .bashrc de .bash_profile si lo desea)

• llamando a las versiones específicas ruta completa por instancia

(apuesta más segura pero probablemente no práctica)

[1] .alias o .bashrc

help alias

(Es un bash incorporado)

Finalmente un ejemplo para bien o para mal: tomado de mi Debian .bash_profile ...

# include .bashrc if it exists

if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
    PATH=~/bin:"${PATH}"
fi

Espero que esto ayude en lugar de obstaculizar

Pete

Muchas preguntas de una vez, pero:

1. Lo haces

# su chris -c "echo $PATH"

Esto sustituirá la variable $PATHantes de ejecutar el comando, lo que dará la $PATHraíz for. Tratar

# su chris -c "echo $HOME"

para ver a qué me refiero.

En cambio, puedes hacer

# su chris -c 'echo $PATH'

lo que impedirá que el shell expanda la variable en el primer caso, y en su lugar obtendrá chris's $PATH. Lo más probable es que descubras que los cambios no han penetrado en ese usuario.

¿Por qué no entonces? /bin/shestá vinculado a los /bin/dashsistemas Debian, y no /bin/bash. Dash no leerá /etc/bash.bashrc. Quizás obtuviste Dash como shell predeterminado para el usuario chriscuando fue creado. Mire /etc/passwdpara ver si este es el caso.

Quizás esto aclare también la pregunta 2.

ACTUALIZACIÓN: Ah, /etc/bash.bashrcsolo se lee para shells interactivos. Lea la man bashsección "ARCHIVOS". No inicia un shell interactivo cuando lo usa sude esa manera.

Actualización 2: este ejemplo es de una manera:

# su chris -c 'myvar="hi there"; echo $myvar'
hi there

o similarmente:

# su chris -c 'export myvar="hi there"; echo $myvar; export | grep myvar'
hi there
declare -x myvar="hi there"

(con export, la variable está disponible para subprocesos generados también, como de costumbre).

Puedes usar

sudo -u <user> -i 

que leerá .bashrc/ .bash_profile.