🚀 go-pugleaf

I've recently installed tcsh on both my home NeXT and our office one
and have generally been quite pleased with the added features.  One 
anomaly has cropped up though, and I'm completely stymied on what is 
causing it.  Perhaps some kind person in netland can offer some help?

Specifically, I log in from home to the office machine via a 2400
baud modem (when, oh when, will my #$%&%^& Supra get here?!) using 
tip.  For file transfers I've found that a 100% reliable method is
compress->uuencode->~t (or ~p)  i.e. the built in tip functions for "take"
and "put".  while not exactly state of the art, I tried various options
with kermit, sz, etc. etc. and found that this ALWAYS worked perfectly,
which is what I really care about.

Okay, here's the puzzle:  now that I've installed tcsh on the NeXT we have
at work (antioch, from which you now get all my mail) I find that this
won't work anymore.  If I say, "take" a file everything goes normally up
to the transfer, in that

[take] foo

on the remote machine antioch makes a file called foo on the near machine
(feynman) but it has 0 bytes and then the window just locks up, as if
the machine is sitting there waiting for some sort of signal to actually
send any of the file.  This is a real pain since I have to kill the window,
remove the modem lock, call up again, etc. etc.  Note that this does
not happen if I switch back to csh [i.e. typing /bin/csh before the [take] ]
before doing the transfer.  Also, it does not happen using tcsh on the
Suns, and it does not matter what shell I am using on the local machine
and I can "put" files just fine (unfortunately, 99% of the time I need
to "take" them).  

A little investigation (with the help of Scott Hess) suggests it has to
do with the "literal next" aspects of the terminal.  
The problem is how the take command works.  From the tip manual page:

     ~t from [ to ]
               Take a file from a remote UNIX host. As in the put
               command the ``to'' file defaults to the ``from''
               file name if it isn't specified. The remote host
               executes the command string ``cat 'from';echo ^A''
               to send the file to tip.

with ^A being control-A.  To get control-A you type ^V^A (control-A control-V)
because ^V is the "literal next" identifier.  I can type ^V^A on either
my personal or the office machine ***locally**** (i.e. in a Stuart window)
and everything works just fine, but if I type ^V^A on the office machine
remotely (i.e. logging in over the phone) I instead get a ^M (Scott was able
to reproduce this behavior) which causes the tip command to go unexecuted
(and explains why "put" works).  

Can anyone offer an explanation and/or workaround?  It's no big deal in 
that I can always just switch to csh before file transfers, and once my
fast modem arrives I'm going to a SLIP connection anyway, but I'd like
to know what's going on.

Thanks in advance   ---- Tom