Re: printf %s in UTF-8 is not POSIX-compliant

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 5, 10:41am, Peter Stephenson wrote:
}
} Is it time to introduce a separate "bash" emulation (meaning smart,
} interactive shell not necessarily 100% POSIX compatible) and
} document that "sh" emulation is aimed at POSIX compatibility?

After reading some of the more recent posts on this thread, I've got
an opinion on this.

I think "emulate sh" should emulate the POSIX shell to the greatest
extent possible.  If that means turning off MULTIBYTE, turn it off.
(Of course there are still subtle differences between starting the
shell as "sh" and running "emulate sh" after it has started.  There
probably isn't any way to entirely resolve that.)

However, if "emulate bash" is going to mean something other than a
synonym for "sh", then some effort should be put into being a bit
closer to bash than it's currently possible to be.  For example,
at least set the various BASH_* options, the way "emulate csh" sets
the smattering of CSH_* options.

Of course "emulate bash" isn't even in the documentation at present.
(The "Compatibilty" section referenced from the "emulate" command
doesn't discuss csh, either, even though the "emulate" doc does list
csh among the possible arguments.)

A final thought on MULTIBYTE:  Is it perhaps reasonable to split this
into two options, one that affects line editor operations and one that
affects internals?  If someone does "emulate sh; setopt zle" it seems
there might be some expectation that ZLE can adapt to a terminal that
displays multibyte even if the input is all treated as raw bytes once
accept-line hands it off.  That might mean that e.g. _main_complete
needs to look at the state of ZLE_MULTIBYTE (or whatever) and setopt
MULTIBYTE locally to correspond.  Other widgets could also be affected,
so the emphasis here is on "reasonable."

(Possible workaround:  setopt MULTIBYTE in zle_line_init and unset it
again in preexec.)