Digamos que tengo algunos directorios:
/Users/user1/ApplicationThing/
/Users/user1/Documents/
/Users/user1/other/directory/it/doesnt/matter/
Digamos que había un archivo main.shen .../ApplicationThing/, que también depende de otro archivo dependancy.sh.
Quiero poder estar en cualquier otro directorio y poder ejecutar main.sh, con su WD como mi CWD, como si el .../ApplicationThing/directorio de contenidos estuviera en cualquier otro directorio del sistema. No como con $PATH, sino como si el contenido estuviera realmente dentro del directorio, pero no debería aparecer en el autocompletado o incluso en ls -l.
Respuesta1
Parece que ApplicationThing debería arreglarse para encontrar sus dependencias desde una ubicación específica, incluso cuando se llama con un directorio de trabajo diferente.
Podrías hacerlo configurando una variable de entorno:
export ApplicationThingHome=/Users/user1/ApplicantionThing
y haciendo referencia a todas las dependencias del main.shuso del valor de esa variable (opcionalmente con un buen valor predeterminado si la variable no está configurada), por ejemplo
${ApplicationThingHome:-/usr/local/ApplicationThingDefaultDir}/dependancy.sh
en lugar de
./dependancy.sh
Luego podrías colocar main.shel directorio $PATHy usarlo desde cualquier directorio.
La solución propuesta tendría un problema: si se encuentra en cualquier otro directorio y desea crear un archivo llamado, digamos, main.sho dependency.shallí, terminaría sobrescribiendo los archivos respectivos de ApplicationThing. Literalmente no podrías tener/usar ningún otro main.shque no sea el que pertenece a ApplicationThing... ¡y los directorios se inventaron precisamente para evitar problemas como ese!
Por supuesto, podría establecer como condición que los "pseudoarchivos" estén allí solo cuando main.shse ejecuten primero... pero luego necesitaría otro conjunto de herramientas para ver lo que main.shve y poder solucionarlo cuando no lo haga. que esperas.
Si no puede arreglar ApplicationThing, puede crear un script contenedor para llamar a ApplicationThing desde cualquier parte del sistema y colocarlo.esoscript en un directorio que está incluido en su $PATH:
#!/bin/sh
# set the correct working directory for silly ApplicationThing
cd /Users/user1/ApplicationThing
# if ApplicationThing has any other environment requirements,
# this would be a great place to ensure they're satisfied too.
# Now execute the main.sh of ApplicationThing, giving it any
# command line arguments that were given to this script, exactly as-is.
exec ./main.sh "$@"
Dado que este script se ejecutará como un proceso separado, el cdcomando en el script no afectará en absoluto la sesión que llama al script. La execpalabra clave al ejecutar main.shevita dejar un proceso adicional entre el shell que llama y el archivo main.sh.
Con este enfoque, si main.shtoma nombres de archivos como parámetros, tendría que proporcionarlos como nombres de ruta absolutos, ya que cualquier nombre de ruta relativo sería interpretado como main.shrelativo al directorio de ApplicationThing, no como relativo al CWD de la sesión de llamada.
Si eso es un problema, puede escribir un preprocesamiento más elaborado para los parámetros de la línea de comando antes de pasarlos a main.sh.Esta pregunta de StackExchangetiene algunas ideas que pueden resultarle aplicables.