Estoy usando MacOSX bash
como mi shell. Tengo un enlace simbólico, creado así:
ln -s /usr/bin/python python2
Tengo un paquete que usa python2 y quiero crear un enlace de símbolo en mi directorio de trabajo actual, /usr/bin/python
que en realidad es python2. Cuando hago un python2
desde la línea de comando me sale este error:
python2: realpath couldn't resolve "/usr/bin/python2"
Pero invocarlo así ./python2
resuelve el camino correctamente. Mi PATH
tiene .
en ello. De hecho, lo modifiqué, para probarlo, para tenerlo solo .
.
¿Cómo resuelvo esto? ¡Gracias!
Contexto
Algunas de las soluciones sugeridas a continuación no funcionarán para mí. Traté de destilar mi pregunta lo más centrada y breve posible para que la gente no se ahogara en un mar de texto, pero claramente necesito proporcionar más antecedentes.
Estoy tratando de desarrollar en un paquete que cloné de git. El paquete original git-multimail
, está / fue desarrollado en alguna variante de Linux (supongo que Ubuntu). He estado tratando de modificarlo para poder usarlo y su conjunto de pruebas en MacOSX con la menor modificación posible. He aquí por qué algunas de las soluciones propuestas no son ideales:
Como root, cree un
python2
enlace simbólico en / usr / bin /. Estoy buscando una solución que no requiera esto. Esta era una opción obvia al principio, pero me gustaría una solución que modifique el sistema host lo menos posible. Es por eso que quería crear un enlace simbólico temporal en el directorio de trabajo actual, agregar el CWD (es decir.
) a mi ruta y luego destruirlo cuando haya terminado (es decir, el enlace simbólico).Cree una secuencia de comandos de contenedor para llamar a la secuencia de comandos de Python con la python existente. El problema con esto es que gran parte del conjunto de pruebas utiliza los archivos de script reales como ejecutables, dependiendo de shebang para encontrar el entorno de ejecución correcto. Esto significaría editar considerablemente el conjunto de pruebas. En este contexto, (vea a continuación un fragmento del marco de prueba), tendría que agregar un contenedor para cada
.py
archivo; Además, el usuario / desarrollador tendría que conocer las diferentes reglas para usar el paquete dependiendo del sistema en el que se encuentren (es decir, en MacOSX asegúrese de no usar los archivos de Python sin invocarlos a través del contenedor o llamar explícitamente/usr/bin/python file.py
).#! /bin/sh D=$(cd $(dirname "$0") && pwd) MULTIMAIL="$D/../git-multimail/git_multimail.py" POST_RECEIVE="$D/../git-multimail/post-receive" TESTREPO=$("$D/create-test-repo") HOME="$D" XDG_CONFIG_HOME="$D" GIT_CONFIG_NOSYSTEM=1 export HOME XDG_CONFIG_HOME GIT_CONFIG_NOSYSTEM cd $TESTREPO test_email() { REFNAME="$1" OLDREV="$2" NEWREV="$3" echo "$OLDREV" "$NEWREV" "$REFNAME" | USER=pushuser "$MULTIMAIL" }
Cambiando todas las
python2
referencias apython
. El archivo README sugiere esto, pero esto efectivamente hace que el control de versión sea inútil ya que el sistema ve el cambio como una nueva versión, cuando en realidad no lo es (semánticamente).
He estado usando (3) pero estoy tratando de encontrar una mejor solución. Estoy dispuesto a aceptar que así son las cosas (es decir, no hay una manera adecuada de señalar 'python2' para /usr/bin/python
que sea portátil y discreto sin muchos cambios en el conjunto de pruebas y el marco real).
git-multimail.py
lo que es #!/usr/bin/env python2
, entonces hay una forma (relativamente) directa de hacer esto.
ln -s /usr/bin/python2.7 /usr/local/bin/python2
hizo
ln -s /usr/bin/python /usr/bin/python2