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