Qual é a maneira correta de solicitar um recurso no GNU Linux?

Question

Estou tentando enviar um relatório de bug para o arquivo do aplicativo, / usr / bin / file

Mas consultar o homem e enviar um email

BUGS Please report bugs and send patches to the bug tracker at http://bugs.gw.com/ or the mailing list at ⟨[email protected]⟩ (visit http://mx.gw.com/mailman/listinfo/file first to subscribe).

Me fez descobrir que o endereço de e-mail não existe.

Existe outra maneira de se comunicar com a comunidade? Espero que essa pergunta já faça parte dela:)

Então, aqui está meu e-mail:

possible feature failure: the --extension option doesn't seem to output anything

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

It would be useful to easily be able to use the output of this to rename a file to its correct extension.

something like file --likely_extension would only output the likely detected extension or an error if the detection was too low

like thus:

$ file --likely_extension "ab.gif"
gif

better though would be a --correct_extension option:

$ file --correct_extension "ab.jpg"

$ ls
ab.gif

Tyvm for this app :)

    

Answer 1

Você está seguindo o procedimento correto para registrar uma solicitação de problema ou melhoria: se a documentação de um programa menciona como fazer isso, siga estas instruções.

Infelizmente, muitas vezes acontece que projetos morrem, ou que as instruções na versão que você tem não são mais precisas. Nestes casos, as coisas ficam um pouco mais difíceis. Uma possível abordagem geral é arquivar um bug na sua distribuição; sucesso pode ser um pouco difícil de acertar ... (eu deveria mencionar que normalmente é melhor relatar um bug para a distribuição da qual você tirou o seu pacote, se você estiver usando um pacote; isso é especialmente verdadeiro se a versão empacotada for mais antiga que a versão atual “upstream” e se você ainda não verificou se o problema ainda está presente.

Para file especificamente, a documentação oficial foi atualizada para mencionar que o rastreador de bugs e A lista de discussão está desativada e também fornece um endereço de e-mail direto para o mantenedor atual, que você pode usar para contatá-lo.

    

Answer 2

Além da resposta de Stephen Kitt , você pode considerar (especialmente se você for um desenvolvedor, e se o programa - file no seu caso - tem código fonte que não é muito difícil de entender) buscando o código fonte daquele programa (talvez da sua distribuição) - já que é software livre - e remendando-o, e também enviando um patch.

Se você reservar um tempo para estudar o código-fonte , provavelmente fará um relatório de erros melhor.

Se você dedicar mais tempo para propor um patch de correção , provavelmente você será considerado mais seriamente (e IMHO você está agindo mais no espírito do software livre).

Então use a liberdade oferecida pelo software livre : estude seu código-fonte (liberdade # 1) e melhorá-lo (liberdade # 3).

Hoje é muito fácil publicar (por exemplo, no github ) sua versão melhorada e compartilhá-la (freedom # 2).

Certifique-se de ter a versão mais recente do programa file . Muitas distribuições não estão usando isso (e talvez o bug na sua distribuição já tenha sido corrigido pelo autor).

Não tenho certeza de que seu comportamento --correct_extension pertença a file (que é um programa para consultar , e não alterar seus dados). Mas se isso acontecer, provavelmente deve ser escrito --correct-extension ou --rename-extension ... E uma vez que você tentar implementar isso, você pode descobrir que existem casos esquisitos estranhos (que dizer de um arquivo tar compactado ou de uma fonte C compactada? arquivo, ou algo que pode precisar de várias extensões de arquivo).

Observe que (ao contrário do Windows) no Linux & Unix um arquivo é na verdade um inode (veja inode (7) ) e podem ter vários nomes (ou nenhum), e pode ser aberto por vários processos de uma vez (leia sobre descritos de arquivo ) - ou nenhum, mesmo que a maioria dos arquivos tenha apenas um nome (mas veja link (2) e stat (2) ). Como o arquivo mesmo pode ser denominado foo.txt e bar.gz , não faz muito sentido atribuir importância às extensões de arquivo. Veja também path_resolution (7) .

Então, se você tentar implementar sua idéia de correct-extension , descobrirá que não é tão simples de implementar (e até de especificar), e que não há um comportamento óbvio simples para isso.

Provavelmente, sua idéia não é muito boa e não pode ser facilmente implementada em sistemas Linux e POSIX (pelo menos, não para todos os casos).

Por isso, recomendo evitar o envio de uma solicitação de recurso (em sua forma inicial, é uma perda de tempo para você e para os desenvolvedores de file ). Ou então, trabalhe muito, melhore suas especificações e envie um patch ... É claro que você vai gastar muito trabalho nisso (e eu realmente não acho que valha a pena).

Talvez também leia algum livro de programação do Unix (como o antigo ALP ou algo mais recente e também intro (2) & syscalls (2) ) e Sistemas Operacionais: Três Partes Fáceis .

    

Answer 3

Você pergunta:

What's the correct way to ask for a feature in GNU Linux?

e para responder isso, é importante saber que não existe uma única coisa como "GNU Linux", por si só. O Projeto GNU é um esforço colaborativo para desenvolver software livre. Parte desse software livre - junto com grandes quantidades de outro software livre e de código aberto - é coletado por outros projetos: projetos colaborativos e abertos como o Fedora * ou o Debian, ou esforços corporativos com graus variados de abertura, ou mesmo indivíduos. Essas coleções são chamadas de "Distribuições Linux" ou "Distribuições GNU / Linux" (há um debate político no qual não vou entrar).

Em geral, se você estiver interessado no aprimoramento do recurso , a melhor coisa a fazer é trabalhar com o desenvolvedor que escreveu o software - as distribuições têm muito trabalho a fazer para coletar vários softwares e fazê-lo funcionar em conjunto, e normalmente preferiria que essas mudanças acontecessem "upstream".

Então, você fez a coisa certa aqui - você encontrou a fonte documentada e tentou reportar lá.

Parece, no entanto, que os métodos de comunicação documentados para o software em que você está interessado não estão funcionando. Nesse caso, você tem várias opções:

1. Tente encontrar outras maneiras de entrar em contato com os desenvolvedores do software. Neste caso, a maioria das distros inclui o comando file originalmente escrito por Ian Darwin e, nominalmente, hospedado no link , com as listas de discussão você mencionou. Mas, como essas listas de discussão, o site principal parece estar inativo. Neste dia e idade, verificar o GitHub é um bom segundo passo, e eu encontrei o link - que diz Espelho somente leitura do repositório CVS do arquivo, atualizado a cada meia hora. OBSERVAÇÃO: não faça pedidos de pull aqui, nem comente nenhum commit, submeta-os normalmente ao bug tracker ou à lista de discussão. Isso não é imediatamente útil, mas percebo que tem sido alterações a esse repo na semana passada. Então, um possível próximo passo é ver quem fez os commits e contatá-los.
2. Você pode perguntar à pessoa responsável pelo pacote na distro que você usa. Para file no Fedora, veja esta página . Como eles trabalham com o software regularmente, eles podem ter outros meios de entrar em contato com o desenvolvedor. Dependendo da distro, isso é melhor feito arquivando um bug ou por contato direto - você meio que precisa conhecer a cultura individual. (No Fedora, sugiro a lista de discussão devel .)
3. Se você estiver usando uma distribuição comercial, como o Red Hat Enterprise Linux *, você pode arquivar um ticket de suporte. Como cliente pagante, você pode influenciar seu fornecedor a encontrar uma solução.
4. Se tudo mais falhar, o projeto do seu interesse pode ser envio morto . Nesse caso, você pode "bifurcar" o projeto - crie sua própria versão e construa uma nova comunidade de desenvolvimento em torno dele. Se a sua versão for mantida e a outra estiver morta, é provável que as distribuições se sigam.

* Eu trabalho no Fedora. E eu sou empregado da Red Hat.

    

Answer 4

Este é um bug na sua distribuição. Se a distribuição estiver enviando man pages que estão desatualizadas, você deve registrar um bug no pacote que a forneceu. Se você está usando o debian, você pode usar uma ferramenta como o reportbug para tornar isso mais simples.

    

Answer 5

identify -format %m file.gif[0]

%m image file format (file magic)

O [0] significa o primeiro quadro, que pode ajudar se você acidentalmente usá-lo em um vídeo, caso contrário, ele usa bibliotecas ffmpeg para fazer uma cópia temporária de cada quadro.

Isso só funciona para imagens. Eu não sei como fazer isso para arquivos genéricos. O ffmpeg retorna 'avc1' para um arquivo mp4 aleatório (outros arquivos mp4 podem retornar strings diferentes, e você ainda precisa analisá-lo), e eu não vejo uma maneira de obter isso do 'mp4'. 'avc1' não está em nenhum lugar em / usr / share / mime.

ffmpeg, ou equivalentemente ffprobe, lista alguns formatos de arquivo que o demuxer usa no início de sua saída. Para um arquivo mp4, ele diz

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from . . .
[. . .]
Video: h264 (Main) (avc1 / 0x31637661)

para um png diz

Input #0, png_pipe, from . . .
[. . .]
Video: png, rgb24(pc)