Re: lynx-dev partial not working on ftp:// url's (?)

[Kim DeVaughn]

On Tue, Jul 20, 1999, Klaus Weide (address@hidden) said:
|
| > And it is the only (or 2nd) ^G that causes "Data transfer interrupted."
| > to be displayed (along with the 1st screenfull of the dir list received
| > thusfar).  Without that ^G, lynx will just sit there, showing a blank
| > screen, and the (now static) "Transferred NNNNN bytes" message.
|
| What if that 2nd key is something else than ^G - like 'z' or '^L' or
| down arrow?

They have no effect (other than say, ^Z, which does the expected thing,
which BTW after fg'ing back to the lynx process, returns to the same
"state" ... blank screen, except for the now static xfer counter in the
statusline position).

Only a ^G at that point will initiate the on-screen rendering (with either
"z" or ^G used to interrupt the xfer itself).


| (I never use ^G for anything except cancelling a prompt or line
| editing - it seems weird to me to use it where 'z' should be used.)

Heh.  IIRC, a ^G has always interrupted an access attempt (or actual data
xfer) for me.  That includes aborting an access attempt to an apparently
"slow" or "hung" link.

This behavior goes back to at least 2.8.1rel.1, and probably earlier.

Which I suppose is the reason that I've never understood the rationale for
adding the NSL/"z" network INTERRUPT code.  Guess I've just always assumed
that the ^G method was an inbuilt emacs'ism, which worked on my particular
platform, but maybe wasn't doing "the whole job" on other OS's, etc (hence
the need for the NSL/"z" code).

I dunno which key I use more frequently ("z" or ^G) to halt a network access
attempt, and/or an xfer in progress, as both (seemingly) do exactly the same
thing (for me).  Guess it's about a 50/50 split, depending of which key is
closest to my left index finger at the time (yes ... I "hunt and peck" ...
always have).


| What does the lynx process do while it just 'sits there', is it using
| CPU time (some loop), does it still have network sockets open?

It's in S(leep) state, and not *really* using any CPU to speak of (I left
a lynx in that state for ~6+ hours, and it used 0.7 CPU secs during that
period ... so no, no "hang loop").

I don't *think* it has a socket open, though FreeBSD's netstat(1) command
does not make it easy to tell.


| In any case, a TRACE should give a better idea where things are stuck.

Immediately following a "z" *or* a ^G, the trace log shows:

 >GridText:     add link on line 2770 col 37 [1965] in HText_trimHightext
 >Gridtext: Anchor found on line:2771 col:37 [1966] ext:13
 >anchor text: 'Aug 29  1997  UNIX Compressed  [1966]alt.ƒï®$†.Z  684 bytes'
 >GridText:     add link on line 2771 col 37 [1966] in HText_trimHightext
 >Gridtext: Anchor found on line:2772 col:37 [1967] ext:14
 >anchor text: 'Oct  7  1997  UNIX Compressed  [1967]alt.²Â§¨©.Z  1Kb'
 >GridText:     add link on line 2772 col 37 [1967] in HText_trimHightext
 >Gridtext: Anchor found

After the next ^G (to initiate the rendering), and a down arrow (which forces
a fflush() to the trace log) it shows:

 >GridText:     add link on line 2770 col 37 [1965] in HText_trimHightext
 >Gridtext: Anchor found on line:2771 col:37 [1966] ext:13
 >anchor text: 'Aug 29  1997  UNIX Compressed  [1966]alt.ƒï®$†.Z  684 bytes'
 >GridText:     add link on line 2771 col 37 [1966] in HText_trimHightext
 >Gridtext: Anchor found on line:2772 col:37 [1967] ext:14
 >anchor text: 'Oct  7  1997  UNIX Compressed  [1967]alt.²Â§¨©.Z  1Kb'
 >GridText:     add link on line 2772 col 37 [1967] in HText_trimHightext
 >Gridtext: Anchor found on line:2773 col:37 [1968] ext:29
 >anchor text: 'Aug 30  1997  UNIX Compressed  
 >[1968]alt.ï®$.©hü®©h.ømøLëÿ©®üë.Z  2Kb'
 >GridText:     add link on line 2773 col 37 [1968] in HText_trimHightext
 >HTFormat: Interrupted in HTGetCharacter
 >HTFTP: Interrupted in HTGetCharacter, apparently.
 >Data transfer interrupted.
 >HTAccess:  status=200
 >HTAccess: `ftp://ftp.isc.org/usenet/control/alt' has been accessed.
 >HTParse: aName:ftp://ftp.isc.org/usenet/control/alt   relatedName:
 >HTParse:      result:ftp.isc.org
 >HTParse: aName:ftp://ftp.isc.org/usenet/control/alt   relatedName:
 >HTParse:      result:ftp
 >HTParse: aName:ftp://ftp.isc.org/usenet/control/alt   relatedName:
 >HTParse:      result:ftp://ftp.isc.org
 >HTParse: aName:ftp://ftp.isc.org/usenet/control/alt   relatedName:
 >1
 >HTParse:      result:/usenet/control/alt
 >Starting realm is 'ftp://ftp.isc.org/usenet/control/'
 >
 >GridText: HText_pageDisplay at line 1 started
 >GridText: HText_pageDisplay finished

Note that I get identical traces whether interrupting the xfer with either
"z" or ^G (excepting, of course the line numbers, which depend on exactly
when I hit the 'rupting key, from run-to-run).


| Is this only with -partial enabled?

Well "partial" is defaulted to normally on, and adding "-partial" to the
command line should toggle it off, I believe.  I get the same results
with or w/o "-partial".

Haven't tried a build with "partial" compiled out (nor with NSL disabled,
for that matter).  A couple things to try and isolate the behavior(s), I
suppose ... maybe later on today ...


| If not, it may have something to do with the following (end of read_directory
| in HTFTP.c):

| Maybe 'the response(NIL) below hangs' is true not only for those
| server types, but also for others.  I added that NETCLOSE a long
| time ago, when testing with those weird servers seemed to show
| that they needed it, but didn't add it for cases I didn't know
| about.  It should probably also be done if WasInterrupted is true
| at that point (please test, I don't want to start loading
| multimegabyte directory listings now..).

Another thing I'll look into, if any of the above information doesn't add
anything to your speculations (as I expect it won't).

/kim