uri(7) Miscellaneous Information Manual uri(7) NOMBRE uri, url, urn - identificador uniforme de recursos (URI), incluido un URL o URN SINOPSIS URI = [ absoluteURI | relativeURI ] [ "#" fragment ] absoluteURI = scheme ":" ( hierarchical_part | opaque_part ) relativeURI = ( net_path | absolute_path | relative_path ) [ "?" query ] scheme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" | "file" | "ftp" | "man" | "info" | "whatis" | "ldap" | "wais" | ... hierarchical_part = ( net_path | absolute_path ) [ "?" query ] net_path = "//" authority [ absolute_path ] absolute_path = "/" path_segments relative_path = relative_segment [ absolute_path ] DESCRIPCION Un identificador uniforme de recursos (URI) es una cadena de caracteres corta que identifica un recurso abstracto o fisico (por ejemplo, una pagina web). Localizador de Recursos Uniforme (URL) es un URI que identifica un recurso por su mecanismo de acceso primario (por ejemplo, su ubicacion de), antes que por su nombre o algun otro atributo del recurso. Un Nombre de Recurso Uniforme (URN) es un URI que debe ser globalmente unico y permanecer aun cuando el recurso deja de existir o pasa a ser inaccesible. Los URI son la forma estandar de nombrar los destinos de los hiperenlaces para herramientas tales como los navegadores web. La cadena "http://www.kernel.org" es un URL (y tambien un URI). Algunas personas usan el termino URL unicamente como sinonimo de URI (aunque tecnicamente URLs son parte de los URI). Los URI pueden ser absolutos o relativos. Un identificador absoluto se refiere a un recurso independiente del contexto, mientras que un identificador relativo apunta a un recurso a traves de las diferencias del contexto actual. Dentro de una referencia a una ruta relativa, los segmentos de ruta completos "." y ".." tienen significados especiales: "el nivel jerarquico actual" y "el nivel superior a este nivel jerarquico", respectivamente, Tal y como lo hacen los sistemas al estilo UNIX. Un segmento de ruta que contiene el caracter ":" no puede ser usado como el primer segmento de ruta relativa URI (por ejemplo, "esto:aquello"), porque seria erroneo para el esquema de nombres. Preceda tales segmentos con ./ ((por ejemplo "./esto:aquello"). Advierta que los descendientes de MS-DOS (por ejemplo, Microsoft Windows) reemplazan los dos puntos de los nombres de dispositivo con la barra vertical ("|") en URI, por lo que "C:" se convierten en "C|". Un identificador de fragmento, si es incluido, se refiere a una porcion particular identificada (fragmento) de un recurso. El texto despues de un '#' identifica al fragmento. Un URI que comience con '#' se refiere al fragmento del recurso actual. Modo de empleo Hay diferentes esquemas URI, cada uno con reglas y significados adicionales, pero intencionadamente se hacen tan similares como sea posible. Por ejemplo, muchos esquemas URL permiten que la autoridad tenga el siguiente formato, llamado aqui un servidor_ip (los corchetes muestran que es opcional): servidor_ip = [usuario [ : contrasena ] @ ] host [ : puerto] Este formato te permite opcionalmente insertar un nombre de usuario, una contrasena y/o un numero de puerto. El host es el nombre del ordenador que hace de anfitrion, y su nombre se puede determinar mediante su DNS o una direccion IP (numeros separados por puntos). Por lo que el URI se introduce en el servidor web del anfitrion example.com como fred (usando fredcontrasena) usando el puerto 8080. Evite incluir contrasenas en un URI si es posible debido a los muchos riesgos para la seguridad que supone tener un password escrito. Si el URL facilita el nombre de usuario, pero no la contrasena, y el servidor remoto pide la contrasena, el programa que interpreta el URL debe requerir una del usuario. Aqui hay algunos de los esquemas mas comunes usados por sistemas al estilo UNIX, los cuales son comprendidos por muchas aplicaciones. Advierta que algunas aplicaciones usan URI y tambien tienen esquemas internos o esquemas especializados. Vea en esas aplicaciones la documentacion para informarse sobre esos esquemas. http - Servidor (HTTP) Web http://servidor_ip/ruta http://servidor_ip/ruta?cuestion Esto es un URL accediendo a un servidor (HTTP) Web. El puerto por defecto es 80. Si la ruta se refiere a un directorio, el servidor web elegira que devolver. Normalmente, si existe un fichero llamado "index.html" o "index.htm" sera mostrado, en otro caso, se devuelve una lista de los ficheros del directorio actual (con los enlaces apropiados). Un ejemplo es . Una pregunta se puede dar en el formato obsoleto "isindex", constituido por una palabra o frase y no incluyendo un signo igual(=). Una peticion tambien se puede dar en un formato mas largo "GET", el cual tiene una o mas peticiones de entrada para el formulario variable=valor separadas por el caracter ampersand (&). Advierta que variable puede ser repetida mas de una vez, piense que son el servidor web y sus aplicaciones los encargados de determinar si tiene significado. Existe una interaccion desafortunada entre HTML/XML/SGML y este formato. Cuando tales URI con mas de una variable se insertan en un documento SGML/XML (incluyendo HTML), el ampersand (&) es reescrito como &. Advierta que no todas las preguntas tienen este formato. Formatos mas largos puede que sean demasiado largos para ser almacenados como una URI, por lo que usan un mecanismo interactivo diferente llamado POST, el cual no incluye los datos en el URI. Vease la especificacion del "Common Gateway Interface" en para mas informacion. ftp - Protocolo de Transferencia de Ficheros (FTP) ftp://servidor_ip/ruta Este es un URL de acceso a ficheros a traves del protocolo de transferencia de ficheros (FTP). El puerto por defecto (para control) es el 21. Si no se incluye un nombre de usuario, se introduce el usuario llamado "anonymous", y en ese caso algunos clientes dan como contrasena su direccion de correo electronico. Un ejemplo es . gopher - servidor Gopher gopher://servidor_ip/selector tipogopher gopher://servidor_ip/selector tipogopher%09search gopher://servidor_ip/selector tipogopher%09search%09gopher+_cadena El puerto por defecto es el 70. tipogopher es un campo de un solo caracter que indica el tipo de recurso Gopher al que se refiere el URL. La ruta entera tambien puede estar vacia, y en tal caso el delimitador "/" es tambien opcional, siendo el tipogopher por defecto "1". selector es la cadena de seleccion Gopher. En el protocolo Gopher, las cadenas de seleccion Gopher son una secuencia de octetos que pueden contener cualquier octeto excepto el 09 en hexadecimal (US-ASCII HT o tab), 0A en hexadecimal (US-ASCII caracter LF) y 0D (US-ASCII caracter CR). mailto - direccion de correo mailto:direccion_de_correo Esto es una direccion de correo electronico, normalmente de la forma nombre@nombrehost. Vease mailaddr(7) para mas informacion acerca del formato correcto de la direccion de correo electronico. Advierta que cualquier caracter % debe ser reescrito como %25. Un ejemplo es . news - Grupo de noticias o Mensaje de noticias news:nombre-gruponoticias news:identificador-mensaje Un nombre-gruponoticias es un nombre jerarquico delimitado por puntos, tal como "comp.infosystems.www.misc". Si es "*" (como ), se usa para referirse a "todos los grupos de noticias disponibles". Un ejemplo es . Un identificador-mensaje corresponde a Message-ID de IETF RFC 1036, sin encerrarlo entre "<" y ">". Toma la forma unico@nombre_completo_dominio. Un identificador de mensaje puede ser distinguido de un nombre de grupo de noticias por la presencia del caracter "@". telnet - sesion Telnet telnet://servidor_ip/ El esquema de una URL de telnet se usa para designar servicios de texto interactivos a los que se puede acceder a traves del protocolo Telnet. El caracter final "/" se puede omitir. El puerto por defecto es el 23. Un ejemplo es . file - Fichero normal file://servidor_ip/ruta file:ruta Esto representa un fichero o directorio que se puede acceder localmente. Como caso especial, servidor_ip puede ser la cadena "localhost" o una cadena vacia. Esto se interpreta como `la maquina desde la que el URL esta siendo interpretado'. Si la ruta es hacia un directorio, el visor deberia mostrar el contenido del directorio con enlaces a cada uno de los contenidos. Actualmente, no todos los visores hacen esto. KDE suporta ficheros generados a traves del URL . Si no se encuentra el fichero indicado, los escritores de visualizadores pueden querer el intentar expandir el nombre del fichero mediante comodines (vea glob(7) y glob(3)). El segundo formato (por ejemplo, ) es correcto para referirse a archivos locales. Sin embargo, los estandares mas antiguos no permitian este formato, y algunos programas no lo reconocen como un URI. Una sintaxis mas portable es usar una cadena vacia como nombre del servidor, por ejemplo, . Esto hace lo mismo y es mas sencillo de reconocer para las expresiones regulares y los programas mas antiguos como un URI. Advierta que si lo que realmente quiere decir es "comienza desde la posicion actual," no especificas todo el esquema. En cambio, usa la direccion relativa como <../test.txt> que tiene el efecto colateral de ser independiente del esquema. Un ejemplo de este esquema es . man - paginas man de documentacion man:nombre-orden man:nombre-orden(seccion) Esto se refiere a las paginas de referencia en linea del manual local. El nombre de la orden opcionalmente puede ir precedido por un parentesis y un numero de seccion. Vease man(7) para mas informacion sobre el significado de los numeros de seccion. Este modelo URI es unico en los sistemas tipo UNIX (como Linux) y actualmente no esta registrado por la IETF. Un ejemplo es . info - Documentacion en paginas info info:nombrefichero-virtual info:nombrefichero-virtual#nombrenodo info:(nombrefichero-virtual) info:(nombrefichero-virtual)nombrenodo Este esquema hace referencia a las paginas de referencia en linea del sistema info (generadas a partir de ficheros texinfo), un formato de documentacion usado por programas tales como las herramientas GNU. Este modelo URI es unico en los sistemas tipo UNIX (tales como Linux) y actualmente no esta registrado por el IETF. En el momento de escribir esto, GOME y KDE difieren en sus sintaxis URI y no aceptan la sistaxis del otro. Los primeros dos formatos son el formato de GNOME. Todos los espacios en los nombres de los nodos se escriben como subrayados. Los otros dos formatos son el formato de KDE. Los espacios en los nombres de los nodos se escriben como espacios, aunque esto esta prohibido por los estandares URI. Se espera que en un futuro la mayoria de las herramientas comprendan ambos formatos y que acepten subrayados para los espacios en los nombres de los nodos. Tanto en GNOME como en KDE, si se usa la forma sin el nombre de nodo, se asume "Top" como nombre de nodo. Ejemplos del formato de GNOME son y .Ejemplos del formato de KDE son y . whatis - busqueda de documentacion whatis:cadena Busca en la base de datos de descripciones cortas (una linea) de ordenes y devuelve una lista con las descripciones que contienen esa cadena. Solo se muestran coincidencias de palabras completas. Vease whatis(1). Este esquema URI es unico en los sistemas al estilo UNIX (tales como Linux) y actualmente no esta registrado por el IETF. ghelp - documentacion de ayuda de GNOME ghelp:ghelp: nombre-de-aplicacion Carga la ayuda de GNOME para la aplicacion dada. Dese cuenta que actualmente no existe mucha documentacion en este formato. ldap - Protocolo Ligero de Acceso a Directorios ldap://hostport ldap://hostport/ ldap://hostport/dn ldap://hostport/dn?attributes ldap://hostport/dn?attributes?scope ldap://hostport/dn?attributes?scope?filter ldap://hostport/dn?attributes?scope?filter?extensions Este esquema soporta consultas al protocolo LDAP (Lightweight Directory Access Protocol), un protocolo para consultar a un conjunto de servidores sobre informacion organizada jerarquicamente (como personas y recursos del equipo). Puede encontrar mas informacion sobre el esquema URL para LDAP en RFC 2255 Los componentes de esta URL son: hostport el servidor LDAP a consultar, escrito como un nombre de anfitrion seguiro por dos puntos y un numero de puerto. El puerto LDAP por omision es el puerto TCP 389. Si no se indica, el cliente determina que servidor LDAP usar. dn el Nombre LDAP Distinguido, que identifica el objeto base de la busqueda LDAP (vea RFC 2253 seccion 3). attributes una lista de atributos, separados por comas, a devolver. Vea RFC 2251 seccion 4.1.5. Si se omite, se deberian devolver todos los atributos. scope especifica el ambito de la busqueda, que puede ser "base" (para una busqueda de objetos base), "one" (para una busqueda de un nivel) o "sub" (para una busqueda de subarbol). Si se omite el ambito, se asume "base". filter especifica el filtro de la busqueda (subconjunto de entradas a devolver). Si se omite, se deberian devolver todas las entradas. Vea RFC 2254 seccion 4. extensions Una lista de parejas tipo=valor, separadas por comas, donde la porcion =valor se puede omitir para opciones que no la necesiten. Una extension prefijada con un '!' es critica (debe estar soportada para ser valida), en otro caso no es critica (opcional). Las consultas LDAP son mas faciles de explicar mediante ejemplos. Aqui tiene una consulta que pide a ldap.itd.umich.edu informacion sobre la Universidad de Michigan en los EE.UU.: ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US Para obtener simplemente su atributo de direccion postal, pregunte: ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress Para pedir informacion a host.com en el puerto 6666 sobre la persona de nombre comun (common name, cn) "Babs Jensen" de la Universidad de Michigan, pregunte: ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen) wais - Wide Area Information Servers (Servidores de Informacion de Area Amplia) wais://hostport/database wais://hostport/database?search wais://hostport/database/wtype/wpath Este esquema designa a una base de datos, busqueda o documento WAIS (vea IETF RFC 1625 para obtener mas informacion sobre WAIS). Hostport es el nombre del anfitrion, seguido opcionalmente por dos puntos y un numero de puerto (el numero de puerto por omision es 210). La primera forma designa a una base de datos WAIS en la que buscar. La segunda forma designa una busqueda particular en la base de datos WAIS database. La tercer forma designa un documento particular a recuperar dentro de una base de datos WAIS. wtype es una designacion WAIS del tipo del objeto y wpath es el identificador de documento WAIS. Otros formatos Existen muchos otros esquemas URI diferentes. La mayoria de las herramientas que aceptan URI, tambien soportan un conjunto de URI internos (por ejemplo, Mozilla tiene el esquema about: para informacion interna, y el navegador de ayuda de GNOME tiene el formato toc: para diversas localizaciones de comienzo. Hay muchos esquemas que han sido definidos, pero que actualmente no se usan de forma amplia. (por ejemplo, prospero). El esquema nntp: esta en desuso en favor del esquema news:. Las URNs van a ser soportadas por el esquema urn:, con un espacio de nombres jerarquico (por ejemplo, urn:ietf:... identificaria documentos IETF). En este momento, las URNs no estan ampliamente implementadas. No todas las herramientas soportan todos los esquemas. Codificacion de caracteres Las URI usan un numero limitado de caracteres que pueden ser tecleados y usados multitud de situaciones. Los siguientes caracteres son reservados, es decir, pueden aparecer en un URI, pero su uso esta limitado a su proposito especifico (los datos conflictivos deben ser precedidos por una caracter de escape antes de formar el URI): ; / ? : @ & = + $ , Los caracteres no reservados se pueden incluir en un URI. Los caracteres no reservados incluyen las letras del alfabeto latino en mayusculas y minuscula, los digitos, y el siguiente conjunto de marcas de puntuacion y simbolos: - _ . ! ~ * ' ( ) Los demas caracteres se deben preceder con caracteres de escape. Un octeto con escape se codifica como un caracter triple, constituido por el caracter de porcentaje "%" seguido de dos digitos hexadecimales que representan el codigo del octeto (puede usar letras mayusculas y minusculas para los digitos hexadecimales). Por ejemplo, un espacio en blanco se debe representar como "%20", el caracter tabulador como "%09", y el "&" como "%26". Ya que el caracter de porcentaje siempre tiene el proposito reservado de comenzar una secuencia de escape, se debe representar como "%25". Es una practica comun indicar los caracteres de espacio con el simbolo (+) en frases para consulta. Esta practica no esta definida de forma concisa en los RFCs relevantes (los cuales recomiendan %20 en su lugar) pero cualquier aplicacion que reciba URI deberia estar preparada para ellos. Un URI siempre se muestra en su forma "de escape". Los caracteres no reservados se pueden escapar sin cambiar la semantica de la URI, pero esto no se deberia hacer a menos que la URI se este usando en un contexto que no permite que aparezcan caracteres sin escapar. Por ejemplo, se usa "%7e" en lugar de "~" en una ruta HTTP URL pero las dos son equivalentes para una URL HTTP. Para las URI que deban manejar caracteres fuera del conjunto de caracteres US ASCII, la especificacion HTML 4.01 (seccion B.2) y el IETF RFC 3986 (ulitmo parrafo de la seccion 2.5) recomiendan lo siguiente: (1) traducir las secuencias de caracteres a UTF-8 (IETF RFC 3629)--consulte utf-8(7) --y a continuacion (2) usar el mecanismo de escape URI, es decir, usar la codificacion %HH para octetos problematicos. Escritura de URI Cuando son escritos, las URI deberian introducirse entre comillas (por ejemplo, "http://www.kernel.org"), encerrados entre <> (por ejemplo, ), o situados en una linea solos. Una advertencia para aquellos que usan comillas dobles: nunca mueva simbolos de puntuacion que no pertenezcan a la URI (tales como el punto y final de una frase o la coma en una lista) dentro de ella, ya que esto cambiara su valor. En lugar de eso, use "<>", o cambie a un sistema de notacion para no incluir nunca en el caracteres extranos. Este ultimo sistema, llamado el 'nuevo' o 'logico' sistema de entrecomillado mediante "Las reglas de Hart"y el "Diccionario Oxford para Ecritores y Editores", se considera una buena practica en Gran Bretana y en varios idiomas europeos. Algunos documentos mas antiguos sugerian anadir el prefijo "URL" justo antes de la URI, pero esta solucion nunca llego a adoptarse mayoritariamente. La sintaxis URI se diseno para que no fuera ambigua. Ademas, como las URI se han convertido en un lugar comun, los medios tradicionales (television, radio, periodicos, vallas publicitarias, etc.) han incrementado el uso de referencias abreviadas URI formadas solo por la autoridad y partes de la ruta del identificativo del recurso (por ejemplo, ). Tales referencias son principalmente entendidas por la interpretacion humana mas que por las maquinas, asumiendo que el estudio del contexto es suficiente para completar el URI (es decir, nombres de host que comiencen por "www" son como tener un prefijo URI "http://" y los host que comiencen con "ftp" usualmente tendran un prefijo "ftp://"). Algunas implementaciones de clientes resuelven heuristicamente estas referncias. Tales heuristicas pueden cambiar con el tiempo, particularmente cuando se introduzcan nuevos esquemas. Ya que un URI abreviado tiene la misma sintaxis que una ruta URL relativa, la referencia URI relativa no se puede usar donde los URI relativos son permitidos, y solo se pueden usar cuando no hay una base definida (como en cuadros de dialogo). No use URI abreviados como enlaces de hipertexto dentro de un documento. Use el formato estandar como se describe aqui. ESTANDARES (IETF RFC 2396) , (HTML 4.0) . NOTAS Algunas herramientas de un sistema Linux que aceptan URI (por ejemplo, un navegador) deberian ser capaces de manejar (directa o indirectamente) todos los esquemas aqui descritos, incluyendo los esquemas man: e info:. Manejarlos invocando otros programas esta bien, y de hecho es lo apropiado. Tecnicamente el fragmento no es parte del URI. Para informarse sobre como incrustar URI (incluidos URLs) en formato de datos, vease la documentacion sobre ese formato. HTML usa el formato texto . Los archivos Textinfo usan el formato @uref{uri}. Man y mdoc han anadido recientemente la macro UR, o simplemente incluyendo el URI en el texto (los visores deben ser capaces de detectar :// como parte de un URI). Los gestores de escritorio KDE y GNOME actualmente varian en los URI que aceptan, en particular en sus respectivos navegadores de ayuda. Para listar las paginas del manual, GNOME usa mientras que KDE usa (el autor de esta pagina prefiere el sistema KDE mostrado aqui, aunque un formato mas regular seria mejor). En general, KDE usa como prefijo para un conjunto de ficheros generados. KDE prefiere la documentacion en formato HTML, siendo accedida a traves de . GNOME prefiere el esquema ghelp para almacenar y encontrar documentacion. Ningun navegador maneja referencias de tipo file: a directorios en el momento de crear este documento, haciendo dificil la referencia a entradas de directorio con un navegador URI. Como se ha indicado antes, estos entornos difieren sobre como manejar el esquema info:, probablemente es la mayor diferencia. Se espera que GNOME y KDE converjan a un mismo formato URI, y en el futuro esta pagina describira el resultado de esa convergencia. Los esfuerzos para ayudar a esta convergencia son admirables. Seguridad Un URI no posee por si mismo un tratamiento de seguridad. No hay garantia general de que un URI, que en un tiempo localizo un recurso dado, continue haciendolo. Ni hay ninguna garantia de que tal URL no localizara un recurso diferente pasado un tiempo. Tal garantia solo se puede obtener de la(s) persona(s) que mantiene(n) el nombre y el recurso en cuestion. A veces es posible construir un URL tal que al intentar realizar una operacion aparentemente inofensiva, como la recuperacion de una entidad asociada con el recurso, se produzca una posible operacion remota peligrosa. El URL no seguro se construye tipicamente especificando un numero de puerto distinto del reservado por el protocolo de red en cuestion. El cliente, inconscientemente contacta con un sitio que de hecho esta ejecutando un protocolo diferente. El contenido del URL contiene instrucciones que, cuando son interpretadas de acuerdo con este otro protocolo, causan una operacion inexperada. Un ejemplo ha sido el uso de un URL gopher para enviar, a traves de un servidor SMTP, un mensaje no intencionado o anonimo. Se deberia llevar cuidado cuando se usa un URL que especifica un numero de puerto diferente del que viene por defecto para el protocolo, especialmente cuando se trata de un numero dentro del espacio reservado. Se deberia andar con precaucion cuando se usa un URI que contiene delimitadores de escape para un protocolo dado (por ejemplo, los caracteres CR y LF para protocolos de telnet) ya que no son decodificados antes de la transmision. Esto puede violar el protocolo, pero evita el peligro de que algunos caracteres sean usados para simular una operacion o parametro extra en ese protocolo, el cual puede que conduzca a que se lleve a caba una inesperada y posiblemente danina operacion. Es claramente una mala idea el uso de un URI que contenga una contrasena, la cual es -supuestamente- secreta. En particular, el uso de una contrasena con el componente 'userinfo' de un URI esta muy desaconsejada excepto en el infrecuente supuesto de una contrasena para uso publico. ERRORES La documentacion puede estar situada en variedad de lugares, por lo que actualmente no es un buen esuqema URI para la documentacion en linea de ambito general con diferentes formatos. Referencias de la forma no funcionan porque distribuciones diferentes y requisitos de instalacion locales diferentes puede que situen los archivos en directorios diferentes (puede ser en /usr/doc, o /usr/local/doc, o /usr/share, o cualquier otro sitio). Ademas, el directorio ZZZ normalmente cambia con la version. Por ultimo, usar el esquema file: no es sencillo para las personas que cargan documentacion dinamica de Internet (en lugar de cargar ficheros en un sistema de archivos local). Un futuro URI puede ser anadido (por ejemplo "userdoc:") para permitirle a los programas incluir referencias cruzadas a documentacion con mas detalle sin tener que saber la posicion exacta de dicha documentacion. Alternativamente, una version futura de la especificacion del sistema de ficheros puede que especifique suficientemente las localizaciones de los ficheros para que el esquema file: sea capaz de encontrar la documentacion. Muchos programas y formatos de ficheros no incluyen una forma de incorporar o implementar enlaces usando URI. Algunos programas no pueden manejar todos los formatos URI. Deberia haber un mecanismo estandar, para cargar un URI, que automaticamente detectara el entorno del usuario (por ejemplo, texto o grafico, entorno de escritorio, preferencias de usuario local, y herramientas que se ejecutan actualmente) y que invocara la herramienta adecuada para cualquier URI. VEASE TAMBIEN lynx(1), man2html(1), mailaddr(7), utf-8(7) IETF RFC 2255 TRADUCCION La traduccion al espanol de esta pagina del manual fue creada por Angel Bueno Pardo , Juan Piernas , Miguel Perez Ibars y Marcos Fouces Esta traduccion es documentacion libre; lea la GNU General Public License Version 3 o posterior con respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD. Si encuentra algun error en la traduccion de esta pagina del manual, envie un correo electronico a . Paginas de manual de Linux 6.06 31 Octubre 2023 uri(7)