Jean Delvare dixit:
>Hello mksh developer,
Hi!
>In mksh, "print -R" is not as close to "echo" as it was in original
>ksh. Specifically, after "-R", mksh's print command keeps parsing the
>command line in search of options, and stops as soon as it finds an
Indeed, this is as documented:
The -R option is used to emulate, to some degree, the BSD echo(1)
command which does not process ‘\’ sequences unless the -e option
is given. As above, the -n option suppresses the trailing new‐
line.
The -R option does _not_ emulate the echo you mean but another.
We have the echo you mean in POSIX mode though…
>Example with the original ksh:
>
>$ print -R -42
>-42
Quick workaround (this will lose you support for -n though):
function print {
if [[ $1 = -R ]]; then
shift
builtin print -r -- "$@"
else
builtin print "$@"
fi
}
>I looked at the mksh code and was able to modify the print_c function
>to get mksh's print command to behave the same with -R as echo and the
>original ksh print with -R. I have a patch ready. Are you interested in
>it, or is the different behavior on purpose?
While I think you’re the first user of “print -R”, this looks as if it
was intended — I’d address this on the customer side, maybe in a
two-step process:
1. Check all uses of 'print.*-[^ ]R' for which syntax is used, e.g.
if we need to handle “print -R -n”, “print -Rn”, “print -nR” or
somesuch; adjust the abovementioned print function, use it
2. Convert all uses of print’s -R option to 'print -r --' or
'print -nr --' in the scripts (yes, more effort, but worth it).
I’d advocate against trying to do something with echo that even
pretends portability; we have no less than three different echo
implementations in mksh alone (and which is chosen depends on
several factors).
Nevertheless, thank you for mailing about this!
Hrm. Funnily enough:
tglase@tglase-nb:~ $ print -R -- -42
-- -42
tglase@tglase-nb:~ $ print -R -x -42
/bin/mksh: print: -x: unknown option
Perhaps I’ll have to investigate “the BSD echo(1) command”
further (no problem thanks to TUHS) and maybe the implementation
is indeed wrong… but the result will likely end up in a formal
mksh release too late for your customer anyway. I’ll make a note.
bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
