¿Cuál es la forma correcta de solicitar una función en GNU Linux?

Estoy tratando de enviar un informe de error para el archivo de la aplicación, / usr / bin / file

Pero consultando al hombre y enviando un correo electrónico

ERRORES Informe de errores y envíe parches al rastreador de errores en http://bugs.gw.com/ o la lista de correo en ⟨file@mx.gw.com⟩ (visite http://mx.gw.com/mailman/ lista de información / archivo primero en suscribirse).

Me hizo descubrir que la dirección de correo no existe.

¿Hay otra forma de comunicarse con la comunidad? Esperemos que esta pregunta ya sea parte de ella :)

Así que aquí está mi correo electrónico:

posible fallo de la función: la --extensionopción no parece mostrar nada

$ file --extension "ab.gif" 
ab.gif: ???

Sería útil poder utilizar fácilmente la salida de este para cambiar el nombre de un archivo a su extensión correcta.

algo como el archivo --likely_extensionsolo generaría la extensión detectada probable o un error si la detección fuera demasiado baja

así así:

$ file --likely_extension "ab.gif"
gif

mejor aunque sería una --correct_extensionopción:

$ file --correct_extension "ab.jpg"

$ ls
ab.gif

Tyvm para esta aplicación :)

Está siguiendo el procedimiento correcto para presentar un problema o una solicitud de mejora: si la documentación de un programa menciona cómo hacerlo, siga esas instrucciones.

Desafortunadamente, a menudo sucede que los proyectos mueren o que las instrucciones en la versión que tienes ya no son precisas. En estos casos, las cosas se ponen un poco más difíciles. Un posible enfoque general es presentar un error con su distribución; Sin embargo, el éxito puede ser bastante impredecible ... (Debo mencionar que generalmente es mejor informar un error a la distribución de la que obtuvo su paquete, si está usando un paquete; esto es especialmente cierto si está empaquetado la versión es anterior a la versión actual "ascendente", y si no ha verificado si el problema todavía está presente allí).

Para fileconcretamente, la documentación oficial se ha actualizado para mencionar que el seguimiento de errores y lista de distribución se han reducido, y también proporciona una dirección de correo electrónico directo para el mantenedor actual, que se puede utilizar para ponerse en contacto con él.

Además de la respuesta de Stephen Kitt , puede considerar (especialmente si usted mismo es un desarrollador y si el programa, fileen su caso, tiene un código fuente que no es demasiado difícil de entender), obtener el código fuente de ese programa (quizás de su distribución), ya que es software libre , y lo parchea, y también envía un parche.

Si se toma el tiempo de estudiar el código fuente , probablemente obtendrá un mejor informe de errores.

Si toma más tiempo para proponer un parche de reparación , es probable que lo consideren más en serio (y en mi humilde opinión, está actuando más en el espíritu del software libre).

Entonces, use la libertad que proporciona el software libre : estudie su código fuente (libertad # 1) y mejórelo (libertad # 3).

Hoy es muy fácil publicar (por ejemplo, en github ) su versión mejorada y compartirla (libertad # 2).

Asegúrese de tener la última versión del fileprograma. Muchas distribuciones no usan eso (y tal vez el error en su distribución ya se ha solucionado).

No estoy seguro de que su --correct_extensioncomportamiento pertenezca file(que es un programa para consultar , no cambiar, sus datos). Pero si lo hace, probablemente debería escribirse --correct-extensiono --rename-extension... Y una vez que intente implementar eso, puede descubrir que hay casos extraños en las esquinas (¿qué pasa con un archivo tar comprimido, un archivo fuente C comprimido o algo que podría necesita varias extensiones de archivo).

Tenga en cuenta que (al contrario de Windows) en Linux y Unix, un archivo es en realidad un inodo (vea inodo (7) ) y puede tener varios nombres (o ninguno), y puede ser abierto por varios procesos a la vez (lea sobre los descriptores de archivo ) - o ninguno, incluso si la mayoría de los archivos tienen un solo nombre (pero vea el enlace (2) y stat (2) ). Dado que se podría nombrar el mismo archivo foo.txty bar.gzno tiene mucho sentido dar importancia a las extensiones de archivo. Ver también path_resolution (7) .

Entonces, si intentas implementar tu correct-extensionidea, descubrirás que no es tan fácil de implementar (e incluso especificar), y que no existe un comportamiento simple obvio para eso.

Probablemente, su idea no es muy buena y no puede implementarse fácilmente en sistemas Linux y POSIX (al menos, no en todos los casos).

Por lo tanto, recomiendo evitar incluso enviar una solicitud de función (en su forma inicial, es una pérdida de tiempo para usted y para los desarrolladores de file). O bien, trabaje mucho en ello, mejore sus especificaciones y envíe un parche ... Por supuesto, dedicará mucho trabajo a eso (y realmente no creo que valga la pena).

Quizás también lea algún libro de programación de Unix (como el antiguo ALP , o algo nuevo; y también intro (2) & syscalls (2) ) y Sistemas operativos: tres piezas fáciles .

Usted pregunta:

¿Cuál es la forma correcta de solicitar una función en GNU Linux?

y para responder eso, es importante saber que no existe algo como "GNU Linux", per se. El Proyecto GNU es un esfuerzo de colaboración para desarrollar software libre. Parte de ese software libre, junto con grandes cantidades de otro software gratuito y de código abierto, es recolectado por otros proyectos: ya sea colaborativos, proyectos abiertos como Fedora * o Debian, o esfuerzos corporativos con diversos grados de apertura, o incluso individuos. Estas colecciones se llaman "Distribuciones de Linux" o "Distribuciones de GNU / Linux" (hay un debate político allí en el que no entraré).

En general, si está interesado en la mejora de funciones , lo mejor que puede hacer es trabajar con el desarrollador que escribió el software: las distribuciones tienen mucho trabajo que hacer para recopilar los diversos programas y hacer que funcionen juntos, y normalmente se prefieren aquellos cambios que suceda "aguas arriba".

Entonces, hizo lo correcto aquí: encontró la fuente ascendente documentada e intentó informar allí.

Sin embargo, parece que los métodos de comunicación documentados para el software que le interesa no funcionan. En ese caso, tiene varias opciones:

1. Intente encontrar otras formas de contactar a los desarrolladores del software. En este caso, la mayoría de las distribuciones incluyen el filecomando originalmente escrito por Ian Darwin y alojado nominalmente en http://www.darwinsys.com/file/ , con las listas de correo que ha mencionado. Pero al igual que esas listas de correo, el sitio principal parece estar inactivo. Hoy en día, verificar GitHub es un buen segundo paso, y encontré https://github.com/file/file , que dice Espejo de solo lectura del repositorio CVS de archivos, actualizado cada media hora. NOTA: no haga solicitudes de extracción aquí, ni comente ninguna confirmación, envíelas de manera habitual al rastreador de errores o a la lista de correo. Eso no es inmediatamente útil, pero noto que no tienenha habido cambios en ese repositorio en la última semana. Entonces, un posible próximo movimiento es ver quién hizo esos compromisos y contactarlos.
2. Puede preguntarle a la persona responsable del paquete en la distribución que usa. Para fileen Fedora, vea esta página . Dado que trabajan con el software regularmente, pueden tener otros medios para contactar con el proveedor. Dependiendo de la distribución, esto se logra mejor mediante la presentación de un error o por contacto directo: es necesario conocer la cultura individual. (En Fedora, sugeriría la lista de correo de desarrollo ).
3. Si está utilizando una distribución comercial, como Red Hat Enterprise Linux *, puede presentar un ticket de soporte. Como cliente que paga, puede influir en su proveedor para encontrar una solución.
4. Si todo lo demás falla, el proyecto que le interesa podría estar muerto río arriba . En ese caso, puede "bifurcar" el proyecto: cree su propia versión y cree una nueva comunidad ascendente a su alrededor. Si su versión se mantiene y la otra está muerta, es probable que las distribuciones sigan.

* Yo trabajo en Fedora. Y estoy empleado por Red Hat.

Este es un error en su distribución. Si la distribución está enviando páginas de manual que están desactualizadas, debe presentar un error contra el paquete que lo proporcionó. Si está utilizando Debian, puede usar una herramienta como reportbug para simplificar esto.

identify -format %m file.gif[0]

Formato de archivo de imagen% m (archivo mágico)

El [0] significa el primer fotograma, lo que podría ayudar si lo usa accidentalmente en un video, ya que de lo contrario usa las bibliotecas ffmpeg para hacer una copia temporal de cada fotograma.

Esto solo funciona para imágenes. No sé cómo hacerlo para archivos genéricos. ffmpeg devuelve 'avc1' para un archivo mp4 aleatorio (otros archivos mp4 pueden devolver cadenas diferentes, y aún debe analizarlo), y no veo una manera de pasar de eso a 'mp4'. 'avc1' no está en ningún lugar en / usr / share / mime.

ffmpeg, o equivalentemente ffprobe, enumera algunos formatos de archivo que el demuxer usa al comienzo de su salida. Para un archivo mp4 dice

Entrada # 0, mov, mp4, m4a, 3gp, 3g2, mj2, desde. . .
[. . .]
Video: h264 (Principal) (avc1 / 0x31637661)

por un png dice

Entrada # 0, png_pipe, de. . .
[. . .]
Video: png, rgb24 (pc)