O Domingo 26 Abril 2009 19:07:08 Camaleón escribiu:
El 2009-04-26 a las 17:21 +0200, Karl García Gestido escribió:
O Domingo 26 Abril 2009 00:45:58 Camaleón escribiu:
El 2009-04-25 a las 22:10 +0200, Carlos E. R. escribió:
¿Contra qué regla va, concretamente?
La de que /usr va antes que /opt.
No lo veo por aquí:
http://www.pathname.com/fhs/pub/fhs-2.3.html
¿Tienes algún enlace o conoces algún manual donde se defina el orden y las prioridades que se debe seguir en el orden de la definición de las rutas para estar conforme a la norma?
No conozco esa restricción y en el manual de bash tampoco lo encuentro.
No sé si está escrito en algún lado, pero la del sentido común debería ser suficiente. Tal vez no se use mucho, pero eso es otra cuestión... XDD
Supongo que lo que pretenden evitar con el FSH es precisamente que cada cual haga sus propias interpretaciones utilizando "su sentido común". Es al revés, lo que se ve es que la gente lo que no usaba era "su sentido común" para interpretar lo que establecía la FSH.
Dicho de alguna forma, es lógico suponer que la ruta de las aplicaciones del sistema/distribución se antepongan a las de terceros, ¿no?
Pues no lo sé, por eso lo preguntaba.
Teniendo en cuenta que el usuario puede definir sus propias rutas de búsqueda, y suponiendo que el orden tenga que estar definido de una manera concreta para no romper nada, sería interesante leer información al respecto.
Es lo que se deriva de la jerarquía.
Y eso es lo que me gustaría ver documentado.
En los libros que tengo no pone nada y tampoco lo logro encontrar por la web.
Saludos,
-- Camaleón Bueno, cuando decimos aquí que el sistema debería apoyar el trabajo del administrador (tanto Carlos como tú estáis incluso porque se primen determinadas características de facilidad, recuerdo próxima lo del rm -rf que hablamos en otro lado), así que lo lógico es que el sistema anteponga sus rutas a las del usuario, y que luego éste si quiere cambiar esto pues que lo haga.
De alguna forma, el software "de terceros" en teoría es un poco menos fiable que el del sistema (vale, no hace falta que discutamos, esto es "en teoría" ;) ). Las distribuciones que incluyeron KDE e incluso GNOME en /opt plantean un interesante problema en las rutas. Veamos: $ echo $PATH /home/karl/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin Vale, eso es porque añadí mi ruta con PATH=/home/karl/bin:$PATH, mal hecho XDD Vemos que de alguna forma tenemos la ruta de las aplicaciones de la máquina local, las comunes a los usuarios, las del sistema, las del sistema gráfico (la diferencia de /usr/bin y /usr/X11R6/bin hoy por hoy es testimonial, pero el mundo ganaría si las aplicaciones gráficas estuviesen en su sitio ¡no todos usamos el modo gráfico como entorno principal!!) y después kde3 (KDE 4 ya está correctamente definido en /usr. Por cierto, leí por ahí sobre los distintos nombres y ubicaciones, y es que el cambio de /opt a /usr no es para que no se mezclen, es para poner KDE 4 donde debería haber estado siempre (igual que antes se hizo con GNOME). Se mantiene KDE 3 en /opt "por compatibilidad" sea lo que sea lo que signifique). En esta regla, añadir /home/karl/bin al principio responde al paradigma, pero una aplicación, digamos por ejemplo google-earth, que como en este caso ni siquiera tiene por qué tener una carpeta "bin", debería ir al final. Podemos verlo de otra forma. Una carpeta de /opt (dicho ya antes que ni GNOME ni KDE encajan en esa carpeta) es poco probable que contenga muchos ejecutables, no usa una carpeta "bin" general (algo como /opt/bin). Finalmente, si tú instalas un programa en /opt, digamos /opt/chapucero, y añades su correspondiente carpeta "bin" /opt/chapucero/bin, podrías encontrarte que algún gracioso puso una herramienta llamada "ls" que no es la que ninguno de los usuarios del sistema se espera. Naturalmente, no dice mucho de que instales software cerrado en /usr ;) Salud!! -- O malo da relixión e a súa carenza de imaxinación -- karl -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org