[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...
Klaus
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
lynx-dev Re: lynx should respect LANG, Christian Weisgerber, 2000/05/27
Re: lynx-dev Re: lynx should respect LANG, Henry Nelson, 2000/05/24
Re: lynx-dev Re: lynx should respect LANG, Henry Nelson, 2000/05/24
Re: lynx-dev Re: lynx should respect LANG, Henry Nelson, 2000/05/24
Re: lynx-dev Re: lynx should respect LANG, Henry Nelson, 2000/05/25
Re: lynx-dev Re: lynx should respect LANG, Henry Nelson, 2000/05/30
Re: lynx-dev Re: lynx should respect LANG, Henry Nelson, 2000/05/30