Re: The Links/Links2/ELinks browsers are unusable on Debian GNU/Hurd

On Sat, 15 Dec 2007 22:36:21 +0200, Kalle Olavi Niemitalo <[email protected]>
wrote:
> This suggests ELinks has failed to disable echoing at the terminal.
> Please verify this by looking up the tty that ELinks is using and
> checking the modes with a command like this:
>
>   stty -F /dev/pts/1 -a
>
> ELinks should have enabled and disabled tty modes as follows:
> -icrnl -ixon -icanon -iexten -echo isig tostop.  And also the
> following, which may already be the default: -ignbrk -brkint
> -parmrk -istrip -inlcr -igncr opost -echonl cs8 min=1 time=0.

   If I run ELinks on an xterm and then check the modes of that
terminal I get:
speed 38400 baud; rows 28; columns 84;
intr = ^C; quit = <undef>; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; status = ^E; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff
-iuclc -ixany imaxbel
opost -olcuc onlcr
isig icanon iexten echo echoe echok -echonl -noflsh -tostop -echoprt echoctl
echoke
  They are not correctly set then ...

> If ELinks fails to set the modes, put a breakpoint at
> src/terminal/kbd.c (setraw) and see whether execution gets there
> and whether the tcsetattr call succeeds and has the intended
> effect.

   ... but the tcetattr call succeeds: when the breakpoint at setraw is
reached, the output of stty -F /dev/ttyp1 -a is the same as above, but
after the execution of the line 242:
if (tcetattr(fd, TCSANOW, &t)) return -1;
it is:
speed 38400 baud; rows 28; columns 84;
intr = ^C; quit = <undef>; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; status = ^E; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany imaxbel
opost -olcuc onlcr
isig -icanon -iexten -echo echoe echok -echonl -noflsh tostop -echoprt echoctl
echoke

    I've found that the function free_itrm is called later and it unsets
these modes.  It is called by select_loop line 305 while i = 7 and n = 1.

> ELinks catches SIGINT and translates it to an event internally.
> It's odd though that it doesn't handle the event immediately.

    Indeed, I don't know if it catches it.

> Please show the value of *ditrm, especially ditrm->blocked.

   Just before the execution of free_itrm:
$2 = {in = {std = 0, sock = 1, ctl = 0, queue = {data = 0x8187e10 "", len = 0}}, 
  out = {std = 1, sock = 7, queue = {data = 0x8187e80 "", len = 0}}, timer = 0x0, 
  t = {c_iflag = 8454, c_oflag = 3, c_cflag = 2816, c_lflag = 1487, 
    c_cc = "\004ÿÿ\177\027\025\022\b\003ÿ\032\031\021\023\026\017\001\000\005\b", 
    __ispeed = 38400, __ospeed = 38400}, mouse_h = 0x0, 
  orig_title = 0x8192720 "xterm", blocked = 0, altscreen = 1, touched_title = 1, 
  remote = 0}
and after the execution of free_itrm ditrm==NULL.

> Does execution ever reach in_kbd?

No.

> It doesn't hang here, on Linux 2.6.  Instead, in
> connect_to_af_unix, connect fails with ECONNREFUSED,
> and ELinks retries that a few times and gives up.

    That does not seem to work with Hurd/GNU-Mach, but that reminds me
that sometimes when I start ELinks I have the error:
ERROR at interlink.c:329: The call to connect() failed: 1073741873
(Cannot assign requested address)
but I haven't found how to reproduce that.

-- 
Fabienne


-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]