Invocation and startup file compatibility with OpenSSH

[James]

Can someone help me out here?

I was having trouble running the OpenSSH version of scp and discovered that
the problem occurs because the remote shell generates text output (in my
case) when calling the ~/.bashrc startup file.  (OpenSSH_2.3.0p2 with Bash
2.03.8(1)-release and with Bash 1.14.7(1) on RedHat 6.2)

Here's the problem:

1) scp selects the remote users /etc/passwd defined shell, /bin/bash in my
case, and uses execve to call it with "/bin/bash -c scp ..."

2) I call /etc/profile - which generates text output from "echo", "date",
and "tty" - from ~/.bashrc because I start non-login interactive shells from
~/.profile on my virtual terminals (open -c <vtnumber>), and I want the same
initialization as for my single login-interactive shell.

3) BASH(1) from 2.04 explicitly says

       Bash  attempts  to  determine  when it is being run by the
       remote shell daemon, usually rshd.  If bash determines  it
       is  being run by rshd, it reads and executes commands from
       ~/.bashrc, if that file exists and is readable.   It  will
       not  do  this  if invoked as sh.  The --norc option may be
       used to inhibit this behavior, and the --rcfile option may
       be  used  to  force another file to be read, but rshd does
       not generally invoke the shell with those options or allow
       them to be specified.

4) scp fails when the text is generated.

Can someone tell me what's right and wrong here?  Normally, bash shouldn't
read ~/.bashrc because it's invoked by ssh as a non interactive shell, but
here bash goes out of its way to read ~/.bashrc because it's being run by a
remote shell daemon.

Is openssh wrong to fail from text output?  (So far, they say no.)

Is there some other way to read /etc/profile but NOT read ~/.profile when
        using "open -c <vtnumber>"?

Is there some particular reason why bash reads ~/.bashrc when run by a
        remote shell daemon?

Can bash read some _different_ startup file when being invoked by a remote
        shell daemon and as a non interactive shell?

Thanks


James Feeney