Acabei de passar um tempo frustrantemente longo para descobrir que o binário do pacote "gnome-console" é chamado "kgx".
Daí a minha pergunta:
Supondo que eu saiba o nome de um pacote instalado do pacman, existe uma maneira geral de encontrar o nome do seu binário que pode ser usado para iniciar o aplicativo?
Para contexto:
Eu sabia que minha instalação padrão do Arch GNOME fornecia um emulador de terminal da GUI. Na GUI, ele era chamado de "Console". Então eu consultei o pacman via pacman -Qs console
. Que retornou:
local/gnome-console 47.1-1 (gnome)
A simple user-friendly terminal emulator for the GNOME desktop
No entanto, gnome-console
não estava dentro do namespace conhecido do meu terminal. Portanto, eu sabia que o binário real deveria ter um nome diferente. Nesse ponto, meu conhecimento acabou, e eu tive que pesquisar na internet (por algum motivo, por muito tempo) até que tropecei em um comentário antigo no Reddit mencionando que o binário é, na verdade, chamado de "kgx".
Imagino que exista uma maneira melhor de fazer isso do que esperar que alguém "na internet" saiba o nome do binário que você está procurando.
Você pode, mas não é tão simples quanto você supõe. Não é garantido que um pacote forneça exatamente um executável. De fato, muitos fornecem vários programas executáveis. Para um exemplo óbvio, considere
coreutils
que fornece utilitários básicos do GNU comocat
,chmod
,ln
,split
e assim por diante. Então não há "seu binário" quando falamos sobre pacotes. Em vez disso, você pode obter uma lista dos vários binários que um pacote pode fornecer.Nota pedante entregue, vamos ver como realmente fazer isso. Eu apenas procuraria por arquivos incluídos no pacote que estão instalados nos vários
bin
diretórios. Algo como:O comando
pacman -Ql PACKAGE_NAME
imprime a lista de arquivos e diretórios que o pacote tocará, com o pacote no primeiro campo e o arquivo/diretório no segundo:Então passamos isso por um
awk
comando que imprime o 2º campo se o 2º campo corresponderbin/
seguido por pelo menos mais um caractere. Isso é para evitar imprimir/usr/bin
a si mesmo. Note que isso não assume espaços em nenhum dos caminhos, o que realmente deveria ser uma suposição segura aqui, mas para fins de completude, aqui está um que também pode lidar com espaços (não no nome do pacote, pois isso não é permitido):E, só para ilustrar o ponto do primeiro parágrafo:
Como alternativa, como pode ser o caso de alguns arquivos executáveis não estarem instalados em
bin
diretórios, você pode iterar sobre a lista de arquivos e procurar por arquivos regulares que seu usuário pode executar:No caso de
coreutils
, isso inclui mais um arquivo: