Re: [Lifelines-dev] /etc/lines.rc ?

[amores p. <lif...@ho...>]

>From: "Matt Emmerton" <ma...@gs...>
>Subject: Re: [Lifelines-dev] /etc/lines.rc ?
>Date: Sun, 1 Jan 2006 21:52:00 -0500
>
> > Isn't it somewhat conventional for a program to have a global config 
>file,
> > and also to somehow store its installed path, so that if lifelines was
> > installed to, say,  /opt/local/lifelines
> >
> > it would (#1) read a global config file 
>/opt/local/lifelines/etc/lines.rc
> > before it reads user private ones (which may thereby override the
> > global one)
> >
> > and it would (#2) have somehow compiled into it that path, so it
> > would look in /opt/local/lifelnes/share/reports for reports, if no
> > config option anywhere overrides that?
>
>Yes.  Obtaining program defaults (paths and configs) from the "install
>program base" is a good idea.
>
> > I may not have done this example correctly -- how would it
> > wind up looking for /etc/lifelines/lines.rc, or /etc/lifelines.rc,
> > which some programs do?
>
>Generally, I abhor programs that do this.  Programs should look within 
>their
>installed base for defaults, with /etc being reserved for system-wide "base
>OS" services, not user programs.
>
> > Should lifelines exhibit these behaviors?
>
>#1 and #2, yes.  Looking in /etc, no.
>

Matt,

Do you know how to make lifelines do this?

I'm guessing something like this

static char installpath = "INSTALL_PATH";

somewhere in the source, picking up a macro from
the configuration, but I'm not sure -- although, surely
lots of programs do exactly this.

(I agree about keeping out of /etc.)




> > I've been thinking that it probably doesn't work all that
> > great out of the box. Out of the box, it should install
> > (via make isntall, or rpm, or debian) in such a fashion
> > that it can find the report directory and also find the
> > tt directory (which has the mapping file for capitalization).
>
>Agreed.  I'm too lazy to build my own config file (for some reason) and it
>pains me to have to always type in the full path to the reports directory.
>

I suppose lifelines should check (1) locally configured report path(s)
and then (2) compiled install path reports, so that the user
can be working on his/her own version of book-latex, and get
that, instead of getting the system installed one.

I keep two paths in my reports path, the first for my own stuff,
and the second pointing to a cvs copy of the reports directory.



> > On a somewhat different issue, I have also been thinking
> > that it should probably default to using the locale codeset
> > (LC_CHARSET, or LC_ALL, or something like that)
> > for the case when there is no internal codeset
> > configured.
>
>Yes.  This would help users in non-en_US locales get appropriate "default"
>settings and not have to tweak anything.
>

Ya, and help avoid what someone has reported on the list,
which I'm pretty sure is gettext doing transliteration to ASCII,
which is due to code I put in set_gettext_codeset, and
which is probably annoying the user, because they want the
French translation, and they were running in ISO-8859-1,
which is the actual encoding used by the French
translation.

What happened was that I told gettext to transliterate
to ASCII if I didn't know what the internal codeset was.

I can't get from the translation encoding to the output
encoding, because I have to go through the internal
encoding, which is unknown.

But, I think it is kind of unix philosopy to assume text
is in the locale codeset, so that seems a plausible
thing to do. Plus, it makes it easy to experiment
by changing locales, and seeing how the text
appears, to figure out in what codeset the text
was entered into the database.

So assuming the locale encoding for the internal
encoding gets around the problem of "not
being able to handle translation encoding because
the internal encoding is unknown."




Now, enough of my running on about encoding.

New topic.

I was annoyed that "llines --version" doesn't work.

I looked at the code. Using getopt_long would
solve it, but I got tired of looking at the
configuration involved. Probably we could take
a copy of getopt* from libiberty sources
(which I've not yet found), to get a local
version (to supplement the local version
of getopt we already have in arch).

I actually thought about dropping getopt
and just writing the raw arg parsing loop,
because its not all that hard, but that kind
of seemed to be going the wrong direction,
so I didn't do that.


I am a big fan of --version, because I trust it
more than -v. Sometimes -v means other
things, but I feel pretty confident that --version
won't do something unintended on my system :)

Also, I like --help.

Cordially,

Perry