> >/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.
The effects of POSIXLY_CORRECT can be localized to the echo command by
setting it in a subshell, but even that does not get RH9's /bin/echo
to behave:
[cricket : phutchis]$ ( export POSIXLY_CORRECT=1 ; /bin/echo "${MY_TITLES}\c" )
\0033]2;cricket\0007\0033]1;cricket\0007\c
[cricket : phutchis]$ /bin/echo --version
echo (GNU coreutils) 4.5.3
Written by FIXME unknown.
> >"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.
...
> >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.
Bug, (mis)feature, whatever. As you pointed out above, it also
departs from applicable standards. I should probably just replace
the RH9 /bin/echo with one that works properly.
> 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).
Not only does bash 1.14.5(1) not understand shopt at all -- it looks
for, and does not find, an external command -- its built-in echo
does not do the right thing either with or without -e. That's why
I've been using /bin/echo: it is the one mechanism which, until now,
has worked the same on all the systems that share this one .bashrc
file.
> >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"?
>
> 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.
For the sake of the archives, this seems to work:
# cruft to avoid broken /bin/echo on RH9
if [ -f /etc/redhat-release ]; then
RHR=` tr -cd '[0-9.]' < /etc/redhat-release `
else
RHR=0
fi
if [ "$RHR" = "9" ]; then
ECHO_CMD="echo -e"
else
ECHO_CMD=/bin/echo
fi
unset RHR
$ECHO_CMD "${MY_TITLES}\c"
This hack is an example of what I mean by an exponentially-exploding
maze of workarounds. This one is a bit over 256 bytes. Largely as
a result of such junk, my .bashrc is currently around 12KB, and it
takes a large fraction of a minute to process every time I log in to
a different system or start up a new xterm. Sheesh!
<flame> Does it never occur to these bozos^H^H^H^H^H"smart, capable
people" that crap like this is one of the big reasons why a lot of us
absolutely refuse to upgrade systems absent a massively compelling
reason? </flame>
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
