Acabei de testar no debian "etch" e "sarge", e como teste acrescente
aum usuario comum no .bash_profile dele coloquei :
echo "executando menu"
exec ~/menu.sh (testei tambem exec /home/usuario/menu.sh)
Se tento o login onde o shell é /bin/sh o script menu.sh não é carregado.
Se troco de volta para /bin/bash ele então é carregado.
/bin/sh continua apontando para /bin/bash
No caso do "etch" é uma instalação limpinha :
apt-cache policy bash
bash:
Instalado: 3.1dfsg-8
Candidato: 3.1dfsg-8
Tabela de versão:
*** 3.1dfsg-8 0
500 http://linorg.usp.br etch/main Packages
100 /var/lib/dpkg/status
man bash :
If bash is invoked with the name sh, it tries to mimic the startup
behavior of historical versions of sh as closely as possible, while
conforming to the POSIX standard as well. When invoked as an interac‐
tive login shell, or a non-interactive shell with the --login option,
it first attempts to read and execute commands from /etc/profile and
~/.profile, in that order. (...)
[]'s e sucesso.
Em 23/02/07, Bruno Schneider<boschneider@gmail.com> escreveu:
On 2/22/07, Maxwillian Miorim wrote: > On 2/22/07, hamacker wrote: > > Mas voltando ao tema do assunto, a partir de alguma atualização do > > debian, o bash ignora ~/.bash* se for carregado por um link > > simbolico, portanto, /bin/sh não vai chamar ~/.bash* enquanto > > /bin/bash funcionará sem problemas. > Eu não sabia disso, apesar de não usar os "~/.bash*", é > interessante... Ajuda a explicar algumas coisas que não funcionam em > alguns casos :D Isso não parece correto. Hamacker, poderia citar uma referência? Testei aqui com o bash 3.1.17 (chamado a partir de um link simbólico) e ele interpretou o .bashrc. Acho que estás confundindo com o fato que o bash não interpreta os .bash* quando chamado como "sh". -- Bruno de Oliveira Schneider http://www.dcc.ufla.br/~bruno/