¿Dónde hay un buen lugar permanente para instalar scripts de bash personalizados?


32

Estoy a punto de instalar "leiningen", que es una secuencia de comandos bash para el lenguaje de programación clojure con mucha utilidad ... ... pero no estoy seguro de dónde es apropiado ingresar una secuencia de comandos ejecutable en Linux sistema para que esté disponible de forma permanente y estable.

No creo que ningún lugar en / home tenga sentido, pero no sé qué directorio / directorios se deben usar para eso.

/ usr / share?


Respuestas:


45

(Nota: se ~traduce como /home/useren esta publicación)

Personalmente, puse todos mis scripts de sistema personalizados /usr/local/biny todos mis scripts de bash personales ~/bin. Muy pocos programas que instalo se colocan en el /usr/local/bindirectorio, por lo que no está muy abarrotado y ya estaba en la $PATHvariable en la mayoría de mis máquinas.

Para agregar /usr/local/bina la ruta de su sistema (si aún no está allí) agregue esto a /etc/profile:

PATH=$PATH:/usr/local/bin
export PATH

Para agregar ~/bina la ruta de su usuario, agregue esto a ~/.bash_profile:

PATH=$PATH:$HOME/bin
export PATH

A veces, el .bash_profilearchivo predeterminado tendrá una instrucción if que se agregará automáticamente ~/bina $PATHsi existe, así que cree ~/biny abra un nuevo terminal para ver si el suyo ya lo hace.


Los BSD hacen esto por defecto.
Chris S

@Chris: los BSD ponen muchas cosas en / usr / local / bin
Dan Andreatta

¿Cuál es la diferencia entre sus scripts de bash y los scripts del sistema, y ​​hay alguna razón por la que separe los dos?
Hashim

@Hashim No puedo hablar por Trey, por supuesto, pero las herramientas que desarrollas para tus necesidades personales tienden a "graduarse" a las herramientas del sistema cuando notas que resuelven un problema con el que otros están luchando, o tienes otra instalación en todo el sistema que depende en una de estas herramientas. Sospecho que el umbral para instalar algo en todo el sistema es bastante alto para la mayoría de los programadores. Además, una herramienta que comparta debe tener documentación, etc., que muchos desarrolladores rara vez escriben de otra manera.
tripleee

Por otro lado, no hay necesidad de exportuna variable varias veces (y probablemente su sistema ya PATHesté marcado para la exportación, por lo que no tiene que hacerlo usted mismo).
tripleee

9

/ usr / local / es realmente el lugar correcto, mientras que / opt es realmente para aplicaciones de terceros; "/ opt está reservado para la instalación de paquetes de software de aplicación complementarios". Esto es parte del estándar de jerarquía del sistema de archivos.

Consulte http://www.pathname.com/fhs/pub/fhs-2.3.html para obtener más información sobre / opt.

Para / usr / local /, es para "uso por parte del administrador del sistema". Simplemente no te olvides de las cosas allí, documentarlo.


El enlace que proporcionó dice "Los directorios / opt / bin, / opt / doc, / opt / include, / opt / info, / opt / lib y / opt / man están reservados para uso del administrador del sistema local". No hay nada sobre / usr / local. Solo se menciona / usr / local / share allí. Por otro lado, los programas compilados generalmente se instalan en / usr / local en Linux. ¿No crees que / opt / bin es el mejor lugar para que lo use el administrador del sistema?
Raacer

1
@raacer Mi experiencia es que /usr/local, como su nombre lo indica, es para el administrador local y /optpara cosas que no se distribuyen oficialmente, como software comercial de terceros que se gestiona mediante un proceso similar (podría reemplazarse o borrarse en una actualización de upstream) pero no administrado por el administrador de paquetes de la distribución, o tal vez distribuido realmente como RPM o .debpaquetes, pero no organizado y empaquetado de acuerdo con todas las políticas y convenciones de la distribución.
tripleee

1
@raacer Hay una sección separada completamente sobre /usr/localmás adelante en el documento.
tripleee

@raacer tripleee tiene razón. Aquí está el enlace: pathname.com/fhs/pub/… .. programas correctos y compilados (generalmente de código abierto) que se compilan / compilan específicamente para ese sistema o se comparten entre varios sistemas (pero no forman parte del paquete / distribución normal del sistema operativo, pero eso depende en gran medida de las bibliotecas compartidas) debe instalarse en / usr / local (básicamente refleja la jerarquía de / usr). El software de terceros que se compila en un sistema posiblemente diferente con posiblemente su propio soporte de biblioteca (es decir, firefox, userify) debe entrar / opt.
Jamieson Becker

3

Históricamente usarías algo como / opt. Todo está bien siempre que se actualice en $ PATH para los usuarios que se supone que lo tienen (por lo tanto, cualquier cosa en / home es una mala idea).


2

/usr/share/clojureparece un lugar común para colocar los binarios y bibliotecas de clojure, por qué no lo sé, parece natural para ellos /usr/local/share/clojure, por lo que crear un sitesubdirectorio debajo de esto para estos scripts de bash parece estar bien.

El punto general es que tiene más sentido organizar los scripts por función, no tener todos los scripts de bash en el mismo lugar.


1
Hay un par de problemas /usr/sharepara usar esto. En primer lugar, sharesignifica archivos independientes de la arquitectura (es decir, compartidos entre arquitecturas). Por esa razón, las bibliotecas y los ejecutables no pertenecen a un sharedirectorio. En segundo lugar, excepto por /usr/localnada más que el administrador de paquetes de distribución debería escribir /usr.
kasperd

2

/usr/local, Creo que hay algo de confusión en el significado de "local".

Según tengo entendido, "local" no significa "originado en / desde la máquina local" sino, más simplemente, "específico de la máquina local", que puede o no originarse en / desde la máquina local.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.