On Wed, 21 Jul 1999, Reinoud Zandijk wrote:

>   >> Attempting to fetch slang-1.3.7.tar.gz from
>   http://gd.tuwien.ac.at/editors/davis/slang/v1.3/.
>   Requesting
>   http://gd.tuwien.ac.at/editors/davis/slang/v1.3/slang-1.3.7.tar.gz
>   Redirected to http://gd.tuwien.ac.at/.missing/gd.html
>   Requesting http://gd.tuwien.ac.at/.missing/gd.html
>   100%
>   |**********************************************************************|
>   2326     102.34 KB/s    00:00 ETA
>   2326 bytes retrieved in 00:00 (39.25 KB/s)
>   ismaelda# 

Yes, I'm able to reproduce the problem. The redirect cause an error
page to be downloaded as /usr/pkgsrc/distfiles/gd.html, but ftp return
success anyway! "ftp" with the -o option still downloads the error
page to gd.html, not slang-1.3.7.tar.gz. Ftp servers occasionally
return an error message which goes in place of the tar.gz file, but
then the checksum fails and FAILOVER_FETCH does it's job. In this
case, there is no tar.gz file at all, so the checksum target balks.

I consider this a bug in ftp. On a redirect, the file fetched should
be saved as the requested name. What if the redirect was for a valid
tar.gz archive? Then it could get saved to a different file name where
the subsequent make targets would never find it. Even in the case
where it's only a stupid error message, at least the behavior would be
consistent with the non-redirect case.

If there are good reasons for ftp to behave this way, then perhaps the
checksum target could be modified to do the right thing when the tar
file doesn't exist.

> Well, I hope the problem is a bit clear now. I got Lynx to work, but the
> cursorkeys are still not functioning properly; also in bash.

Sounds like a termcap problem. Try experimenting with "tset".