[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Re: lynx should respect LANG

From: Klaus Weide
Subject: Re: lynx-dev Re: lynx should respect LANG
Date: Thu, 25 May 2000 16:59:05 -0500 (CDT)

On Thu, 25 May 2000, Henry Nelson wrote:

> > > would handle the four or so environment variables concerning encoding
> > > and NLS, set paths to specific help/doc files, and be sure terminal
> > > and console settings are sane could be written with less words than
> > > the explanation you proposed for lynx.cfg alone, 
> > 
> > I doubt that very much.  If you want to uphold that claim, prove it. :)
> Don't really want to argue, especially with someone as knowledgeable as
> you.  ... But, although your proposal is designed for the general case,
> and as such is worthwhile indeed, if I understand correctly you are
> attempting to deal only with getting the "right" display character in
> accordance with the LANG environment variable.  To do this absolutely
> in a script takes basically three lines: unset the LANG variable, reset
> it to the desired value, then execute lynx with the appropriate command
> line options.

Not at all the same; in fact, quite the opposite.
One approach assumes that the pre-existing LANG is right.
Your approach assumes that you (as script writer) know better.

> The advantage of a script, which granted could NOT be for the general
> case, BUT which would quite easily act as a "plug in the values" template,
> is that it could set an entire suite of environment variables, set
> paths to the appropriate support files to match the environment, and
> then start up a lynx which would work properly in that environment.

Sure, if you want all that, by all means do it.  You can.
But that doesn't mean it's worthless to provide a builtin mechanism
that increases the chances that lynx starts up "right" when nobody
has written such templates/scripts.

> I think this thread started as a request from a "packager."  In my biased
> opinion, they can get by with a bare-bones script which does not need
> to do a lot of error recovery (which takes up all the space in a script)
> because they have a known, fixed environment, just that, a package.

Your concept of a "package" seems to be very different from what it
means in Debian GNU/Linux and other linux distributions, for example.
Making a package certainly doesn't imply a "known, fixed environment".
Nor should it mean that one can be cavalier about error recovery -
if the package is actually meant to be distributed and used.

> > Note that that "intelligent wrapper" should deal with more than just
> > two languages (not just ja vs en), and should be system independent
> > (not depend on specific install locations), in order to provide similar
> Why?  My idea of an "intelligent wrapper" is that it would handle the
> languages and systems for which service is intended or available.  A
> wrapper intended for Debian-JA need do no more than that.  

You seem to assume that a package is only intended for a very limited
set of languages and systems that are explicitly "intended" and supported.
That's up for the Debian(-JA) people to say, no?
I think (I would hope) they have higher ambitions...


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]