Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Filename completion in Apollo's C shell
Message-ID: <4e4240ee.1bc5b@pisa.ifs.umich.edu>
Date: 27 Nov 90 15:24:27 GMT
References: <1200@prlhp1.prl.philips.co.uk> <2171@tuvie> <11670@milton.u.washington.edu>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 27

In article <11670@milton.u.washington.edu>, etb@milton.u.washington.edu (Eric Bushnell) writes:
  Yeah, but it don't work! My apollos running SR10.2 and BSD4.3
  won't complete file names properly either. From the console,
  they just ignore ESC or ^L or whatever.

That's because you're running your shell from a DM pad.  Pads aren't ttys.
They let you do things like edit the input before it gets eaten by your
shell, at the expense of things (like completion) that require line breaks
at other than newline boundaries.  Pads are great and some of us like them,
but they are not vt100s.

If this bothers you, it's easy enough to fix.  Just run your shell from an
xterm instead of from a pad.  I usually have a couple of pads and an xterm
open at the same time so I can pick whichever one I want to use at any
particular time.

Some day someone should write the perfect terminal emulator.  It would
behave a lot like a DM pad when it was in cooked mode, and a lot like an
xterm when it was in raw mode.

  From a dial-up vt100
  terminal, they'll complete the name, but overwrite part of the
  command line in the process (faulty termcap?).

This is a bug.  It seems to be a bug in the csh, not the termcap entry,
since it does this regardless of your terminal type.  Someone should send in
an APR (I don't do APRs any more).