Re: suggestion: shell option for echo to not interpret any argument as an option

[Zachary Santer]

I managed to set xpg_echo on in bash and then forget that I did that. I was
using echo's behavior with -n to determine if set -o posix had taken
effect, when it's completely unrelated. And sh in MSYS2 is definitely just
bash with set -o posix on. What I get for rushing.

However, the man page for bash 5.2 only says the following about xpg_echo,
in the section about shopt:
"If set, the echo builtin expands backslash-escape sequences by default."

It makes no mention of disabling option processing.

Similarly, in the description of the echo command, we see:
"The xpg_echo shell option may be used to dynamically determine whether or
not echo expands these escape characters by default."

So is that a bug in the documentation?

On Wed, Jul 26, 2023 at 10:51 AM Chet Ramey <chet.ramey@case.edu> wrote:

> On 7/26/23 10:15 AM, Zachary Santer wrote:
> > Oh, that's weird. I just assumed that sh would be running bash with 'set
> -o
> > posix'. Evidently, not in MSYS2. 'man sh' takes me to the Bash man page.
>
> Weird. I don't use MSYS2, but that's how it works on Unix/Linux systems.
>
> > When I run sh, 'set -o posix' has no effect, but it definitely makes
> echo
> > not interpret any arguments as options when I'm in bash.
>
> Not quite, at least on Unix/Linux/macOS. `set -o posix' by itself doesn't
> affect echo's behavior with respect to accepting options or expanding
> backslash-escapes in the remaining arguments. There's too much existing
> code to try and bother with that. The `xpg_echo' shell option disables
> option processing and enables backslash-escape translation, which is the
> POSIX/XSI required behavior.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>
>