From: utzoo!decvax!ucbvax!ARPAVAX:C70:info-cpm
Newsgroups: fa.info-cpm
Title: Plink bugs/features
Article-I.D.: ucb.2132
Posted: Wed Oct 13 00:15:41 1982
Received: Mon Oct 25 02:26:30 1982

>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.