Eu personalizei .bashrc com um número de alias, especificamente ll e export LS_OPTIONS='--color=auto'
Infelizmente, isso não funciona quando usado com sudo , então também modifiquei /root/.bashrc , mas isso parece não ter feito diferença.
sudo env mostra HOME=/root e SHELL=/bin/bash
Como posso obter os comandos sudo para usar as configurações em /root/.bashrc ?
Entendo que isso acontece somente quando bash é executado de forma interativa, por isso estou aberto a outras sugestões sobre como personalizar.
Obrigado àqueles que responderam, que me pediram para ler man sudo com mais cuidado.
sudo -s Se nenhum comando for especificado, um shell interativo será executado.
Este shell interativo usa /root/.bashrc e, portanto, inclui minhas personalizações.
Requer que o comando seja inserido separadamente, mas está tudo bem.
sudo executa um executável, não um comando shell. Por isso, não sabe sobre aliases. Se você executar sudo ls , é como sudo /bin/ls , ele não usa nenhum ls alias que você possa ter.
Você pode fazer com que sudo ls expanda o alias colocando o seguinte em .bashrc :
alias sudo='sudo '
Observe o espaço à direita - que informa ao shell para continuar a expansão de alias com a palavra que vem depois de sudo . Esteja ciente de que aliases em expansão depois do sudo podem nem sempre ser uma boa ideia, depende dos tipos de aliases que você tem.
Além disso, o sudo remove a maioria das variáveis do ambiente. Isso não afetará um alias como alias ls='ls $LS_OPTIONS' , porque essa é uma variável de shell usada pelo shell enquanto ele está expandindo o comando (e exportá-lo de .bashrc não tem nenhum propósito). Mas isso afetaria as variáveis usadas pelo comando, como LS_COLORS . Você pode configurar o sudo para manter certas variáveis de ambiente editando sua configuração: execute visudo e adicione a linha
Defaults env_keep += "LS_COLORS"
Com essas configurações, sudo ll dará as cores que você está acostumado.
Como alternativa, você pode executar um shell raiz com sudo -s . Este shell carregará seu arquivo de configuração ( ~/.bashrc for bash). Dependendo de como o sudo é configurado, isso pode manter HOME definido em seu diretório pessoal ou alterá-lo para /root . Você pode forçar o diretório home a ser configurado para root's com sudo -Hs ; Por outro lado, para manter o diretório inicial original, execute sudo env HOME="$HOME" bash .
Sempre senti que essa pergunta é um problema XY . O título implica que eles querem algo fora de /root/.bashrc , mas realmente o que a questão é depois é os aliases deste arquivo - isso é amplamente acreditado para não ser possível por isso - Por que meu script Bash não reconhece aliases? .
É basicamente por design que seus aliases não serão apanhados em sudo e em outros lugares porque não são portáteis, e essa também é minha opinião sobre eles.
Qualquer coisa que esteja no ambiente do usuário não deve ser assumida por scripts e qualquer software que possa ser executado em uma determinada caixa. Mas percebo que há cenários em que pode haver alguns aliases em $HOME/.bashrc de uma determinada conta de usuário que outras pessoas possam querer aproveitar em cenários interativos.
Para esse fim, você pode simplesmente dizer ao interpretador Bash para expandir quaisquer aliases que encontrar durante o processo de login, fora dos comportamentos normais de shell que você executa ao usar sudo .
Para configurar, adicionei os seguintes aliases, variáveis de ambiente e funções aos arquivos /root/.bashrc e /root/.bash_profile de meu usuário root.
$ grep smurf ~/.bashrc
alias brc_smurf='echo "ran alias from /root/.bashrc"'
export brc_smurf_env='var from /root/.bashrc'
bpf_smurf_func() { echo 'ran func from /root/.bash_profile'; }
$ grep smurf ~/.bash_profile
alias bpf_smurf='echo "ran alias from /root/.bash_profile"'
export bpf_smurf_env='var from /root/.bash_profile'
brc_smurf_func() { echo 'ran func from /root/.bashrc'; }
Sem fazer nada disso, nenhum trabalho (sem surpresas):
$ sudo brc_smurf
sudo: brc_smurf: command not found
$ sudo bpf_smurf
sudo: bpf_smurf: command not found
Observamos que o comando alias não mostra aliases quando executado em sudo :
$ sudo alias
$
Esse comportamento é sua dica de que você não deve esperar que aliases sejam acessíveis. Mas nós continuamos ...
Se executarmos bash -ci , podemos induzir o Bash a ler pelo menos o nosso $HOME/.bashrc :
$ sudo bash -ci 'alias' | grep smurf
alias brc_smurf='echo "ran alias from /root/.bashrc"'
Legal, então talvez possamos executá-lo?
$ sudo bash -ci 'alias; brc_smurf'
bash: alias; brc_smurf: No such file or directory
shopt -s expand_aliases
Não. Novamente, isso é intencional, estamos fazendo algo que não devemos fazer, portanto, há vários "seguranças" que precisamos desativar. a outra "segurança" é Bash.
$ sudo bash -ci 'shopt -s expand_aliases; alias; brc_smurf'
alias brc_smurf='echo "ran alias from /root/.bashrc"'
alias cp='cp -i'
alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'
alias l.='ls -d .* --color=auto'
alias ll='ls -l --color=auto'
alias ls='ls --color=auto'
alias mv='mv -i'
alias rm='rm -i'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
ran alias from /root/.bashrc
Aqui podemos ver nossa mensagem de /root/.bashrc , nós executamos com sucesso o alias do usuário root brc_smurf .
Se você estiver usando o método mostrado acima, estes devem funcionar também.
$ sudo bash -ci 'shopt -s expand_aliases; brc_smurf; echo $brc_smurf_env'
ran alias from /root/.bashrc
var from /root/.bashrc
Isso funciona também como esperado:
$ sudo bash -ci 'shopt -s expand_aliases; brc_smurf; echo $brc_smurf_env;brc_smurf_func'
ran alias from /root/.bashrc
var from /root/.bashrc
ran func from /root/.bashrc
Você pode fazer isso para obter acesso a variáveis de ambiente + aliases de /root/.bashrc :
$ sudo bash -ci 'shopt -s expand_aliases; <cmds>'
Este método ativa o conteúdo de /root/.bashrc , ele não pega o conteúdo de /root/.bash_profile .
Há um monte de configurações no arquivo / etc / sudoers especificamente ou a configuração de um ambiente para quando os comandos sudo são executados (por exemplo, garantir que o PATH tenha apenas locais confiáveis), mas dependendo do que você espera obter a partir disso, você pode não conseguir fazer o que está procurando se envolver a execução de comandos reais em um shell para configurar o ambiente. O Sudoing especificamente não fornece um shell de login root, portanto, ele não configura um perfil regular para você.
Digamos que editemos o /root/.bashrc como:
$ sudo su -
Password: ******
# cat ~/.bashrc
echo "root bashrc file was read"
PATH=~/bin:$PATH
echo "$PATH"
export USERVAR=set
echo "$USERVAR"
umask 022
alias ll='ls $LS_OPTIONS -l'
alias l='ls $LS_OPTIONS -lA'
Vamos fazer logout e logar novamente para fazer o bash ler o arquivo:
# exit
$ sudo su -
root bashrc file was read
/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
set
root@here:~# alias l
alias l='ls $LS_OPTIONS -lA'
root@here:~#
Como você pode ver, o arquivo foi lido, o PATH foi alterado e os aliases foram definidos. Tudo está funcionando como você pede.
No entanto, o sudo ainda não funciona como você espera.
root@here:~# exit
$ sudo env | grep USERVAR # no output
$ sudo env | grep PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
O PATH não mudou. Pode haver maneiras de mudar o caminho em sudoers, mas eu recomendo strongmente que você evite fazer isso. E, de qualquer forma, aliases, funções e algumas outras mudanças ainda não serão aplicadas mudando apenas o PATH. Um arquivo precisa ser originado. Fazer isso para cada script ou comando pedirá ao computador para executar mais trabalhos sem qualquer benefício real. Script não usa aliases (não há uso prático para eles dentro de scripts).
Então, faça o login, o arquivo .bashrc será carregado automaticamente e funcionará.
Você pode começar o bash assim:
$ sudo bash
root bashrc file was read
/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
set
root@mail:/home/isaac/me/temp/clocks-master#
Mas, como você vê acima, o pwd (o diretório de trabalho) não foi alterado e, se você inspecionar um pouco mais, algumas outras configurações também não foram alteradas. É por isso que o comando correto é usar:
$ sudo su -
Se esse comando for muito longo para ser digitado, crie um alias ou uma função no usuário (não raiz) onde esse comando será usado, algo como:
$ alias mysu='sudo su -'
$ mysu
#
TL; DR: Você pode usar sudo -i para executar uma função definida /root/.bashrc (mas não um alias) e também ter acesso a variáveis exportadas desse arquivo:
sudo -i command arguments
Os aliases não funcionam lá, mas você pode facilmente convertê-los em funções se quiser disponibilizá-los para sudo -i .
Leia para uma análise completa e mais detalhes.
Existem alguns problemas aqui, alguns em como o sudo funciona e alguns em como o próprio bash funciona ...
Por padrão, sudo procurará apenas por comandos e ignorará o shell, portanto, simplesmente executar sudo ll só funcionará se houver um executável ll em um dos diretórios em $PATH . Então, para usar aliases (ou funções), você precisa ter certeza de que um shell é invocado como parte do processo.
Uma maneira seria executar algo como sudo sh ou sudo bash , embora o moderno sudo (estou testando isso no sudo 1.8.19p1) tenha opções -s e -i para essa finalidade. / p>
Portanto, uma tentativa seria algo como sudo -s ll (o que equivale a sudo bash -c 'll' , supondo que seu $SHELL seja Bash, o que parece ser o caso com base no rcfile que você mencionou.) Mas isso não Não trabalhe também, pois ele inicia o shell em um modo não interativo, não interativo, que não lê nenhum de seus arquivos de inicialização. É essencialmente o mesmo que se você escrevesse um script de shell e usasse #!/bin/bash para executá-lo. Os aliases (e funções) que você tem em seu ~/.bashrc não estarão acessíveis a partir desse script ...
O próximo passo é a opção -i , que cria um shell de login. Isso é mais promissor, já que irá ler seus arquivos de inicialização! E ainda assim, sudo -i ll (equivalente a sudo bash -l -c 'll' ) ainda não funcionará. Então, como isso é possível, dado que fez ler a definição do ll alias?
Bem, a próxima explicação aqui é que, por padrão, o bash não expande aliases, exceto quando o shell é interativo ... Este shell iniciado por sudo -i (ou bash -l ) é um login shell, mas ainda não é interativo.
O próximo passo é obter um shell interativo , que então funciona :
sudo bash -i -c 'll'
(Ter ambos login e interativo também é bom, é claro, bash -l -i -c ... funcionará.)
Outra alternativa é continuar usando um shell login (não interativo), mas solicitá-lo explicitamente para expandir os aliases. Isso também funcionará:
sudo bash -l -O expand_aliases -c 'll'
(O caso em que o bash era interativo não precisava de um shell login , já que isso é suficiente para ler os arquivos de inicialização, mas este precisa de -l para leia-os.)
Estas são linhas de comando bastante longas ... E elas também exigem que você cite o comando shell inteiro, então se você está chamando um alias com argumentos, você terá que transformar tudo isso em uma string ... Então é meio desajeitado usar ...
Note que antes eu estava falando sobre aliases e funções ... Isso foi proposital, já que as funções são muito mais convenientes aqui. Você não precisa de nada especial (como ter um shell interativo ou definir uma opção específica) para executar funções em um shell, contanto que você esteja obtendo sua definição.
Portanto, se você definiu ll como uma função em vez de um alias, poderá usá-lo diretamente com o atalho -i do sudo:
sudo -i ll
E se você tiver uma linha de comando mais longa, com argumentos, também poderá passá-los diretamente aqui:
sudo -i ll -C -R /etc
(Compare com sudo bash -i -c 'll -C -R /etc' .)
Funções também são muito mais flexíveis e geralmente mais fáceis de manter ... Geralmente é fácil converter um alias em uma função, a única ressalva é sempre usar "$@" onde você espera que argumentos extras sejam obtidos ( normalmente no final do alias.)
Por exemplo, esse alias:
alias ll='ls $LS_OPTIONS -l'
Pode ser transformado nesta função:
ll () {
ls $LS_OPTIONS -l "$@"
}
Eles são, na maioria dos casos, equivalentes. E, como mencionado anteriormente, a função deve ser acessível diretamente de sudo -i , então isso é um bônus adicional.
Espero que você ache esta resposta e explicação úteis!