gpsd-dev
[Top][All Lists]
Advanced

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

Re: ✘ Release blockers?


From: James Browning
Subject: Re: ✘ Release blockers?
Date: Wed, 1 Jan 2020 10:22:18 -0800

On Tue, Dec 31, 2019, at 6:11 PM Greg Troxel <address@hidden> wrote:
> "Gary E. Miller" <address@hidden> writes:
> >> But seriously, for the nerd audience, do enough people really want
> >> imperial units to have that as the default?
> >
> > I would hope the non-nerd audience is bigger than the nerd one.
>
> In terms of all the people that use gpsd, I really cannot believe that a
> majority would prefe imperial units.  I would think it's at least 9:1
> metric, if not higher.  My logic is that everyone who isn't in the US,
> Liberia or Burma prefers metric, and that more than half of US people
> that play with GPS want metric too.
>
> > Unix is choice, just set XGPSOPTS.

(blatherskite exposition bomb warning)

The value of XPGSOPTS is prepended to the command line arguments. The
default unit system here is None which triggers the stuff int the next
paragraph. Each instance of -u followed by a value overrides the
previous value.

The environment variable GPSD_UNITS is then checked to change away
from the default of unspecified you could set it to 'imperial',
'metric', or 'nautical'.

If no selection has been made LC_MEASUREMENT is checked. A value of C,
POSIX, or starting with en_US sets imperial units. Any other set value
yields metric. Then the immediately preceding checks are run using the
value of LANG (if set).

If the value is still unspecified units are temporarily set to be
undefined, which IIRC gets squashed to metric.  Liberia is never
mentioned.

The checks should probably drop LC_MEASUREMENT or LANG value of C, or
POSIX setting imperial units.

It might be possible to drag Liberia into imperial units. The more
likely outcome is kicking en_US starting values out.



reply via email to

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