GBOPOLY1@NUSVM.BITNET (fclim) (08/14/89)
The Domain/OS man pages (BSD) on C SHELL sez that Apollo has implemented
the filename expansion facility. Suppose
% ls
bar foobar haha
then if we
% set filec
we have switched on this facility. Now, when we type
% vi f<ESC>
C shell will expand the line to
% vi foobar
This works with ~user; suppose we wish to replace user ah-fock's .cshrc
with user ah-lok's version, we may (as root) in a C shell, type in
% cpf -r ~ah_l<ESC>
which becomes
% cpf -r ~ah_lok
where we continue typing
% cpf -r ~ah_lok/.cshrc ~ah_f<ESC>
which expands to
% cpf -r ~ah_lok/.cshrc ~ah_fock
assuming that there are no other user with the prefixes ah_l or ah_f.
This works in a DM shell input pad. My question is: will this still
work if we change the default DM's definition of the <ESC> key? What
happen if we
% /com/xdmc kd esc ke
or
% /com/xdmc kd esc cp /bin/csh ke
(Please don't ask me why I know about this when I do not have SR10+;
it's a long story).
While we are talking about the DM interfaces with a C shell (or Unix
shells), I like to bring something similar up.
At SR9.7 (and at least at SR10.1), the Unix command "stty" has a lot
of no-ops on DM input pads. For example, suppose that when I login,
the DM defines the keys as in /sys/dm/std.basics instead of /sys/dm
/std.unix or similar. Thus ^Z is EOF. Now, if I issue the command
% stty eof ^D
stty will not issue any warning; but the EOF char is still ^Z.
Similarly, the following is a no-op
% stty -echo
These stty options and others work if we pull the pad into PAD_$raw mode
via /com/vt100, telnet, rsh, rlogin, etc. But then, we will lose the
scrollability and the quarter-plane
of the transcript pad since when we enter PAD_$raw mode,
we lose the transcript pad.
There are times when I like to invoke
% make :: echo "make returns OK^G" &
ie if make returns 0, a message is printed. Because this
is put into the background, this message can be confused with output
from the foreground job. So I put in a bell, ^G. But I can't get
this to work at SR9.7; I'm not sure about SR10+. I do not wish to
resort to SysV echo (/sysV/bin/echo "make returns OK\07") or vt100
or to use vi to create a file with a bell in it and then cat that file.
Is it possible to write the OS so that the DM filters keystrokes
to a /com/sh pad, but when we have a Unix shell (either through
"cp /bin/{csh,ksh,sh}" or "cp /sys/dm/login_sh"), the DM only filters
the grey keys but leave the cooking to the line discipline for the
other white keys? Of course, the DM still have the task of sending
the keystrokes only to the pad under the cursor (context).
I'd love to change the world
But I don't know what to do
So I leave it up to you
Alvin Lee (Ten Years After)
fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu
computer centre
singapore polytechnic
dover road
singapore 0513.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Add your pet peeve
If we think really hard, maybe we can stop this ____!
No ____! No ____! No ____!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=