In regard to: Re: RH9 breaks bash ?, Perry Hutchison said (at 12:59pm on...:
>> > MY_HN=`hostname | sed -e 's/\..*//' `
>> > MY_TITLES="\0033]2;$MY_HN\0007\0033]1;$MY_HN\0007"
>> > /bin/echo "${MY_TITLES}\c"
>> >
>> >which used to set the xterm window and icon titles, now just echos
>> >the uninterpreted string:
>> >
>> > \0033]2;cricket\0007\0033]1;cricket\0007\c
>>
>> It's probably the echo, not the other stuff. When I run your commands
>> on a Solaris box, with bash 2.05b, and do
>>
>> echo "${MY_TITLES}\c"
>>
>> I get the backslashed output. If I instead run
>>
>> builtin echo -e "${MY_TITLES}\c"
>>
>> I get your expected result.
>
>/bin/echo, echo alone, and "builtin echo" all produce identical
>(wrong) results on RH9:
>
> [cricket : phutchis]$ echo "${MY_TITLES}\c"
> \0033]2;cricket\0007\0033]1;cricket\0007\c
> [cricket : phutchis]$ /bin/echo "${MY_TITLES}\c"
> \0033]2;cricket\0007\0033]1;cricket\0007\c
> [cricket : phutchis]$ builtin echo "${MY_TITLES}\c"
> \0033]2;cricket\0007\0033]1;cricket\0007\c
That's because bash's builtin echo doesn't by default expand escape
sequences. I'm guessing that the GNU echo command doesn't either,
though I haven't checked. You can probably get it (GNU /bin/echo) to
honor them by setting POSIXLY_CORRECT=1, but that's suboptimal for bash
since it changes a number of other behaviors.
>"echo -e" works on RH9, but not on any of the other systems I use.
That's essentially because the GNU folks chose a default for echo
that isn't compliant with the XPG standard. The folks responsible
for bash and the GNU coreutils are really smart, capable people, and
they have their reasons, but it does make it a bit harder for those of
us with lots of platforms to deal with.
>> Well, changing your personal .bashrc seems like a more viable approach
>> than trying to change the system shell.
>
>To me, fixing the breakage in a new release seems more viable than
>constructing an exponentially-exploding maze of workarounds.
Breakage depends on point of view. It's working as the designers
intended, the problem for you is that it departs from historical function
and it's different from other platforms.
> I was
>hoping for something like a "set" command that would cause the new
>bash (or echo) to behave like the old one.
How about
shopt -s xpg_echo
? I don't think the `xpg_echo' option was around for the early 2.x
releases, so you may need to test bash version (see below).
>I suppose I could do something like
>
> if [system is RH9]; then
> ECHO_CMD="echo -e"
> else
> ECHO_CMD=/bin/echo
> fi
> ...
> $ECHO_CMD "${MY_TITLES}\c"
>
>but what do I put inside the [], that will run on all systems,
>to reliably identify "Red Hat 9"? Apparently $BASH_VERSION is
>irrelevant, and $OSTYPE on RH9 just says "linux-gnu".
As I mentioned on this mailing list just a couple weeks ago, when I need
to programmatically detect whether I'm on a RH box, and what version it
is, I generally test for the existence of /etc/redhat-release, and parse
out the version from there.
In your particular case, you may also be able to use rpm itself:
rpm --queryformat '%{version}\n' -q redhat-release
Running that from a shell startup file isn't a great idea, though.
$BASH_VERSION is relevant, because if you intend to continue supporting
systems that use bash 1.14.x, you'll want to do things a bit differently
for them.
Tim
--
Tim Mooney mooney@xxxxxxxxxxxxxxxxxxxxxxxxx
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
