🚀 go-pugleaf

In article <77373@eerie.acsu.Buffalo.EDU> pjg@acsu.buffalo.edu (Paul Graham) writes:
>[is this a real person?]
>lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes:

No; they won't give us individual accounts here, so a bunch of us use this
one, with subdirectories set up for each of us, and a .$USER file for each
to do his/her/its own personal login tailoring.  It's lots of fun to try to
sort out news and mail to a shared account; you should try it sometime.  We
do have fun reading each others' mail and all that, especially flames that
come in from questions on various newsgroups.  But then, we keep finding
useful morsels among the flames, and we don't mind if they are well-done,
so we keep using rn in one window, notes in another, and complaining that
they can't get together...

>|Ummm...UUCP over TCP has been in existence for years; quite a lot of
>|vendors supply it.
>|. . . it is a whole lot nicer than ftp. It retries if
>|the call doesn't go through; it does proper error checking and doesn't
>|hand you garbaged files;
>
>eh?

Well, just a week or so ago, I tried ftping over to lcs.mit.edu to fetch
a copy of something useful, and it took three tries before ftp could get
the tar.Z file across intact, and then zcat|tar couldn't unpack it.  When 
I ran a hexdump of it, there were big chunks (whose sizes were a multiple 
of 512) that were filled with nulls.  This isn't new.  I have a little 
program that merges files that contain null chunks, and complains if the 
non-null parts don't agree.  If I give it 3 or more files, it uses the 
obvious voting algorithm for each byte, and only complains if there are 
chunks on which no two files agree.  It sure comes in handy at times. 
(All the grumbling about the turkeys who think their file-transfer package 
works; they have a very strange definition of the term. ;-)

Sure, ftp works fine across a single Ethernet.  It usually works if you
have one or two bridges or gateways to cross.  But everywhere I've worked,
it has problems on some links, and its way of failing is to tell you that
it has copied the data, when large chunks are null or garbage.  I'm tired
of complaining to vendors about it; I've never once seen the problems get
fixed (and it's been nearly 10 years now).  They just run tests on their 
in-house network, there aren't any problems there, so they dismiss me as 
an idiot who obviously must be misusing this wonderful tool.

In my experience, you should always install as many file-transfer packages 
as you can get your hands on, to increase the probability that maybe one 
of them will work in a particular situation.  UUCP is generally the best 
(in the sense that if it tells you it succeeds, then the data is always 
there and intact), but between an arbitrary pair of machines, there is 
a very small chance that you can make UUCP work, because you can't get 
a physical connection that is compatible with any of the drivers that 
the two ends' UUCPs have in common.  Kermit also works well (when you
can get it to work at all) but is slow and requires constant handholding, 
and isn't in the libraries supplied by very many vendors.  Rcp usually 
just says "Permission denied" and you can't figure out what the security 
rules are this time.  Tftp works in some cases where ftp fails, but it 
but tftpd isn't installed nearly as widely as ftpd.  The dcp command 
works if you are luck enough to have DECnet on both ends, but these days 
you can't get a DECnet address, and in any case, dcp only succeeds if 
you are the receiver; it invariably fails its security checks if you 
try downloading to another machine.  And so on.

Another constant problem is that ftp is inherently interactive; if you 
run it from a script, it has totally bizarre and baffling behavior; it
certainly doesn't copy the files.  Making this work seems to require 
renaming /dev/tty (which means being super-user), and this breaks any 
other application that tries using /dev/tty during the copy.  Again, 
when you ask questions, you get treated like an idiot.  (Why would you 
want to write a script in one of those user-unfriendly shell languages 
when you can do the job so easily by hand every time? ;-)

Of course, there is also the approach of uuencode+uusplit+mail, with 
the inverse transformation at the other end...

Sigh.