Hello, On Thu, 02 Apr 2015, David C. Rankin wrote:
On 04/02/2015 11:59 AM, David Haller wrote:
There is a bug somewhere, even though you are on 12.1, you seem to be
ahead of 13.1: ;) I suggest you get the current 4.3 from the 'shells' repo.
Install:
$ rpm -qa --queryformat '%{installtime} %{installtime:date} \ %{name} %{VERSION}-%{RELEASE}\n' | sort -n | cut -c 12- | tail -n10 <snip> Thu 02 Apr 2015 05:43:02 PM CDT bash 4.3-275.1
BTW: better just use | cut -f2- | instead of that breakable 'cut -c'. Remember, when unix-timestamps were just 9 digits long? You'd have used 'cut -c 11-' and on Sun 09.09.2001 03:46:40 CEST (date +%s == 1000000000) your script would have failed. Ok, the next digit is a while away (10000000000 == Sat 20.11.2286 18:46:40 CET), so you should be safe there (but what about a package installed before 09.09.2001?[1]) Stuff like this, is what _always_ gets people into trouble (Y2K anyone?). Generally: avoid 'cut -c' if you can get away with it in almost any way! Use awk instead if 'cut -fN' does not work, or even perl / python / ruby. But do not use count-of-character based stuff if you can avoid it in any way (or the spec states _explicitly_ that the field is N-{chars,bytes,digits} (what chars? ASCII? UTF-8?) long. And even then: distrust the specs! BTDT. [..]
Seems to be working now! Thanks dnh!
That's nice to read :) I have found some patches/changes regarding the libhistory (part of libreadline) since bash-4.2/accompanying libreadline, but nothing obvious. In such cases, I tend to try a newer (but tested) version, of which this is a fine example, as the bash-4.3 / libreadline / libhistory has been long tested. And if you find someone using that new stuff under the same or older oS (like me that 4.3 under 12.1), just the better, eh :) BTW: one indicator of a "well behaving" package is, that no tweaks are neccessary to build it for old(er) distro-versions. With bash, a simple link to the Base:System/bash suffices to be able to build it cleanly, so there should be no trouble[2]. When the packager has to change stuff to get the current package to build on e.g. 12.1, there might be problems (depending on the type of changes needed, they may be trivial and to be ignored (e.g. upstream just did not test against libfoo-(N-1) and thus requires libfoo-N in configure or such), but they might of the be "flaky" but "works-for-me" kind. HTH, -dnh [1] until "recently", I had such packages installed ;) [2] and in the >= 6 months I use it, I noticed none -- Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org