☰

Qual é a interface recomendada para um utilitário que requer muitos parâmetros?

tag-icon • tag-icon command-line arguments
Qual é a interface recomendada para um utilitário que requer muitos parâmetros?

Estou construindo um utilitário de linha de comando que requer seis informações para funcionar corretamente. Se parece com isso:

fm-git filename repository path comment username password

No entanto, em qualquer sistema individual, usernamee passwordserá constante.

Ao executar o utilitário, estou achando difícil construir. Por exemplo, aqui está uma chamada de teste para o utilitário (dividida em várias linhas para facilitar a leitura):

/Users/chuck/Projects/fm-git/fm-git.py chiv-lib
/Users/chuck/Projects/chiv-lib/ Chivalry/ "continued testing"
Administrator abc1234

Estou considerando diferentes maneiras de transmitir esses argumentos. Por exemplo, fm-git -f filename -r repository ...ou fm-git --filename filename --repository repository.... Também estou pensando em definir as configurações dos argumentos usernamee password, já que eles geralmente não mudam e podem ser eliminados da chamada do utilitário.

Quando os argumentos do utilitário são muitos, mas obrigatórios, qual é a prática aceita para manter a legibilidade da chamada do utilitário?

Responder1

Normalmente, os aplicativos Unix permitem múltiplas maneiras de fornecer essas informações, com as formas mais "específicas" substituindo as menos específicas.

Então você tem:

  • Para aplicações gráficas, o kit de ferramentas usado quase sempre fornece alguma maneira de ter recursos (por exemplo, xrdb-style em X simples, etc.)

  • um arquivo de configuração, se o kit de ferramentas ainda não fornecer um.

  • opções de linha de comando, tanto em formato curto quanto em formato longo (fácil em getoptC)

  • padrões razoáveis ​​se nenhuma informação for fornecida, por exemplo, o diretório atual de um caminho

Os parâmetros posicionais só fazem sentido para alguns parâmetros obrigatórios, seguidos possivelmente por uma lista de arquivos (porque as especificações curinga se expandem para vários parâmetros). Seis peças individuais são demais; a ordem é difícil de lembrar, então use opções para elas.

Para senhas, pode ser útil fornecer uma maneira de fazer o aplicativo ler a senha do stdin, possivelmente usando um valor especial (por exemplo, --password -ou -p -).

Quem usa o aplicativo pode escolher se senhas codificadas, senhas em arquivos de configuração ou permitir que o usuário insira a senha são a melhor opção para o caso de uso específico.

Responder2

Em geral, é uma boa ideia:

  1. calcule argumentos dependentes, mas permita redefini-los: por exemplo, no seu exemplo, você tem filenameo mesmo que $(basename repository), portanto, pode exigir apenas o repositório, mas tem a opção --filenamede fornecer um nome de arquivo alternativo.
  2. ocultar a autenticação da linha de comando e psda saída. Coloque-os em algum arquivo: pode ser $HOME/.fm-git.conf, dê mais restrições ao arquivo chmod 600 $HOME/.fm-git.confe leia-os do arquivo. Às vezes também é uma opção para obter nome de usuário e senha de variáveis ​​de ambiente (como nome de usuário padrão é o nome de usuário do sistema ou SUDO_USER), mas pode não ser o seu caso.

Então, depois dessas duas otimizações, você tem apenas 3 parâmetros cli, é aceitável, eu acho. Sinta-se à vontade para usá-los como parâmetro posicional ou fornecer alguns sinalizadores como --comment: fornecer sinalizadores longos aumentará a legibilidade se você usar ainda mais seu programa em scripts, mas exigirá digitar mais se você executar seu programa principalmente manualmente a partir do cli.

De qualquer forma, ao escrever seu programa em Python, recomendo que você usemódulo argparse- ajudará você a analisar parâmetros e fazer alterações no futuro, se desejar alterá-los.

informação relacionada