If you'll use
LC_TIME="en_US.UTF-8" rpm -q cobbler --qf
"%{INSTALLTIME:date}\n"
then new value for LC_TIME will affect only one string.
No need to mess with saving/restoring/unsetting
Valery.
From: Joe Wulf <joe_wulf@xxxxxxxxx>
To: General discussion about the RPM package manager <rpm-list@xxxxxxxxxxxxx>
Sent: Friday, April 6, 2012 6:17 PM
Subject: (solved) Re: INSTALLTIME:date format
I've figured it out, based on the clues you guys offered.With additional research and troubleshooting, I found the "LANG=c" was sometimes conditionally being set; then the effective execution of: rpm -q cobbler --qf "%{INSTALLTIME:date}\n" was giving me the exactly formatted result (of: Tue Jan 31 14:43:27 2012) most times. I fixed the script to:LC_TIMEsave="${LC_TIME}"; LC_TIME="en_US.UTF-8"rpm -q cobbler --qf "%{INSTALLTIME:date}\n"LC_TIME="${LC_TIMEsave}"; unset LC_TIMEsaveIn all my tests so far, things are consistent the way I want them.Thanks Greg and Jeff for the help!R,-Joe
From: Greg Swift <gregswift@xxxxxxxxx>
To: Joe Wulf <joe_wulf@xxxxxxxxx>; General discussion about the RPM package manager <rpm-list@xxxxxxxxxxxxx>; Jeffrey Johnson <n3npq@xxxxxx>
Sent: Friday, April 6, 2012 9:30 AM
Subject: Re: INSTALLTIME:date format
I know what Jeff says is right as well, but here is the output I was
suggesting, and it shows the same thing, and is much simpler than
reconfiguring your strftime.
[root@penguin rhel]# rpm -q cobbler --qf "%{INSTALLTIME:date}\n"
Tue 31 Jan 2012 02:43:27 PM EST
[root@penguin rhel]# LANG=c rpm -q cobbler --qf "%{INSTALLTIME:date}\n"
Tue Jan 31 14:43:27 2012
I'd check the difference of your configured LANG on the two different
sets of systems. This affects other bits of the system, like sar's
output. The applications utilize the locally configured language's
time format preference to present the time.
-greg
On Thu, Apr 5, 2012 at 22:57, Joe Wulf <joe_wulf@xxxxxxxxx> wrote:
> Jeff,
>
> Thank you for the insight and direction. I'll go explore the LC_TIME
> issue. I agree that is the right direction, from what you've said, and the
> little I've read so far.
>
> My process is a casual one. Once in a while, I'll kick off some scripts.
> A part of that queries the RPM database for what is installed and provides a
> structured formatted list back. All the other data I can chop up as I need
> to. When that date format comes back different ways, it is challenging to
> process consistently, since the returned data seems to vary so. What I
> think I need is a way to prefix my rpm query with a command that preserves
> LC_TIME (or important aspects of it), set it temporarily for the duration of
> that shell script instance to what I want and then puts LC_TIME back (if
> necessary). I'm not looking to change the whole system around, just to
> support my occasional need.
>
> I'm going to start looking for a good understanding of locale and
> specifically the parts and pieces of LC_TIME.
>
> Thank you.
>
> R,
> -Joe
>
> P.S. resent to the list (I apologize for the duplicate).
>
> ________________________________
> From: Jeffrey Johnson <n3npq@xxxxxx>
> To: Joe Wulf <joe_wulf@xxxxxxxxx>
> Cc: Greg Swift <gregswift@xxxxxxxxx>
> Sent: Thursday, April 5, 2012 8:32 PM
> Subject: Re: INSTALLTIME:date format
>
>
> On Apr 5, 2012, at 8:28 PM, Greg Swift wrote:
>
> Try prefixing the command with LANG=c to see if that is causing the
> discrepancy.
>
>
> Right idea but wrong envvar (is my guess).
>
> strftime(3) is used to format dates (in a per-locale fashion).
>
> And "man 3 strftime" identifies LC_TIME as what you
> want to change.
>
> I don't know what to change LC_TIME to, just that RPM uses strftime(3).
>
> hth
>
> 73 de Jeff
>
> On Apr 5, 2012 7:05 PM, "Joe Wulf" <joe_wulf@xxxxxxxxx> wrote:
>
> How does one refine or specify the format for the date returned by:
> "%{INSTALLTIME:date}"?
>
> On some systems I get the first response (preferred) and for unknown reasons
> I get the second on other systems:
> - "Fri 10 Jun 2011 02:03:18 PM GMT"
> - "Fri 10 June 02:03:18 2011"
>
> Is there some other, external (maybe posix thing) that affects this?
>
> Thank you.
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@xxxxxxxxxxxxx
> http://lists.rpm.org/mailman/listinfo/rpm-list
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@xxxxxxxxxxxxx
> http://lists.rpm.org/mailman/listinfo/rpm-list
>
>
>
>
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@xxxxxxxxxxxxx
> http://lists.rpm.org/mailman/listinfo/rpm-list
>
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
