Saltar al contenido

¿Qué es / usr / local / bin?

Este team de especialistas despúes de varios días de trabajo y de recopilar de datos, hallamos la respuesta, queremos que resulte útil para ti para tu plan.

Solución:

/usr/local/bin es para programas que puede ejecutar un usuario normal.

  • los /usr/local La jerarquía es para que la utilice el administrador del sistema al instalar software localmente.
  • Debe estar a salvo de que se sobrescriba cuando se actualice el software del sistema.
  • Puede usarse para programas y datos que se pueden compartir entre un grupo de hosts, pero que no se encuentran en /usr.
  • El software instalado localmente debe colocarse dentro /usr/local en lugar de / usr a menos que se esté instalando para reemplazar o actualizar el software en /usr.

Esta fuente ayuda a explicar el estándar de jerarquía del sistema de archivos en un nivel más profundo.

Puede encontrar este artículo sobre el uso y abuso de /usr/local/bin interesante también.

/ usr /, supongo que es el usuario de la computadora.

Cerrar.

Unix comenzó como un sistema operativo multiusuario, por lo que no es “el usuario”, es “el usuarios, “plural.

Antes de que AT&T Unix System V Release 4 (SVR4) saliera en 1988 con sus herramientas de administración de usuarios por defecto para crear directorios de inicio de usuarios en /home, la ubicación convencional era /usr.¹ Tu $HOME el directorio podría haber sido /usr/jfw en una caja System III.

/usr también contenía, entonces como ahora, /usr/bin, /usr/lib, etc. La experiencia demostró que segregar los directorios de inicio era una buena práctica de gestión del sistema, por lo que con el /home cambio de política en SVR4, dejó atrás todo lo que ahora consideramos que pertenece a /usr.

/usr Todavía tenía una buena razón para conservar el nombre: lo que se dejó atrás fueron los archivos que no necesitaban estar disponibles hasta que el sistema se iniciara lo suficiente como para admitir el uso interactivo normal. Es decir, lo que quedó atrás fueron los usuario-partes del sistema operativo centradas. Esto quiere decir eso /usr podría estar en un volumen físico diferente, lo cual era algo bueno en los días de unidades de disco duro de 92 MB del tamaño de lavadoras.

Los primeros sistemas Unix tenían cuidado de mantener los archivos centrales del sistema operativo fuera de /usr para que pueda arrancar en modo de usuario único² incluso si el /usr el volumen era imposible de montar por alguna razón. El volumen de la raíz contenía suficientes herramientas para obtener el /usr volumen de nuevo en línea.

Varias versiones de Unix ahora ignoran este antiguo principio de diseño, ya que incluso los sistemas integrados pequeños tienen suficiente espacio para los archivos de volumen raíz tradicionales y todo /usr en un solo volumen.³ Enlace simbólico de Red Hat Enterprise Linux, Solaris y Cygwin /bin para /usr/bin y /lib para /usr/lib para que ya no exista ninguna diferencia entre estos directorios.

… / local / … obviamente representa la computadora local …

Si. Se refiere al hecho de que los archivos bajo /usr/local se supone que son particulares de ese único sistema. Los archivos que sean de alguna manera genéricos deberían residir en otro lugar.

Esto también tiene sus raíces en la forma en que los sistemas Unix se usaban comúnmente hace décadas cuando todo esto estaba estandarizado. Una vez más, los discos duros de la época eran voluminosos, realmente caros y se almacenaban poco para los estándares actuales. Para ahorrar dinero y espacio en los discos, un laboratorio de computación lleno de cajas Unix a menudo compartiría la mayor parte de /usr a través de NFS o algún otro protocolo de intercambio de archivos de red, por lo que cada caja no tenía que tener su propia copia redundante. Los archivos específicos de una sola caja irían debajo /usr/local, que sería un volumen separado de /usr.

Esta herencia histórica es la razón por la que sigue siendo el predeterminado para que la mayoría del software Unix de terceros se instale en /usr/local cuando se instala a mano. La mayoría de este tipo de software le permitirá instalar el paquete en otro lugar, pero al no hacer una elección, obtendrá el valor predeterminado seguro, que no interfiere con otras ubicaciones de instalación comunes con propósitos más específicos.

Hay buenas razones para instalar el software en otro lugar. El equipo macOS de Apple hace esto cuando crea, digamos, bash del código fuente de GNU Bash. Ellos usan / como la instalación prefix, anulando el /usr/local predeterminado, por lo que Bash termina en /bin.

Otro ejemplo es la forma en que los sistemas Linux más antiguos segregaban su software GUI en /usr/X11R6, para mantenerlo separado de la línea de comando tradicional y cursessoftware basado en. Esto se hizo simplemente anulando el valor predeterminado /usr/local prefix con /usr/X11R6.⁵

¿Y qué es / bin?

Es la abreviatura de “binario”, que en este contexto significa “un archivo que no es texto sin formato”. La mayoría de estos archivos son ejecutables en una caja de Unix, por lo que estos dos términos se han convertido en sinónimos en algunos círculos. (“Por favor, compáreme un binario para RHEL 7, Fred”).

Los archivos de texto en una caja de Unix viven en otro lugar: /etc, /usr/include, /usr/shareetc.

Érase una vez, incluso los scripts de shell, que son archivos de texto sin formato, se mantuvieron fuera de bin directorios, pero esta línea también se ha difuminado. Hoy dia, bin Los directorios suelen contener cualquier tipo de archivo ejecutable, ya sea estrictamente “binario” o no.


Notas al pie y digresiones:

  1. La naturaleza primitiva de las herramientas de gestión de usuarios anteriores a SVR4 significaba que el HOME=/usr/$NAME El esquema se documentó simplemente como una convención, en lugar de imponerse mediante herramientas de software de forma predeterminada.

    Puede ver esto en la página 4-8 de la “Guía del administrador del sistema AT&T Unix System V versión 3.2: aquí puede ver AT&T recomendando el antiguo /usr/$NAME esquema en la última versión principal de Unix antes de que saliera SVR4.

    Era bastante común en los sistemas Unix más antiguos que los administradores del sistema eligieran un esquema diferente que tuviera más sentido para ellos. Siendo personas personas, eso significó que se inventaron muchos esquemas diferentes.

    Un esquema que encontré antes /home/$NAME se convirtió en el estándar fue /u/$NAME.

    Otro sistema que usé a principios de la década de 1990 tenía tantos usuarios que no podían encajar todos los directorios de inicio en un solo volumen físico, por lo que usaron un esquema como /u1/$NAME, /u2/$NAME, y así sucesivamente, según recuerdo. En qué disco terminó su directorio personal fue simplemente una cuestión de cuál tenía espacio en el momento en que se creó su cuenta.

  2. Puede iniciar una caja de macOS en modo de usuario único manteniendo presionado Cmd-S mientras arranca. Suéltelo una vez que la pantalla se vuelva negra y vea que aparece un texto gris claro. Es como ejecutar debajo de la Terminal, pero ocupa toda la pantalla porque la GUI aún no se ha iniciado.

    Ten cuidado, estás corriendo como root.

    Escriba “salir” en el indicador raíz de usuario único para salir del modo de usuario único y continuar iniciando en modo GUI de usuario múltiple.

  3. Sistemas operativos Unixy que todavía aparecer para mantener los archivos críticos del modo de usuario único fuera de /usr puede que, de hecho, no lo haga en estos días. Una vez hice que una caja de FreeBSD 9 no se pudiera arrancar moviendo /usr a un volumen ZFS. Olvidé que las características de ZFS-on-root no aterrizaron hasta FreeBSD 10, creando un Catch 22: el sistema operativo necesitaba archivos en /usr para montar /usr!

    Eso ya era bastante malo, pero si FreeBSD 9 todavía mantuviera su material de arranque de un solo usuario fuera de /usr, Podría haberlo arreglado en su lugar. Dado que no arrancaría ni siquiera en modo de usuario único con /usr siendo imposible de montar, claramente esa tradición había sido violada de alguna manera. Tuve que arrancar desde un CD de rescate para recuperar ese sistema.

  4. Aquí también es donde obtenemos /usr/share: segrega archivos que podrían compartirse (por ejemplo, a través de NFS) incluso entre cajas Unix con diferentes tipos de procesadores. Normalmente, archivos de texto: páginas de manual, diccionario, etc.

  5. “X11R6” se refería a la versión del sistema X Window que sustentaba las GUI de Linux en el momento en que prevalecía esta convención. Los sistemas Linux generalmente dejaron de segregar el software GUI cuando se reemplazó X11R6 por X.Org.

  6. Los sistemas Unix originales mantuvieron sus scripts de shell centrales en /etc para evitar mezclarlos con el true binarios en /bin.

/usr/local/bin muestra las raíces de UNIX-esque del último Mac OS (su BSD se basa allí).

  • “usr” significa recursos del sistema UNIX. Esta es la ubicación donde se almacenan los programas del sistema y las bibliotecas.
  • “local” representa los recursos que no se enviaron con la distribución estándar y, por lo general, se compilan y mantienen por sitio.
  • “bin” representa ejecutables compilados en binario.

Esto se ha transformado desde las primeras implementaciones de UNIX a Linux y BSD, pero la convención se ha mantenido. Ahora, /usr/bin sería para programas y bibliotecas “principales” o centrales donde /usr/local/bin sería para bibliotecas y programas complementarios y no críticos.

Si posees algún contratiempo o capacidad de perfeccionar nuestro reseña eres capaz de realizar una interpretación y con deseo lo analizaremos.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *