> and with this change .bashrc is never sourced. Will we do something with > this? Changing check from socket to pipe stdin will cause problems with > older ssh. Maybe defining SSH_SOURCE_BASHRC? Or just don't do anything?
This is the reaason that SSH_SOURCE_BASHRC exists, but you have to accept the consequences of enabling it. Changing the shell to check whether stdin is a pipe and sourcing the .bashrc in that case will cause havoc -- every invocation of bash -c by a program that uses a pipe for input and output to that shell will cause the .bashrc to be sourced. This seems like something that would cause more trauma than would be worth it. The problem with SSH_SOURCE_BASHRC is that it looks for environment variables set by sshd that persist across shell invocations. This means that other programs running bash to execute non-interactive commands with `bash -c' will result in sourcing .bashrc, with unpredictable consequences. This isn't that great, either. So far, neither solution has been clean enough for me to consider changing the current behavior. Ultimately, you'll have to decide what is best for your customers, but you should at least know what you'll potentially be in for. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU [EMAIL PROTECTED] http://tiswww.tis.case.edu/~chet/
