[procps] Re: backporting
- From: Jim Warner <james.warner@xxxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Wed, 7 Dec 2011 08:01:56 -0600
On Dec 7, 2011, at 7:02 AM, Sami Kerola wrote:
> Thanks for feedback.
You're most welcome.
> Thank you, missing to add the following was silly mistake.
>
> setlocale (LC_ALL, "");
> bindtextdomain(PACKAGE, LOCALEDIR);
> textdomain(PACKAGE);
The bindtextdomain is technically optional but protects against non-standard
install locations. Do you think ours could/should be controlled by a configure
option rather than hard coded?
> Do you mean usage() outputs and for instance diskheader() in vmstat?
> I would argue the usage() is fine, but headers could better indeed.
Most usage could be output in a single fprintf. Not only is that more
efficient, but it's much better for the translator I should think.
> True. Some guidance could help. How about getting obvious things to
> fixed, such as the header words to strings, and then I'll do Finnish
> translation. While doing the translation I'll try to catch anything
> which is unclear/difficult.
That's an excellent idea. Why don't you establish a Finish branch that I could
look at too. My own testing just fudged some meaningless Chinese and
Australian English.
>> Finally, you have inexplicably eliminated important functionality
>> in some programs that is sure to upset numerous users.
>
> If I did that was unintentional. Do we have test(s) which highlight
> such?
Last time I looked, much error feedback was gone from sysctl and pkill provided
no confirmation of success. There was some missing help output too, but I've
lost track.
> I proposed something
> ...
> so perhaps you could write the README patch which would indicate you
> agree as well.
Sorry Sami, but I haven't begun to analyze those suggestions and libabc yet.
You're a hard guy to keep up with, and I'm just a plodder. One thing I will
try to protect is Albert's investment in the library and ps. That represents
an effort beyond most folks ability.
I'll try to begin that analysis.
> Having for example program_invocation_short_name dealt somewhere once
> to me sounds much better than writing that code segment to every
> single program file. That's essentially why headers & libraries
> exist, right.
Two lines of code would allow each program to determine its own name. And a
future programmer doesn't have to wonder what the heck that obscure, lengthy
variable really contains.
> In all honesty there are few things in `c.h' which may be subject to
> clean up. For example TRUE & FALSE definition may not be needed. I
> this one my thinking is that it's better to do something, even it
> would go wrong, rather than trying to be always right & perfect and
> get nothing done.
I'll still argue strongly against using any of those util_linux headers. To me
it makes no sense to rely on a non-standard BSD header extension, only to have
to plug the gap if configure doesn't find it. It would be much
easier/cleaner/simpler to fail the configure step with a missing *standard*
header.
>> In any case, to keep the nls ball rolling I'd like to incorporate
>> the attached top patch in your nls branch.
>
> Done.
Thanks Sami.
Jim
Other related posts:
