Antes de hoy, he usado el terminal hasta cierto punto para moverme dentro y fuera de los directorios y cambiar las fechas de los archivos usando el comando touch
. Me di cuenta de la extensión completa de la terminal después de instalar un script divertido en Mac y tener que chmod 755
el archivo para hacerlo ejecutable después.
Me gustaría saber qué /usr/local/bin
es, sin embargo. /usr/
, Supongo, es el usuario de la computadora. No estoy seguro de por qué /local/
está ahí, sin embargo. Obviamente significa la computadora local, pero dado que está en la computadora (o en un servidor), ¿sería realmente necesario? No /usr/bin
¿estar bien?
Y lo que es /bin
? ¿Por qué esta área se usa generalmente para instalar scripts en el terminal?
/usr/local/bin
es para programas que puede ejecutar un usuario normal.
/usr/local
la jerarquía es para uso del administrador del sistema al instalar software localmente./usr
./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.
Cerca.
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 predeterminadas 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 un cuadro Sistema 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 administración del sistema, por lo que con el /home
cambio de política en SVR4, dejó todo lo que ahora pensamos que pertenece a /usr
.
/usr
todavía tenía una buena razón para conservar el nombre: lo que quedó atrás fueron los archivos que no necesitaban estar disponibles hasta que el sistema se inició lo suficientemente lejos como para admitir el uso interactivo normal. Es decir, lo que quedó atrás fueron las usuario - partes enfocadas del sistema operativo. Esto quiere decir eso /usr
podría estar en un volumen físico diferente, lo que fue bueno en los días de 92 MB de unidades de disco duro del tamaño de las lavadoras .
Los primeros sistemas Unix tuvieron cuidado de mantener los archivos principales del sistema operativo fuera de /usr
para poder seguir arrancando en modo de usuario único² incluso si el /usr
el volumen no se podía montar por alguna razón. El volumen raíz contenía suficientes herramientas para obtener el /usr
volumen de nuevo en línea.
Varios sabores de Unix ahora ignoran este antiguo principio de diseño, ya que incluso los pequeños sistemas integrados tienen suficiente espacio para los archivos de volumen raíz tradicionales y todos /usr
en un solo volumen.³ Red Hat Enterprise Linux, Solaris y Cygwin symlink /bin
a /usr/bin
y /lib
a /usr/lib
para que ya no haya ninguna diferencia entre estos directorios.
.../local/... obviamente significa la computadora local ...
Si. Se refiere al hecho de que los archivos bajo /usr/local
se supone que son particulares de ese sistema único. Los archivos que son genéricos deben vivir en otro lugar.
Esto también tiene 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 de Unix a menudo compartiría la mayor parte de /usr
a través de NFS o algún otro protocolo de red para compartir archivos, por lo que cada cuadro no tenía que tener su propia copia redundante. Los archivos específicos de un solo cuadro irían bajo /usr/local
, que sería un volumen separado de /usr
.
Esta herencia histórica es la razón por la cual sigue siendo el valor predeterminado para la mayoría de los software de Unix de terceros para instalar en /usr/local
cuando se instala a mano. La mayoría de estos programas le permitirán instalar el paquete en otro lugar, pero al no elegir, obtiene el valor predeterminado seguro, que no interfiere con otras ubicaciones de instalación comunes con fines más específicos.
Hay buenas razones para hacer que el software se instale en otro lugar. El equipo macOS de Apple hace esto cuando construyen, digamos, bash
del código fuente GNU Bash . Ellos usan /
como prefijo de instalación, anulando el /usr/local
predeterminado, para que Bash termine en /bin
.
Otro ejemplo es la forma en que los sistemas Linux más antiguos segregaron su software GUI en /usr/X11R6
, para mantenerlo separado de la línea de comandos tradicional y el software basado en curses
. Esto se hizo simplemente anulando el valor predeterminado /usr/local
prefijo 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 un cuadro de Unix, por lo que estos dos términos se han convertido en sinónimos en algunos círculos. ("Por favor, constrúyeme un binario para RHEL 7, Fred").
Los archivos de texto en un cuadro de Unix viven en otro lugar: /etc
, /usr/include
, /usr/share
, etc.
Érase una vez, incluso los scripts de Shell, que son archivos de texto sin formato, se mantuvieron fuera de los directorios bin
, pero esta línea también se ha desdibujado. Hoy en día, los directorios bin
generalmente contienen cualquier tipo de archivo ejecutable, ya sea estrictamente "binario" o no.
Notas al pie y digresiones :
La naturaleza primitiva de las herramientas de administración de usuarios anteriores a SVR4 significaba que el HOME=/usr/$NAME
el esquema se documentó simplemente como una convención, en lugar de que las herramientas de software lo aplicaran de forma predeterminada.
Puede ver esto en la página 4-8 de " AT&T Unix System V Release 3.2 Guía del administrador del sistema : aquí puede ver que AT&T recomienda el viejo /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 de sistemas eligieran un esquema diferente que tuviera más sentido para ellos. Ser personas, eso significaba que se inventaron muchos esquemas diferentes.
Un esquema que encontré antes /home/$NAME
se convirtió en el estándar era /u/$NAME
.
Otro sistema que usé a principios de la década de 1990 tenía tantos usuarios que no podían ajustar todos los directorios principales en un solo volumen físico, por lo que usaron un esquema como /u1/$NAME
, /u2/$NAME
, y así sucesivamente, según recuerdo. El disco en el que terminó su directorio de inicio fue simplemente una cuestión de cuál tenía espacio en el momento en que se creó su cuenta.
Puede iniciar un cuadro de macOS en modo de usuario único manteniendo presionado Cmd-S mientras arranca. Suelta una vez que la pantalla se vuelva negra y veas aparecer un texto gris claro. Es como correr bajo la Terminal, pero ocupa toda la pantalla porque la GUI aún no ha comenzado.
Tenga cuidado, está ejecutando como root
.
Escriba "exit" en el indicador raíz de usuario único para salir del modo de usuario único y continuar arrancando en el modo GUI multiusuario.
Sistemas operativos Unixy que todavía ¡aparecen para mantener los archivos críticos en modo de usuario único fuera de /usr
puede que, de hecho, no lo haga en estos días. Una vez hice que un cuadro de FreeBSD 9 no se pueda iniciar moviendo /usr
a un volumen ZFS. Olvidé que las características de ZFS en la raíz no llegaron 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 mantenía su arranque de usuario único fuera de /usr
, Podría haberlo arreglado en su lugar. Dado que no arrancaría incluso 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 que el sistema volviera a funcionar.
Aquí también es donde obtenemos /usr/share
: segrega archivos que podrían compartirse incluso entre cajas Unix con diferentes tipos de procesadores. Típicamente, archivos de texto: páginas man, el diccionario, etc.
"X11R6" se refería a la versión de X Window System apuntalando 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 X11R6 fue reemplazado por X.Org .
Los sistemas Unix originales mantuvieron sus scripts principales de Shell en /etc
para evitar mezclarlos con los verdaderos binarios en /bin
.
/usr/local/bin
muestra las raíces UNIX-esque del último Mac OS (su BSD está basado allí).
Esto se ha transformado desde las primeras implementaciones de UNIX para 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 programas y bibliotecas complementarias y no críticas.
Recomendaría consultar Wikipedia para preguntas relacionadas con la estructura en general, cubrirá los conceptos básicos.
Sin embargo, para responder su pregunta directamente:
Es por eso que tiendes a encontrar una estructura similar entre los dos;/usr/{, local /} {bin, sbin, lib}. Al ser nuevo en Shell, esa parte de {} es una expansión de Shell. Intenta ejecutar
ls -ld /usr/{,local/}{bin,sbin,lib}
de su Shell local para ver cómo funciona.
/usr/local/bin
es la ubicación predeterminada más popular para los archivos ejecutables, especialmente los de código abierto.
Sin embargo, esto podría decirse que es una mala elección ya que, en sistemas Unix, /usr
se ha estandarizado a principios de los noventa para contener una jerarquía de archivos que pertenecen al sistema operativo y, por lo tanto, pueden ser compartidos por múltiples sistemas que utilizan ese sistema operativo.
Como estos archivos son estáticos, el /usr
el sistema de archivos se puede montar de solo lectura. /usr/local
está derrotando este estándar, ya que es por diseño local, por lo tanto no compartido, por lo que debe ser de lectura-escritura para permitir la compilación local y no es parte del sistema operativo. Lástima que algo como /opt/local
no fue elegido en su lugar ...
Te recomiendo que uses /usr/local
para programas comerciales que puede instalar, como Mathematica. Colóquelo en su propia partición cuando configure. Cuando actualice su sistema operativo, esta partición no se verá afectada y no tendrá que volver a instalar su contenido. Así que úselo para cosas que desea mantener entre las actualizaciones del sistema operativo.
Por separado, asegúrese de dar /home
su propia partición por este motivo también.
Esta respuesta también puede ser útil.
La idea original detrás de /usr/local
debía tener un directorio separado ('local') '/ usr' en cada máquina además de /usr
, que podría montarse solo lectura desde otro lugar. Copia la estructura de /usr
.
Estos días, /usr/local
es ampliamente considerado como un buen lugar para mantener programas autocompilados o de terceros. Los /usr/local
la jerarquía es para uso del administrador del sistema al instalar software localmente. Es necesario evitar que se sobrescriba cuando se actualiza el software del sistema.
Se puede usar para programas y datos que se comparten entre un grupo de hosts, pero no se encuentran en /usr
. El software instalado localmente debe colocarse dentro de /usr/local
más bien que /usr
a menos que se esté instalando para reemplazar o actualizar el software en /usr
.