como usar o regex no alias?

4

Eu quero criar o alias para o comando "ssh [email protected]" como 10.32.44.225

alias [0-9][0-9][0-9].[0-9][0-9][0-9].[0-9][0-9][0-9].[0-9][0-9][0-9]="ssh user@$0"

Eu criei, mas não está funcionando. Existe algum erro de sintaxe neste comando?

    
por KALAI SELVAN 02.11.2014 / 06:59

5 respostas

0

Isto é factível - mesmo com alias , embora a única maneira que conheço envolva eval , o que pode ser perigoso dependendo do que os argumentos possam conter - mas não com regex. O problema real aqui é a tokenização - para cada comando simples que o shell lê, ele tenta executar qualquer palavra encontrada em posição do comando como um alias primeiro, então. falhando isso, como uma função / builtin, e, falhando ambos, como um executável $PATH ed. Esta é uma simplificação do processo, mas é bem próxima da verdade.

O problema é que você tem em uma única palavra dois tokens possíveis - ssh é o que você gostaria de executar, e @$IP é um < em> argumento com o qual você gostaria de executá-lo. Você pode fazer como foi sugerido em outro lugar e simplesmente dividir o token em dois combinados com uma função shell - isso é feito simplesmente. Ou você pode obter o primeiro token para dividir-se .

Uma coisa interessante sobre os nomes do shell $var é que eles são bem explícitos sobre quais caracteres eles podem conter. Salve um único caso especial, @ não está entre esses. Se eu fizer:

$var_this_is_appended_to_the_name

O shell interpretará a string inteira como um nome de variável único, porque todos os caracteres dentro são permitidos dentro de um $var name. Mas ...

$var@this_is_appended_to_the_name

... resulta em dois tokens (se não necessariamente duas palavras ) e o shell expande $var independentemente de @the_rest . A expansão do alias, infelizmente, não tem nenhum marcador conveniente como $ e, portanto, o shell sempre tentará expandir ...

alias@this_is_appended; alias_this_is_appended

... como um único token. É também porque o shell expande ambos $var e aliased cmdstring simultaneamente que o último não pode ser contido no primeiro e ainda ser executado sem eval - mas então qualquer argumento dado $var - even ${varcontains='$(cmd substitutions)'} será avaliado duas vezes - o que pode ser bastante perigoso.

Então eu proponho que você faça algo com uma variável readonly chamada $ssh que se parece com isso:

ssh() { case "$1" in
(@*)  set -- "$USER$@";;
esac; command -p ssh "$@"
}

readonly ssh='ssh '

Dessa forma, você pode fazer ...

[email protected]; [email protected]

... ou ...

ssh @someplace.com

... e etc. ou qualquer outra coisa, porque o shell irá dividir os dois tokens que são $ssh e @somplace.com em duas palavras . Não funciona, no entanto, se você ...

"[email protected]"

... porque nesse caso, apesar de você receber dois tokens, o resultado ainda é uma única palavra. Eu usei readonly acima para garantir que $ssh varname não possa ser sabotado e redefinido para algo mais perigoso, mas isso ainda pode ser possível com a função ssh para qualquer usuário normal no shell. Não tenho conhecimento de nenhum meio que possa ser usado para readonly uma função de shell, mas, se isso for uma preocupação para você, talvez você queira localizar a função em um script de shell $PATH ed com leitura / gravação apropriada direitos.

Então, novamente, ele pode funcionar sem uma função se configurado a partir de um arquivo de perfil ou qualquer outra coisa:

[mikeserv@localhost ~]$ readonly "ssh=ssh $USER"
[mikeserv@localhost ~]$ $ssh@localhost
mikeserv@localhost's password: 

Mas é menos flexível assim.

    
por 02.11.2014 / 19:52
3

Aliases de Bash não funcionam assim - são strings de palavras simples sem metacaracteres de casca e sem globbing. você pode, com muito esforço, fazer com que o gancho de depuração faça o que você quer (iniciar de esta pergunta de super usuário ), mas você provavelmente seria melhor aclimatar a digitação de um par extra de caracteres e definir uma função de um argumento s ou algo em vez disso :

s() {
    ssh user@"$1"
}

Então:

s 127.0.0.1

será executado:

ssh [email protected]

É tecnicamente possível definir aliases individuais, ou fazer scripts de shell individuais, que façam o que você quer, mas existem 2 ^ 32 endereços possíveis, portanto, não é realmente viável. Se você tiver um número muito pequeno de endereços que queira usar e os conhecer com antecedência, poderá fazê-lo diretamente.

    
por 02.11.2014 / 07:28
2

Não há correspondência de padrões em aliases. Então, se você quiser fazer o login em 192.168.0.2 sem digitar ssh user@ , é necessário especificar:

alias 10.32.44.225="ssh [email protected]"

para cada endereço IP que você provavelmente usará.

Claro que você pode escrever um programa para escrever essas linhas para o intervalo que você precisa. Ou faça algo como:

for i in $(seq 225 228); do
    alias 10.32.44.$i="ssh [email protected].$i"
done

para obter aliases para o intervalo 10.32.44.22510.32.44.228

    
por 02.11.2014 / 07:25
2

Se você estiver usando bash 4 ou posterior, poderá aproveitar o command_not_found_handle hook, pois é extremamente improvável que um endereço IP simples seja um nome de comando válido. Adicione isto ao seu arquivo .bashrc :

command_not_found_handle () {
    if [[ $1 =~ [0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9] ]]; then
        ssh user@$1
    else
        printf "Command not found: %s\n" "$1" >&2
        return 127
    fi
}

Se o comando ausente corresponder à sua expressão regular para um endereço IP, ele executará o comando ssh desejado; caso contrário, imita o comportamento padrão de um comando ausente.

    
por 02.11.2014 / 16:37
1

Provavelmente é mais simples usar o arquivo de configuração ssh , em vez de um alias ou função do shell. Suponha que ssh [email protected] conecte você à sua máquina de desenvolvimento. Você pode adicionar o seguinte a ~/.ssh/config :

Host dev
    User user
    Hostname 10.32.44.225

Agora você pode se conectar à máquina como user com

ssh dev

Você pode adicionar mais desses aliases se tiver várias máquinas; veja man ssh_config para mais detalhes.

    
por 02.11.2014 / 16:33