Re: ✘Long options?

[Gary E. Miller]

Yo John!

On Sun, 03 May 2020 08:54:39 -0400
John Ackermann <address@hidden> wrote:

> Gary, one other option could be to have a config file that would
> include header field keyword/value pairs.  That has the advantage of
> being do-it-once, then forget for the user.

Wow, you want everything.  :-)

My do-it-once, then forget, suggestion is that you just create a batch
file with your options.  One file as good as another?  Right?

> I can think of several reasons why that might not be optimal, not
> least because it would have the tendency to grow like Topsy with new
> values.

gpsd does try to fight option bloat, but in this case, it does not see
fair to ask the user to manually edit fixed format files.  Most will open
it an word and watch in horror as it reflows...

gpsd (gpsrinex) is stuck with needing more options. gpsd programs
take command line options, and command line options from environment
variables.  Except gpsrinex does not use the environment, yet.  The next
step is reading the same options from a file, and using the same option
parsing.  Using the same pargin is essential, otherwise things get out
of sync.  Madness ensues.

gpsd has needed long options for a while.  They make documentation
and examples a lot easier to read.  gpsrinex is as good a place as any
to start.  Then, if someone has spare cycles, they can implement an
environment variable GPSRINEXOPTS, and finally an @optionfile option.

Oddly, with everyone in lockdown and stuck at home, spare cycles are
still in short supply...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpmxtC3UTi7m.pgp
Description: OpenPGP digital signature