Re: lynx-dev Re: lynx should respect LANG

[Henry Nelson]

> > a certain Windows' FTP program cannot make whole-directory transfers from
> > a Solaris [version 2.6, later versions may be fixed] server with Japanese
> > NLS setup system-wide.  The reason is that the WSFTP does a "dir" command
[...]
> To bring it on topic, how does lynx fare with it?

(Can Lynx do recursive ftp fetches of all files and sub-directories under a
directory?  [-- No, of course.])

To answer your question, not very well.  Lynx also seems to take the
first line of the directory listing as a file.  But worse than that is
that it assumes the file or directory name is ALL the user/group/size/
date information prefixed to the file name (see the References section).
Weird; never seen this on any server before.  Here's an example:

% cd TEST
% /bin/ls -al  <<== only with /bin/ls; /usr/ucb/ls uses English "total 26"
$B9g7W(B 26
drwxr-xr-x   3 henry    user     512  6$B7n(B  1$BF|(B  10:57 .
drwxr-xr-x  24 henry    user    1024  6$B7n(B  1$BF|(B  10:53 ..
-rw-r--r--   1 henry    user    5712  6$B7n(B  1$BF|(B  10:55 .mailcap
drwxr-xr-x   2 henry    user     512  6$B7n(B  1$BF|(B  10:58 tannin
-rw-r--r--   1 henry    user    2678  6$B7n(B  1$BF|(B  10:54 toiapps
-rw-r--r--   1 henry    user     259  6$B7n(B  1$BF|(B  10:54 wglog1422

In lynx, the above appears as:

Current directory is /home/henry/TEST

   [1]Up to henry

     * text/plain       
     * text/plain       [2] henry    user     259  6$B7n(B  1$BF|(B  10:54 
wglog142
     * Directory        [3] henry    user     512  6$B7n(B  1$BF|(B  10:57 .
     * Directory        [4] henry    user     512  6$B7n(B  1$BF|(B  10:58 
tannin
     * Directory        [5] henry    user    1024  6$B7n(B  1$BF|(B  10:53 
..
     * text/plain       [6] henry    user    2678  6$B7n(B  1$BF|(B  10:54 
toiapps
     * text/plain       [7] henry    user    5712  6$B7n(B  1$BF|(B  10:55 
.mailcap

References

   Visible links
   1. ftp://address@hidden/home/henry
   2. 
ftp://address@hidden/home/henry/TEST/%20henry%20%20%20%20user%20%20%20%20%20259%20%206%B7%EE%20%201%C6%FC%20%2010%3A54%20wglog1422
   3. 
ftp://address@hidden/home/henry/TEST/%20henry%20%20%20%20user%20%20%20%20%20512%20%206%B7%EE%20%201%C6%FC%20%2010%3A57%20.
[...]

Anyway, I tend to agree with ipswitch that Solaris 2.6 is broken.  Their
recommendation was to upgrade to Solaris 2.8.  (Linking /bin/ls to
/usr/ucb/ls was the poor-man's solution for me.)  Just a curiosity.

> > > > I can set DCS to either EUC or SJIS, and Lynx will
> > > > [just] work, *IF* my terminal emulator is set to receive/send SJIS.
[...]    ^^^^
> But that explains why sending SJIS when the terminal expects EUC may
> be dangrous, not why sending EUC when the terminal expects SJIS "works"
> (i.e., shows the right glyphs).

Okay, here's the gory details (all 8 combinations):
Emulator   LANG    Lynx DCS   result
  EUC    japanese   EUC-JP     okay
  EUC    japanese  Shift-JIS   glyphs wrong/blank, positioning wrong, keys work
  EUC       ja      EUC-JP     okay
* EUC       ja     Shift-JIS   total lockup of emulation (even ^C, ^D dead)
 SJIS    japanese   EUC-JP     glyphs wrong, positioning okay, keys work
 SJIS    japanese  Shift-JIS   okay
 SJIS       ja      EUC-JP     glyphs wrong, positioning okay, keys work
 SJIS       ja     Shift-JIS   okay

The asterisk marks the combination I have been calling "fatal."  I suppose if
done from a console, there would be no way to recover other than a hardware
reboot.  Why take the fun out of Un*x, right? :)  Although matching DCS to
LANG would prevent the worst-case scenario, it would not guarantee a correct
rendering.

> I thought he said he tried both, and got the expected result (works better
> *with* SLANG_HAS_KANJI_SUPPORT defined).

You're right; I misread his letter!

> My nkf apparently cannot deal with JIS X 0212 characters (which can be
> validly encoded in EUC-JP and in ISO-2022-JP-2), while my iconv can.
> I guess those characters aren't much used.  (Current lynx doesn't
> treat them right, either.  I have made some changes in my copy to
> add support.)

Don't even know what 0212 are :(.  I've never been able to figure out
how I'm supposed to use ISO-2022-JP-2 :( :(.  (If it's easy and you have
the time, kindly write me off list.  Thanks.)

> the display character set form the command line, but you have to
> compile with -DMISC_EXP, and it's undocumented.  Consider this
> a plug for (helping test) MISC_EXP.
>      lynx -dump -convert_to="text/plain;charset=euc-jp" ...

This could be a real time-saver.  Do I have to use -dump?  Is it possible/
meaningful-to-do-so in an interactive session?  Might just add it to my
alias to lynx.

__Henry

PS  An aside on the NLS discussion we had wrt:
> policy.  But it isn't required - both LANG and LANGUAGE can take the
> same kinds of strings (like "ja_JP", "ja_JP.eucJP" or "ja_JP.ujis")
> which may or may not explicitly mention a character encoding.

My understanding of "acceptable" strings for LANG and LANGUAGE seems to
be different from yours.  LANG, AFAIK on Solaris, _has_ to be a valid
character set name which can be determined by issuing the command
"locale -a."  LANGUAGE, OTOH, is simply the name of the directory under a
prescribed path definition that contains the message catalogue under the
specific category in question.  Therefore, I have always considered it
"legal" to set LANGUAGE to things like "ja-pub" or "ja-kan" for subsets
within a particular language.  Like now I'm evaluating the translation Kohda
turned us on to (Remember I arrived in Japan before most of these people
were born; we speak a different language.), so I have it stuck under
"ja-hatta."  I once started a Kansai dialect translation that would have
been pretty funny to those Kanto guys.

> It's perhaps a shortcoming of the whole "locale" idea that "character
> set" and "language" issues are inseparably mixed together like that.

Yes.

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden