Onde colocar scripts de wrapper?

Question

Eu criei alguns scripts para tarefas administrativas etc, eu os fiz para serem independentes do ambiente - toda dependência é injetada através de argumentos. No entanto, é irritante fornecer scripts para dependências comumente usadas toda vez que eu o executo, e não quero codificar nele nenhuma informação local, então criei wrappers. Eu coloquei meus scripts gerais em $ HOME / bin, mas onde devo colocar wrappers que contêm informações locais e são apenas para acelerar a invocação?

Exemplo: Pense no script que faz e envia para o backup do sistema criptografado do servidor FTP fornecido. Ele foi feito como um script genérico que pode ser usado com qualquer chave pública gpg ou servidor ftp, porém eu estou usando sempre apenas uma chave pública específica e fazendo o upload somente para um servidor ftp específico, então criei um wrapper com essa informação. Este script genérico está realmente em / root / bin, pois é uma ferramenta administrativa, mas onde colocar esse wrapper?

    

Answer 1

Esqueça as coisas do wrapper :-)

Tudo o que você precisa é de um .file (arquivo de pontos) com as opções de configuração do usuário, na diretiva $ USER. Você pode ter um em / etc para as opções de configuração do sistema também.

Faça seu script checar esses arquivos .fils (arquivo de pontos) e se eles existirem, use-os.

HTH, .

    

Answer 2

Você pode usar aliases ou functions

Dado um script geral $HOME/bin/foo que precisa ser chamado de maneiras diferentes, assumindo o shell bash :

Aliases

# ~/.bashrc
alias foo1="$HOME/bin/foo -a -b"
alias foo2="$HOME/bin/foo -c -d"

Funções

# ~/.bashrc
foo1() { $HOME/bin/foo -a -b; }
foo2() { $HOME/bin/foo -c -d; }
export -f foo1 foo2

export -f disponibiliza as funções no ambiente, para outros scripts executados a partir do seu shell. Assim, você pode fazer um script foo_all executar as funções foo1 e foo2 sem a necessidade de defini-las dentro do script.

Nota extra

Eu acredito que a maneira tradicional para muitos é colocar os scripts gerais em /usr/local/bin/ e colocar seus wrappers como scripts regulares em $HOME/bin/ .

    

Answer 3

Eu acredito que você deveria abstrair mais uma camada, para que você acabe com esse tipo de padrão.

GenericName 
    calls -> Architecture_or_Server_or_Domain_or_User_specific
                calls -> AllArchServer Script

Exemplo usando backup

do_machine_backup é um nome para as pessoas usarem (executar, adicionar tarefas do cron, etc.)

A tarefa é treinar qual ambiente / servidor (talvez usuário) está sendo executado em / on / by. Digamos que você tenha 3 ambientes dev / test / prod, poderia resolver isso e depois chamar o script Environment_Specific.

do_dev_machine_backup -type user | db | web
do_test_machine_backup ...
do_prod_machine_backup ...
or
do_centos_machine_backup -env dev|test|prod ...
...

Isso funciona sabendo o domínio / ambiente , que é o backup_host, qual é o backup, quais chaves usar, onde os arquivos de log devem ir, etc.

do_gen_machine_backup <src dir> <dst host> dst dir> <host_key> ... many args

Eu faria esses scripts (não aliases ou funções), misturando-os (tendo os dois) apenas servirá para tornar mais complicado depurar / desenvolver / manter, conforme se desenvolve. Você está salvando milissegundos apenas para comparar com a freqüência que você usa e com o tempo de execução dos scripts, isso provavelmente fará com que seja insignificante que sejam funções / aliases e não scripts.

Eu colocaria tudo em um lugar, onde você quiser, mas um nível superior, isso facilita a configuração do novo servidor, instala um diretório e, opcionalmente, adiciona um diretório a um caminho. ex. /usr/local/CompanyShortName e daqui, você pode expandir dependendo de suas necessidades agora e no futuro ./bin ./sbin/ ./config ./keys ...

É difícil ser específico, por isso minhas sugestões foram um pouco genéricas, espero que alguns dos princípios de criação de um ambiente sejam comuns e possam ser frutos para comentários adicionais.