Ray Daoud wrote:
>
> On Sat, 6 May 2000, Sami Lehtinen wrote:
>
> > Do the user's shell scripts output something to stdout? This
> > would mess with the filexfer-protocol.
> >
> > (for example,"echo foobar" in .cshrc would do something like this.)
>
> Yes, we have also narrowed this problem down on our site to the "set
> prompt" command in users .cshrc files.
>
We found it isn't necessarily the "set prompt". In our individual
.cshrc files, we all source a common Cshrc file which sets the prompt
as:
set prompt="`hostname` {`whoami`} \!: "
Most people continue to use this, but some like I use other forms:
set prompt="`hostname`{`whoami`}:`echo $cwd`\!: "
Over the years people tend to collect things in their .cshrc based on
what they see work for others or settings needed for long-forgotten
group projects. On one of my users' you could see the error print when
his .cshrc sourced another file, which itself tried to source a
non-existent third. Another user however sourced a file which did not
provide any feedback for the error.
This calls for housecleaning of users .cshrc files to make it work. Of
course, most will call on their system administrators, saying SSH
doesn't work. And then we have to assist in finding the fault in what
they've wrongly written into their .cshrc files ("oh yeah, I always get
that error; I just ignore it").
But I do agree, if the connection is already made, the file transfer
agent doesn't really need to be re-sourcing the login files.
--
Jeff Bailey 371 ARL
Info Tech Associate PO Box 30
[EMAIL PROTECTED] State College, PA 16804
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Applied Research Laboratory, Penn State University