In regard to: Re: RH9 breaks bash ?, Perry Hutchison said (at 4:26pm on Dec...:
>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.
I looked at the man page for the `echo' standalone on RH 7.3, and the
man page seems pretty clear: In the abscense of `-E', the implied default
behavior is that escape sequences *should* be honored. That's not what
happens though.
I meant to mention this earlier -- Have you tested this *without* the
extra leading 0? I've always seen the escape sequences documented as
\NNN octal character NNN
but you have 4 digits, which might mean that the sequence is not being
interpreted as you expect. In other words, is it being parsed like
\003 3]2;cricket\000 7\003 3]1;cricket\000 7\c
(extra spaces added to show where parsing might be off)? I *doubt* that's
the problem, but you should consider it as a possible issue.
>> 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.
That's just asking for trouble. There may exist system utilities that
*depend* on /bin/echo not interpreting things that look like escape
sequences.
>> 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 --
As expected.
> 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.
:-) That's the great thing about adding more systems and different
software versions to the mix. It turns up areas where you've made
assumptions about intelligent behavior from system tools. ;-)
># cruft to avoid broken /bin/echo on RH9
> if [ -f /etc/redhat-release ]; then
> RHR=` tr -cd '[0-9.]' < /etc/redhat-release `
That's a better trick than the one I had been using, but if you should
happen to add
Red Hat Enterprise Linux AS release 2.1
Red Hat Enterprise Linux ES release 2.1
Red Hat Enterprise Linux AS release 3
Red Hat Enterprise Linux ES release 3
Red Hat Enterprise Linux WS release 3
to your list of systems, your test won't be "broad" enough. All of them
are based on Red Hat Linux 7.2 or later, so they will have an "echo"
that behaves in the way that displeases you.
> 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!
:-) I hear you. My ~/.bashrc is 19K, and that's not counting any
host-specific or platform-specific rc files that get loaded in addition.
Of course, I have my HISTSIZE set to 95000 and I have bash compiled as
an LP64 executable on many platforms, so it's not uncommon for one of my
bash shells to have an RSS of 16-18 Megabytes.
FYI, I looked at the echo that comes with `coreutils-5.0', and it also
has the exact same man page, and it behaves the exact same way. If
nothing else, I think the man page is wrong and should be updated.
Perhaps you want to report this as a bug to the coreutils maintainers?
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
