[links-list] bugs from Debian big tracking system

Peter Gervai grin at tolna.net
Wed Jan 30 03:08:25 PST 2002


The new ones since my last report. (I'll review the old ones when I
install the pre1 version, but I suspect they're not fixed.)

The 'euro' symbol ( €  entity ) is not supported by links browser

 Construct such as:



 Results in one single unnumbered list, i.e. there isn't an empty line
 between the two. This should be fixed, as all other browsers I've tried do
 insert an empty line in there, and it does seem logical not to join two
 lists if the code says it's two lists.

 links has a feature whereby it can invoke a new instance of
 itself in another xterm.  It uses the system() function to do
 this, so it has to escape the use of unsafe characters in the
 shell.  It does so by translating each of them from its original
 form into "+XY", where X and Y are hex digits.  When the new
 instance starts up, it translates the three-character sequences
 back to single characters.

 Unfortunately, this is not restricted just to URLs that have been
 passed to links by another invocation of its.  It can backfire in
 some cases, because URLs are decoded that were never encoded.
 For instance, invoking links to browse the following Google query
 URL will have the "+ba" replaced by a single character, resulting
 in a useless failing query:
         links 'http://www.google.com/search?q=foo+bar'

 This kind of query is easily constructed with the Debian
 "surfraw" package with a shell command like
         google foo bar
 and the results are confusing, to say the least.

 The solution is to prevent links from decoding URLs that it never
 encoded.  One approach would be for links to pass its
 subprocesses URLs by a new command-line option; e.g.,
 "-encoded_url URL".  A simpler approach, though, is to just have
 links prepend a unique string to its URLs upon encoding and
 recognize and strip that string upon decoding.  One good choice
 of prefix is "links:", because that's an invalid URL scheme, but
 in fact :' is one of the characters that gets encoded.  I chose
 "links+" instead.  Here's a minimal patch that fixes the problem
 that way.  I've tested this against the current links package,
 but it should also apply without changes to the links-ssl

 --- session.c~  Fri Jan  4 23:45:01 2002
 +++ session.c   Fri Jan  4 23:42:44 2002
 @@ -1290,6 +1290,8 @@
         unsigned char *u = init_str();
         int l = 0;
 +        add_to_str(&u, &l, "links+");
         for (; *url; url++) {
                 if (is_safe_in_shell(*url) && *url != '+') add_chr_to_str(&u, &l, *url);
                 else add_chr_to_str(&u, &l, '+'), add_chr_to_str(&u, &l, hx(*url >> 4)), add_chr_to_str(&u, &l, hx( @@ -1301,6 +1303,11 @@
         unsigned char *u = init_str();
         int l = 0;
 +        if (strncmp(url, "links+", strlen("links+"))) {
 +                add_to_str(&u, &l, url);
 +                return u;
 +        }
 +        else url += strlen("links+");
         for (; *url; url++) {
                 if (*url != '+' || unhx(url[1]) == -1 || unhx(url[2]) == -1) add_chr_to_str(&u, &l, *url);
                 else add_chr_to_str(&u, &l, (unhx(url[1]) << 4) + unhx(url[2])), url += 2;

wishlist items - NOT BUGS:

 I'd like to use the scroll wheel in links under X (gnome-terminal). :)
 When switching between source view and rendered view, the position of
 the view is based on the page number of the previous view -- i.e. if I
 switch from rendered view at page 4 to source view, the source view
 will be positioned at page 4 of the source code, instead of the code
 corresponding to the stuff rendered on page 4.

 When I try to use links at a Wyse 60 terminal, I see all the escape
 sequences on the screen.  They must be escapes sequences for either
 vt100 or linux terminals.  My WYSE 60 terminal works fine with lynx.

 Then on my other terminal (almost a vt100) lynx will work only if I
 set the terminal to no parity and 8-bits/char.  But I have it set by
 default to odd-parity and 7-bits/char and this works fine with lynx,
 etc.  Stty shows the same.  Then when I start links, it changes the
 "stty" settings to no-parity and 8-bits/char.  Since the terminal
 itself (done by the "set-up" key on the terminals) is still set to
 parity and 7-bits/char, I get mostly error characters on the screen.
 Since a lot of documentation is in gzipped html format, it would be
 useful if links had an option to take html from stdin like this:

         gunzip -c index.html.gz | links -stdin

 similar to how one can pipe html to "lynx -stdin" or "w3m -T text/html".
 (Or if this feature already exists, I can't find it documented anywhere.)
 Any possibility of adding it?
 It would be nice when links can handle *.gz files like lynx or netscape.

 In the links menus, the scroll up/down functions should wrap around.

 I.e., if the cursor is on the top item of the File menu, and I press the up
 arrow, I would expect that the cursor wraps around to the last entry of the
 File menu, i.e. "Exit" (when I press the down arrow then, I should be back
 again at the topmost item of the menu).

 The left/right cursors in the menu bar work this way, btw.
 This file:

 <html lang="ru">
 <META http-equiv="Content-Type" content="text/html; charset=koi8-r">

 links displays as:

 mozhete prekratit' obschat'sya po vengerski?

 but lynx displays it as:

 mo 3/4ete prekratit' obschat'sya po vengerski?

 Notice the difference -- lynx did the right thing and converted the third
 Cyrillic character into  3/4' (Latin small letter z with caron) while links
 did the suboptimal English-centric thing and converted it to `zh'.

 The character is set to ISO 8859-2, yes.

Unsubscribe: send email to links-list-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message

More information about the links-list mailing list