ARPAVAX:C70:info-cpm (10/13/82)
>From w8sdz@BRL Wed Oct 13 00:15:18 1982
From: Boebert.SCOMP at MIT-MULTICS
Subject: Plink bugs/features
To: w8sdz at BRL
I have encountered the following using PLINK to transfer files to
Multics over an ordinary (non-network) dialup link:
1. PLINK appears not to accept console line editing commands in the
filename field, i.e., M<backspace>NEW will not match a file named NEW.
---This is because PLINK does not use the CP/M buffered-console input
call. Reason: it's possible to ^C out of that and lose your whole
PLINK session. I agree, it would be nice if the PLINK filename input
accepted backspaces. Right now, they go into the filename field and
create a CP/M filename with ^H in it - NOT GOOD. This is not easily
fixed with the present routine. Trapping control characters would
make it ignore the carriage return that terminates in the filename.
2. When the line contains tabs, PLINK will occasionally die or lockup,
and you have to ctl-c out of it. Expanding the tabs to spaces seems to
cure this. This phenomenon appears especially pronounced when the line
is short, as when you have used tabs to generate whitespace in a very
sparse table.
---When you are sending a file with PLINK, if you are sending into a
program that expands TABs, things get confused when you send them.
It's better to PIP newfile=oldfile[t8] to expand the tabs before you
send the file. It would be nice if PLINK had a time-out feature in
that area where it is looking for the LF character to know when to
send the next line. The time-out would have to look for (x) seconds
of no characters received. This could be a problem on time-share
systems where there may be many seconds of no characters due to system
load.