Quelle est la bonne façon de demander une fonctionnalité dans GNU Linux?
J'essaie d'envoyer un rapport de bogue pour le fichier d'application,/usr/bin/file
Mais consulter l'homme et envoyer un e-mail
BOGUES Veuillez signaler les bogues et envoyer les correctifs au traqueur de bogues à http://bugs.gw.com/ ou à la liste de diffusion à ⟨[email protected]⟩ (visitez http : //mx.gw.com/mailman/listinfo/file premier abonné).
Me fait découvrir que l'adresse e-mail n'existe pas.
Y a-t-il une autre façon de communiquer avec la communauté? J'espère que cette question ici en fait déjà partie :)
Voici donc mon email:
échec possible de la fonctionnalité: l'option
--extensionne semble rien afficher$ file --extension "ab.gif" ab.gif: ???Il serait utile de pouvoir facilement utiliser la sortie de ceci pour renommer un fichier à son extension correcte.
quelque chose comme le fichier
--likely_extensionne produirait l'extension probablement détectée ou une erreur que si la détection était trop faiblecomme ainsi:
$ file --likely_extension "ab.gif" gifmieux serait une option
--correct_extension:$ file --correct_extension "ab.jpg" $ ls ab.gifTyvm pour cette application :)
Vous suivez la bonne procédure pour déposer un problème ou une demande d’amélioration: si la documentation d’un programme indique comment procéder, suivez ces instructions.
Malheureusement, il arrive souvent que des projets meurent ou que les instructions de la version que vous avez ne soient plus exactes. Dans ces cas, les choses deviennent un peu plus difficiles. Une approche générale possible consiste à déposer un bogue avec votre distribution; le succès peut être plutôt aléatoire ... (je dois mentionner qu'il est généralement préférable de signaler un bug à la distribution que vous avez reçue package from, si vous utilisez un package; cela est particulièrement vrai si la version packagée est plus ancienne que la version "amont" actuelle et si vous n'avez pas vérifié si le problème est toujours présent là-bas.)
Pour file en particulier, la documentation officielle a été mis à jour pour mentionner que le suivi des bogues et la liste de diffusion sont en panne, et il fournit également une adresse e-mail directe pour le responsable actuel, que vous pourriez utiliser pour le contacter.
En plus de réponse de Stephen Kitt , vous pouvez envisager (surtout si vous êtes vous-même développeur, et si le programme - file dans votre cas - a un code source qui n'est pas trop difficile à comprendre) récupérer le code source de ce programme (peut-être à partir de votre distribution) - car il s'agit de logiciel gratuit - et le patcher, et également envoyer un patch.
Si vous prenez le temps d'étudier le code source , vous ferez probablement un meilleur rapport de bogue.
Si vous prenez plus de temps pour proposer un correctif , vous serez probablement considéré plus sérieusement (et à mon humble avis, vous agissez davantage dans l'esprit du logiciel libre ).
Donc utilisez la liberté offerte par logiciel libre: étudiez son code source (liberté # 1) et améliorez-le (liberté # 3).
Aujourd'hui, il est très facile de publier (par exemple sur github ) votre version améliorée et partagez-la (liberté # 2).
Assurez-vous d'avoir la dernière version du programme file. De nombreuses distributions n'utilisent pas cela (et peut-être que le bogue de votre distribution a déjà été corrigé en amont).
Je ne suis pas sûr que votre --correct_extension le comportement appartient à file (qui est un programme pour requête, pas changer, vos données). Mais si c'est le cas, il devrait probablement être orthographié --correct-extension ou --rename-extension ... Et une fois que vous essayez de l'implémenter, vous découvrirez peut-être qu'il y a des cas étranges (qu'en est-il d'un fichier tar compressé, ou d'un fichier source C compressé, ou quelque chose qui pourrait avoir besoin de plusieurs extensions de fichier).
Notez que (contrairement à Windows) sous Linux et Unix, un fichier est en fait un inode (voir inode (7) ) et peut avoir plusieurs noms (ou aucun), et peut être ouvert par plusieurs processus à la fois (en savoir plus descripteurs de fichiers ) - ou aucun, même si la plupart des fichiers n'ont qu'un seul nom (mais voir - lien (2) & stat (2) ). Étant donné que le fichier identique pourrait être nommé foo.txt et bar.gz cela n'a pas beaucoup de sens d'attacher de l'importance aux extensions de fichiers. Voir aussi path_resolution (7) .
Donc, si vous essayez d'implémenter votre correct-extension idée, vous découvrirez que ce n'est pas aussi simple à implémenter (et même à spécifier), et qu'il n'y a pas de comportement simple évident pour ça.
Probablement, votre idée n'est pas très bonne et ne peut pas être facilement mise en œuvre sur les systèmes Linux et POSIX (du moins, pas pour tous les cas).
Je recommande donc d'éviter même de soumettre une demande de fonctionnalité (dans sa forme initiale, c'est une perte de temps pour vous et pour les développeurs de file). Sinon, travaillez-y beaucoup, améliorez ses spécifications et soumettez un correctif ... Bien sûr, vous y consacrerez beaucoup de travail (et je ne pense vraiment pas que cela en vaille la peine).
Peut-être aussi lire un livre de programmation Unix (comme l'ancien ALP , ou quelque chose de plus récent; et aussi intro (2) & - syscalls (2) ) et Systèmes d'exploitation: trois pièces faciles .
Tu demandes:
Quelle est la bonne façon de demander une fonctionnalité dans GNU Linux?
et pour y répondre, il est important de savoir qu’il n’existe pas de "GNU Linux" en soi. Le projet GNU est un effort de collaboration pour développer des logiciels libres. Certains de ces logiciels gratuits - ainsi que de grandes quantités de autres logiciels libres et open source - sont collectés par autre projets: soit collaboratifs, des projets ouverts comme Fedora * ou Debian, soit des efforts d'entreprise avec différents degrés d'ouverture, ou même des individus. Ces collections sont appelées "distributions Linux" ou "distributions GNU/Linux" (il y a là un débat politique dans lequel je n'entrerai pas).
En général, si vous êtes intéressé par l'amélioration de la fonctionnalité , la meilleure chose à faire est de travailler avec le développeur qui a écrit le logiciel - les distributions ont beaucoup de travail à faire pour simplement collecter les différents logiciels et les faire fonctionner ensemble, et normalement préférez ces changements se produiraient "en amont".
Donc, vous avez fait la bonne chose ici - vous avez trouvé la source en amont documentée et avez essayé de faire un rapport là-bas.
Il semble cependant que les méthodes de communication documentées pour le logiciel qui vous intéresse ne fonctionnent pas. Dans ce cas, vous avez plusieurs options:
- Essayez de trouver d'autres moyens de contacter les développeurs du logiciel. Dans ce cas, la plupart des distributions incluent la commande
fileécrite à l'origine par Ian Darwin et hébergée nominalement à http://www.darwinsys.com/file/ , avec les listes de diffusion que vous ' ai mentionné. Mais comme ces listes de diffusion, le site principal semble être en panne. De nos jours, la vérification de GitHub est une bonne deuxième étape, et j'ai trouvé https://github.com/file/file - qui dit Miroir en lecture seule du référentiel CVS de fichiers , mis à jour toutes les demi-heures. NOTE: ne faites pas de pull request ici, ne commentez aucun commit, soumettez-les de manière habituelle au bug tracker ou à la mailing list. Ce n'est pas immédiatement utile, mais je remarque qu'il y a have des changements ont été apportés à ce référentiel la semaine dernière. Donc, une prochaine étape possible est de voir qui a fait ces commits et de les contacter. - Vous pouvez demander à la personne responsable du colis dans la distribution que vous utilisez. Pour
filedans Fedora, voir cette page . Puisqu'ils travaillent régulièrement avec le logiciel, ils peuvent avoir d'autres moyens de contacter l'amont. Selon la distribution, cela se fait mieux en signalant un bug ou par contact direct - vous avez en quelque sorte besoin de connaître la culture individuelle. (Dans Fedora, je suggère la liste de diffusion devel .) - Si vous utilisez une distribution commerciale, comme Red Hat Enterprise Linux *, vous pouvez déposer un ticket de support. En tant que client payant, vous pourrez peut-être influencer votre fournisseur pour trouver une solution.
- Si tout le reste échoue, le projet qui vous intéresse pourrait être mort en amont. Dans ce cas, vous pouvez "bifurquer" le projet - créer votre propre version et construire une nouvelle communauté en amont autour de lui. Si votre version est maintenue et que l'autre est morte, il est probable que les distributions suivront.
* Je travaille sur Fedora. Et je suis employé par Red Hat.
Il s'agit d'un bug dans votre distribution. Si la distribution envoie des pages de manuel obsolètes, vous devez déposer un bogue contre le package qui l'a fourni. Si vous utilisez debian, vous pouvez utiliser un outil tel que reportbug pour simplifier les choses.
identify -format %m file.gif[0]
Format de fichier image% m (fichier magique)
Le [0] signifie la première image, ce qui pourrait être utile si vous l'utilisez accidentellement sur une vidéo, sinon il utilise les bibliothèques ffmpeg pour faire une copie temporaire de chaque image.
Cela ne fonctionne que pour les images. Je ne sais pas comment le faire pour les fichiers génériques. ffmpeg renvoie 'avc1' pour un fichier mp4 aléatoire (d'autres fichiers mp4 peuvent renvoyer des chaînes différentes, et vous devez toujours l'analyser), et je ne vois pas de moyen de passer de cela à 'mp4'. 'avc1' n'est nulle part dans/usr/share/mime.
ffmpeg, ou de manière équivalente ffprobe, répertorie certains formats de fichier que le démultiplexeur utilise au début de sa sortie. Pour un fichier mp4, il dit
Entrée # 0, mov, mp4, m4a, 3gp, 3g2, mj2, from. . .
[. . .]
Vidéo: h264 (Principal) (avc1/0x31637661)
pour un png ça dit
Saisissez # 0, png_pipe, à partir de. . .
[. . .]
Vidéo: png, rgb24 (pc)