[lmi] dash print vs. printf

[Greg Chicares]

Vadim--Somehow I thought 'print' was a shell builtin like 'printf',
which might be preferable if no particular formatting is wanted.
That's true with zsh...

$cat ./eraseme.sh 
#!/bin/sh
echo 'Test echo'
printf 'Test printf\n'
print 'Test print\n'

$. ./eraseme.sh               
Test echo
Test printf
Test print

...but not with dash:

$./eraseme.sh    
Test echo
Test printf
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_TIME = "en_DK.UTF-8",
        LC_COLLATE = "C.UTF-8",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Error: no such file "Test print\n"

Let me ask a few questions about this.

(1) I tried in vain to find out whether POSIX requires 'print'
to be a built-in, but there seem to be three categories:
 - "special built-ins", like 'exec' or 'export', which are
   prescribed to be built in;
 - utilities that by their nature must be built in, like 'fg'
   or 'cd'; and
 - other "regular built-ins", for which AFAICT POSIX doesn't
   prescribe anything: they can be a large set, or an empty set.
Have I understood that correctly?

(2) What practical rule should be followed? I used to write
'echo' everywhere. Then I changed most occurrences of 'echo' in
scripts and makefile recipes to 'printf' or 'print'. Is the best
practice to use 'printf' as the only replacement for 'echo', and
never 'print'? If so, then...how can I be sure 'printf' won't
surprise me someday as 'print' has today? Is the answer that
POSIX prescribes a 'printf' command:
  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
so that's safe; but it but simply doesn't mention any 'print'
command, so 'print' is allowed to surprise me in a POSIX shell?

(3) I'll just accept that '/usr/bin/print' is some mailcap thing
that enables email attachments to do things that I probably don't
want them to do anyway. But there's that distressing series of
locale diagnostics, which I often see when I run 'apt-get upgrade'
as well. Overriding only the ones that are missing lets the
command complete, at least:

$LANGUAGE="$LANG" LC_ALL="$LANG" /usr/bin/print --help           
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_US.UTF-8",
        LC_ALL = "en_US.UTF-8",
        LC_TIME = "en_DK.UTF-8",
        LC_COLLATE = "C.UTF-8",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Use: /usr/bin/print <--action=VAL> [--debug] [MIME-TYPE:[ENCODING:]]FILE [...]

...and, better, if I instead follow your advice here:

  https://lists.nongnu.org/archive/html/lmi/2018-07/msg00018.html
| Presumably, if you changed it to C.UTF-8, this warning would disappear.

...then the unwelcome diagnostics disappear:

$LANGUAGE=C.UTF-8 LC_ALL=C.UTF-8 /usr/bin/print --help
Use: /usr/bin/print <--action=VAL> [--debug] [MIME-TYPE:[ENCODING:]]FILE [...]

I'll try that sort of override next time I 'apt-get upgrade'.
Or...assuming that this is a perl-specific problem (I do get
UTF-8 in vim:
  :set encoding
    encoding=utf-8
and also in 'less' by setting LESSCHARSET as you recommended here:
  https://lists.nongnu.org/archive/html/lmi/2018-03/msg00049.html
), is there a perl-specific solution, like
  export PERL_USE_DEFAULT_LOCALE=1
?