Qual è il modo corretto di richiedere una funzione in GNU Linux?

Sto cercando di inviare una segnalazione di bug per il file dell'app, / usr / bin / file

Ma consultare l'uomo e inviare una mail

BUG Si prega di segnalare i bug e inviare patch al tracker dei bug all'indirizzo http://bugs.gw.com/ o alla mailing list all'indirizzo ⟨file@mx.gw.com⟩ (visitare http://mx.gw.com/mailman/ listinfo / file prima di abbonarsi).

Mi ha fatto scoprire che l'indirizzo e-mail non esiste.

Esiste un altro modo di comunicare alla comunità? Spero che questa domanda qui sia già parte di essa :)

Quindi ecco la mia email:

possibile errore della funzione: l' --extensionopzione non sembra produrre nulla

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

Sarebbe utile poter facilmente utilizzare l'output di questo per rinominare un file nella sua estensione corretta.

qualcosa come file --likely_extensionprodurrebbe l'estensione probabilmente rilevata o un errore se il rilevamento fosse troppo basso

come così:

$ file --likely_extension "ab.gif"
gif

meglio sarebbe --correct_extensionun'opzione:

$ file --correct_extension "ab.jpg"

$ ls
ab.gif

Tyvm per questa app :)

Stai seguendo la procedura corretta per presentare un problema o una richiesta di miglioramento: se la documentazione di un programma menziona come farlo, segui queste istruzioni.

Sfortunatamente capita spesso che i progetti muoiano o che le istruzioni nella versione che hai non siano più accurate. In questi casi, le cose diventano un po 'più difficili. Un possibile approccio generale è quello di presentare un bug con la tua distribuzione; il successo può essere piuttosto incostante ... (Devo dire che di solito è meglio segnalare un bug alla distribuzione da cui hai ricevuto il tuo pacchetto, se stai usando un pacchetto; questo è particolarmente vero se il pacchetto versione è precedente all'attuale versione "upstream" e se non hai verificato se il problema è ancora presente lì.)

In fileparticolare, la documentazione ufficiale è stata aggiornata per menzionare che il bug tracker e la mailing list sono inattivi e fornisce anche un indirizzo e-mail diretto per l'attuale manutentore, che è possibile utilizzare per contattarlo.

Oltre alla risposta di Stephen Kitt , potresti considerare (specialmente se sei uno sviluppatore tu stesso e se il programma - filenel tuo caso - ha un codice sorgente che non è troppo difficile da capire) recuperando il codice sorgente di quel programma (forse dal tuo distribuzione) - dal momento che è un software gratuito - e patch, e anche l'invio di una patch.

Se impieghi del tempo per studiare il codice sorgente , probabilmente realizzerai una segnalazione dei bug migliore.

Se impieghi più tempo a proporre una patch di correzione , è probabile che tu sia considerato più seriamente (e IMHO stai agendo di più nello spirito del software libero).

Quindi usa la libertà fornita dal software libero : studia il suo codice sorgente (libertà # 1) e miglioralo (libertà # 3).

Oggi è molto semplice pubblicare (ad esempio su github ) la tua versione migliorata e condividerla (libertà n. 2).

Assicurati di avere l'ultima versione del fileprogramma. Molte distribuzioni non lo usano (e forse il bug nella tua distribuzione è già stato corretto a monte).

Non sono sicuro che il tuo --correct_extensioncomportamento appartenga file(che è un programma per interrogare , non modificare, i tuoi dati). Ma se lo fa, probabilmente dovrebbe essere scritto--correct-extension o --rename-extension... E una volta che provi a implementarlo, potresti scoprire che ci sono strani casi angolari (che dire di un file tar con gzip, o di un file sorgente C compresso, o qualcosa che potrebbe sono necessarie diverse estensioni di file).

Nota che (contrariamente a Windows) su Linux e Unix un file è in realtà un inode (vedi inode (7) ) e può avere più nomi (o nessuno) e può essere aperto da più processi contemporaneamente (leggi i descrittori di file ) - o nessuno, anche se la maggior parte dei file ha un solo nome (ma vedi link (2) e stat (2) ). Dal momento che lo stesso file potrebbe essere nominato foo.txte bar.gznon ha molto senso attribuire importanza alle estensioni dei file. Vedi anche path_resolution (7) .

Quindi, se provi a implementare la tua correct-extensionidea, scoprirai che non è così semplice da implementare (e persino da specificare) e che non esiste un comportamento semplice ovvio per quello.

Probabilmente, la tua idea non è molto buona e non può essere facilmente implementata su sistemi Linux e POSIX (almeno, non per tutti i casi).

Quindi consiglio di evitare di inviare una richiesta di funzionalità (nella sua forma iniziale, è una perdita di tempo per te e per gli sviluppatori di file ). Altrimenti, lavoraci molto, migliora le sue specifiche e invia una patch .... Certo che ci dedicherai molto (e non penso davvero che valga la pena).

Magari leggi anche qualche libro di programmazione Unix (come il vecchio ALP , o qualcosa di più recente; e anche intro (2) e syscalls (2) ) e sistemi operativi: Three Easy Pieces .

Tu chiedi:

Qual è il modo corretto di richiedere una funzione in GNU Linux?

e per rispondere a ciò, è importante sapere che non esiste una sola cosa come "GNU Linux", di per sé. Il progetto GNU è uno sforzo collaborativo per sviluppare software libero. Alcuni di questi software gratuiti - insieme a grandi quantità di altri software gratuiti e open source - vengono raccolti da altri progetti: collaborativi, progetti aperti come Fedora * o Debian, o sforzi aziendali con vari gradi di apertura, o persino individui. Queste raccolte sono chiamate "Distribuzioni Linux" o "Distribuzioni GNU / Linux" (c'è un dibattito politico in cui non entrerò).

In generale, se sei interessato al miglioramento delle funzionalità , la cosa migliore da fare è lavorare con lo sviluppatore che ha scritto il software - le distribuzioni hanno molto lavoro da fare per raccogliere i vari software e farlo funzionare insieme, e normalmente sarebbe preferiscono quei cambiamenti che accada "a monte".

Quindi, hai fatto la cosa giusta qui: hai trovato l'origine a monte documentata e hai provato a riportare lì.

Sembra, tuttavia, che i metodi di comunicazione documentati per il software a cui sei interessato non funzionino. In tal caso, hai diverse opzioni:

1. Prova a trovare altri modi per contattare gli sviluppatori del software. In questo caso, la maggior parte delle distribuzioni include il filecomando originariamente scritto da Ian Darwin e nominato nominalmente su http://www.darwinsys.com/file/ , con le mailing list che hai citato. Ma come quelle mailing list, il sito principale sembra essere inattivo. In questi tempi, controllare GitHub è un buon secondo passo e ho trovato https://github.com/file/file - che dice il mirror di sola lettura del repository CVS dei file, aggiornato ogni mezz'ora. NOTA: non effettuare richieste pull qui, né commentare alcun commit, inviarle normalmente al bug tracker o alla mailing list. Non è immediatamente utile, ma noto che ci sonosono state apportate modifiche a tale repository nell'ultima settimana. Quindi, una possibile mossa successiva è vedere chi ha commesso tali impegni e contattarli.
2. Puoi chiedere alla persona responsabile del pacchetto nella distribuzione che usi. Per filein Fedora, vedi questa pagina . Poiché lavorano regolarmente con il software, potrebbero avere altri mezzi per contattare l'upstream. A seconda della distribuzione, è meglio farlo presentando un bug o per contatto diretto: è necessario conoscere la cultura individuale. (In Fedora, suggerirei la mailing list di sviluppo .)
3. Se stai usando una distribuzione commerciale, come Red Hat Enterprise Linux *, puoi presentare un ticket di supporto. Come cliente pagante, potresti essere in grado di influenzare il tuo fornitore per trovare una soluzione.
4. Se tutto il resto fallisce, il progetto che ti interessa potrebbe essere morto a monte . In tal caso, è possibile "biforcare" il progetto: creare la propria versione e creare una nuova comunità a monte attorno ad esso. Se la tua versione viene mantenuta e l'altra è morta, è probabile che seguiranno le distribuzioni.

* Lavoro su Fedora. E sono impiegato da Red Hat.

Questo è un bug nella tua distribuzione. Se la distribuzione sta spedendo pagine man non aggiornate, è necessario presentare un bug nel pacchetto che lo ha fornito. Se stai usando debian, puoi usare uno strumento come reportbug per renderlo più semplice.

identify -format %m file.gif[0]

% m formato file immagine (file magic)

[0] indica il primo fotogramma, che potrebbe essere utile se lo si utilizza inavvertitamente su un video poiché altrimenti utilizza le librerie ffmpeg per creare una copia temporanea di ciascun fotogramma.

Funziona solo con le immagini. Non so come farlo per i file generici. ffmpeg restituisce 'avc1' per un file mp4 casuale (altri file mp4 possono restituire stringhe diverse e devi ancora analizzarlo), e non vedo un modo per passare da quello a 'mp4'. 'avc1' non è da nessuna parte in / usr / share / mime.

ffmpeg, o equivalentemente ffprobe, elenca alcuni formati di file che il demuxer utilizza all'inizio del suo output. Per un file mp4 dice

Ingresso # 0, mov, mp4, m4a, 3gp, 3g2, mj2, da. . .
[. . .]
Video: h264 (principale) (avc1 / 0x31637661)

per un png dice

Immettere # 0, png_pipe, da. . .
[. . .]
Video: png, rgb24 (pc)