Re: /bin/echo -- $var
2019-08-15 07:29:37 -0700, Kaz Kylheku (Coreutils):
> On 2019-08-15 00:53, Harald Dunkel wrote:
> > IMHO they should have kept the "no args allowed" for echo
> > ("in the late 70s") and should have introduced a new tool
> > "eecho" instead.
>
> Well, new tool for printing was introduced under the name "printf".
[...]
And "print" long before that (1983) as a builtin of the ksh
shell which was to be the replacement for sh, and would probably
have been if it hadn't been sold separately from the base system
at a hefty price (it eventually was in spirit as the POSIX sh
specification is largely based on it).
"print" has the same problem as the PWB/SysIII/XSI echo in that
escape sequences are expanded by default (and implementations
handle octal sequences the C/normal way, and some the echo way).
But at least it can be disabled with "-r" and there is an
end-of-option marker:
print -r - "$@"
pdksh, zsh and ksh93 also support --. Sometime after ksh86a, --
was also supported there, but actually any number of "-"
(possibly intersperced with decimal digits) act an
end-of-options marker (like print --1-1-1-- "$@", still works
with /usr/xpg4/bin/sh on Solaris).
That's like zsh's:
echo -E - "$@"
I beleive "printf" was a POSIX invention. It was never added to
ksh88, nor pdksh (though some pdksh-derived shells now have
one). But it's ubiquitous if only as a standalone utility, so I
agree it should be the command to use to output arbitrary text.
ksh93 and zsh added a "printf" builtin and "print -f". bash has
printf but not print.
printf does support "--" (to allow formats that start with -).
A few anoying things with it:
printf '%s\n'
prints the same thing as:
printf '%s\n' ''
So we can't use it to print an arbitrary number of lines (zsh's
print -l has the same problem).
The equivalent of echo "$@" is painful to write:
(IFS=" "; printf '%s\n' "$*")
And it outputs the same thing if "$@" is an empty list or a
list of one empty element. csh echo is the only one that
addresses that one (echo alone doesn't output anything, echo ''
outputs an empty line).
--
Stephane
Re: /bin/echo -- $var
On 8/15/19 2:36 AM, Harald Dunkel wrote: > On 8/14/19 3:10 PM, Eric Blake wrote: >> On 8/14/19 7:01 AM, Harald Dunkel wrote: >>> >>> Shouldn't it be just >>> >>> -n >> >> No, because 'echo' is one of the few exceptions to the rule, in that >> POSIX specifically mandates that it NOT recognize -- as an >> end-of-options marker. > > But then the "-n" shouldn't be printed either, should it? "-n" > is a valid command line option for coreutil's /bin/echo (and > the bash builtin, too). Wrong. Since you called 'echo -- -n', and did not use '-n' first (which is itself a can of worms), the literal output must be '-- -n' (the -- is not ignored as an end-of-option marker, but treated as a literal string). > > This doesn't seem reasonable. Posix says also "Implementations > shall not support any options", i.e. coreutil's echo is violating > Posix, anyway. Partially wrong. In general, '/bin/echo --help' does not ignore --help and goes on to print a lot of text; but that is because in general, most users don't request strict POSIX compliance. If you instead run 'POSIXLY_CORRECT=1 /bin/echo --help', you will output exactly '--help'. That is, when coreutils has been asked to run in POSIX compliance mode, coreutils does NOT violate POSIX. Otherwise, we intentionally violate POSIX in a few spots where it makes sense, but try to limit those spots to as few as possible. Treating -- as an end-of-options marker in non-POSIX mode would break more than it helps, so we do not diverge from POSIX there; but treating --help as an option in non-POSIX mode is essential to your ability to learn whether /bin/echo came from coreutils. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: /bin/echo -- $var
On 2019-08-15 00:53, Harald Dunkel wrote:
IMHO they should have kept the "no args allowed" for echo
("in the late 70s") and should have introduced a new tool
"eecho" instead.
Well, new tool for printing was introduced under the name "printf".
Re: /bin/echo -- $var
On 8/14/19 3:10 PM, Eric Blake wrote: On 8/14/19 7:01 AM, Harald Dunkel wrote: Shouldn't it be just -n No, because 'echo' is one of the few exceptions to the rule, in that POSIX specifically mandates that it NOT recognize -- as an end-of-options marker. But then the "-n" shouldn't be printed either, should it? "-n" is a valid command line option for coreutil's /bin/echo (and the bash builtin, too). This doesn't seem reasonable. Posix says also "Implementations shall not support any options", i.e. coreutil's echo is violating Posix, anyway. Regards Harri https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
Re: /bin/echo -- $var
On 8/14/19 10:23 PM, Stephane Chazelas wrote:
2019-08-14 09:28:22 -0700, Kaz Kylheku (Coreutils):
[...]
According to POSIX, echo doesn't take options. It is specified
that "Implementations shall not support any options."
(We have options, though, so things are complicated.)
[...]
The POSIX specification of "echo" is going to change in a future
version. See: http://austingroupbugs.net/view.php?id=1222
and http://austingroupbugs.net/view.php?id=1222#c4375 for the
accepted new text.
I see.
IMHO they should have kept the "no args allowed" for echo
("in the late 70s") and should have introduced a new tool
"eecho" instead.
Regards
Harri
Re: /bin/echo -- $var
2019-08-14 09:28:22 -0700, Kaz Kylheku (Coreutils):
[...]
> According to POSIX, echo doesn't take options. It is specified
> that "Implementations shall not support any options."
> (We have options, though, so things are complicated.)
[...]
The POSIX specification of "echo" is going to change in a future
version. See: http://austingroupbugs.net/view.php?id=1222
and http://austingroupbugs.net/view.php?id=1222#c4375 for the
accepted new text.
In short, except when they implement the XSI option (which they
need to to claim the UNIX trademark) implementations are going to
be allowed to support a "-e", "-n" or "-E" option (but still not
"--"/"-" to mark the end of option) and their behaviour will
still be unspecified if any argument contains a backslash
character (in practice, most implementations also fail if those
arguments contain a multibyte character whose encoding contains
byte 0x5c, which happens to be the ASCII encoding of backslash)
Implementations that support an end of option marker include the
"echo" builtin of zsh ("-", formerly "--"), fish ("--"), Byron
Rakitzis clone of "rc" for Unix ("--") and its derivatives (es,
akanga).
With GNU "echo" (and GNU "env"), you can output "-n" or
arbitrary $data with:
env -u POSIXLY_CORRECT echo -En "$data
"
--
Stephane
Re: /bin/echo -- $var
On 2019-08-14 05:01, Harald Dunkel wrote: Hi folks, I just learned by accident that var="-n" /bin/echo -- $var actually prints -- -n Shouldn't it be just -n ? According to POSIX, echo doesn't take options. It is specified that "Implementations shall not support any options." (We have options, though, so things are complicated.) Furthermore, the specification explicitly speaks of -- thusly: "The echo utility shall not recognize the "--" argument in the manner specified by Guideline 10 of XBD Utility Syntax Guidelines; "--" shall be recognized as a string operand."
Re: /bin/echo -- $var
echo is defunct by definition. The preferred way is printf %s\\n "data" which is much more stable against such "attacks"! Also it is far more stable to be used for multiline output: printf %s\\n "line 1" line\ 2 'line 3' "line 5 and line 6" and no, it shouldn't. echo should not be used but must not be changed. On 14/08/2019 14:01, Harald Dunkel wrote: > Hi folks, > > I just learned by accident that > > var="-n" > /bin/echo -- $var > > actually prints > > -- -n > > Shouldn't it be just > > -n > ? > > Other tools in coreutils use '--' to indicate "stop parsing for > command line flags", e.g. touch, ls and rm: > > % /bin/touch -- -l > % /bin/ls -- -l > -l > % /bin/rm -- -l > % /bin/rm -- -l > /bin/rm: cannot remove '-l': No such file or directory > > Some common style would be nice here. > > > Regards > Harri >
Re: /bin/echo -- $var
On 8/14/19 7:01 AM, Harald Dunkel wrote: > Hi folks, > > I just learned by accident that > > var="-n" > /bin/echo -- $var > > actually prints > > -- -n Correct. This is the POSIX-mandated behavior. > > Shouldn't it be just > > -n No, because 'echo' is one of the few exceptions to the rule, in that POSIX specifically mandates that it NOT recognize -- as an end-of-options marker. Instead, POSIX recommends that you use printf instead of echo if the string you are intending to print may contain \ or start with -. > ? > > Other tools in coreutils use '--' to indicate "stop parsing for > command line flags", e.g. touch, ls and rm: > > % /bin/touch -- -l > % /bin/ls -- -l > -l > % /bin/rm -- -l > % /bin/rm -- -l > /bin/rm: cannot remove '-l': No such file or directory > > Some common style would be nice here. It would be nice, but it would be non-compliant to the standards. We can't change this one. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
