[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Re: lynx should respect LANG
Re: lynx-dev Re: lynx should respect LANG
Thu, 1 Jun 2000 14:01:22 +0900 (JST)
> > 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"
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
Up to henry
* text/plain  henry user 259 6$B7n(B 1$BF|(B 10:54
* Directory  henry user 512 6$B7n(B 1$BF|(B 10:57 .
* Directory  henry user 512 6$B7n(B 1$BF|(B 10:58
* Directory  henry user 1024 6$B7n(B 1$BF|(B 10:53
* text/plain  henry user 2678 6$B7n(B 1$BF|(B 10:54
* text/plain  henry user 5712 6$B7n(B 1$BF|(B 10:55
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
> 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.
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.
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
- Re: lynx-dev Re: lynx should respect LANG,
Henry Nelson <=