4 ms·

Ok, I'll bite. What's wrong with "echo -n"?

by gjem97 11y ago

cbr 11y ago
The FreeBSD manpages have: Note that the -n option as well as the effect of `\c' are implementation-defined in IEEE Std 1003.1-2001 (``POSIX.1'') as amended by Cor. 1-2002. -- http://www.freebsd.org/cgi/man.cgi?echo So there's probably some system (or shell) out there where -n doesn't work?
hyperbovine 11y ago
On some Unix variants that will print "-n" followed by a newline. On others it will print the empty string. http://steve-parker.org/sh/echo.shtml http://steve-parker.org/sh/echo.shtml
masklinn 11y ago
http://www.in-ulm.de/~mascheck/various/echo+printf/ http://www.in-ulm.de/~mascheck/various/echo+printf/ is the raw data version. POSIX defines echo as only taking string parameters and no options, but notes that behaviour facing `-n` is implementation-defined. BSD and GNU echo implement `echo -n` as not printing a trailing newline, but `echo` commonly calls to a shell builtin which may or may not follow that behaviour (and may switch behaviour depending on whether the shell is in "sh mode" or not), so `echo -n` could print `-n<newline>` or nothing whatsoever (empty string and suppressed newline) depending on the utils set, the shell, and the shell's runmode. GNU echo also supports -e, -E, --version and --help options, and much like -n shells and other utils set may or may not support these. For instance on my machine (OSX 10.11) * zsh (builtin) interprets -e, -E and -n as options (but not version or help) * bash (builtin) also does, except when invoked as sh in which case it does not and all parameters are literal (this may also apply to zsh) * dash (builtin) interprets -n, but none of the others. bash note may also apply to it. * BSD echo interprets -n but will print -e, -E, version and help literally * GNU echo interprets all of the above So if you use echo with any non-literal parameter, or with one of the parameters listed above, in a script you distribute to un-controlled third-parties as an sh script (rather than e.g. a bash or zsh script specifically) you will suffer from portability issues. And that's just for measly trivial echo (and incidentally why you should always use printf rather than echo in scripts you try to make portable).
- ape4 11y ago
  Whoever wrote the POSIX spec was too conservative. -n should mean no newline(s). Anything else is wrong.
  - gkya 11y ago
    ECHO(1) FreeBSD General Commands Manual ECHO(1) NAME echo — write arguments to the standard output For this definition, -n should mean merely a sequence of two bytes to be written to stdout. Why not just use printf instead? It is way more flexible and powerfull, and "printf x" always prints "{'x', 0}";.
  - jandrese 11y ago
    The POSIX spec is basically the minimal intersection of all commercial UNIX distros of its day. It defines a minimal system that happened to be what everybody already had implemented. For the most part you are allowed to add features to a POSIX base to make a real OS, since that's what everybody had. This is also why the old Windows POSIX subsystem was so useless. It implemented only the minimal amount needed to check off the box on a feature list, and none of the stuff you need to actually make a system usable. That said, POSIX has a fair bit of braindamage baked in and people can be excused for ignoring the worst parts and instead doing the right thing.
- peterwwillis 11y ago
  The only operating systems that are certified to conform to POSIX are old Unix operating systems. GNU has always been non-POSIX. And honestly, a POSIX implementation would be more trouble than it's worth. The point of coreutils is to have utilities that make up the ability to write scripts for and interact with your operating system, right? Well, what operating system?? A POSIX-compliant one? Or just a mostly-POSIX-compliant one? Or one with POSIX extensions? How would your utilities know the difference? How would the OS know how to deal with these utilities? Would the user know the difference? Ultimately, each platform has quirks, and it is up to the developer to port and test their script or application to a platform and make any necessary changes. This extends to far more than just POSIX compliance.

Ok, I'll bite. What's wrong with "echo -n"?

by gjem97 11y ago

Ok, I'll bite. What's wrong with "echo -n"?

cbr 11y ago

The FreeBSD manpages have: Note that the -n option as well as the effect of `\c' are implementation-defined in IEEE Std 1003.1-2001 (``POSIX.1'') as amended by Cor. 1-2002. -- http://www.freebsd.org/cgi/man.cgi?echo So there's probably some system (or shell) out there where -n doesn't work?

hyperbovine 11y ago

On some Unix variants that will print "-n" followed by a newline. On others it will print the empty string. http://steve-parker.org/sh/echo.shtml http://steve-parker.org/sh/echo.shtml

masklinn 11y ago

http://www.in-ulm.de/~mascheck/various/echo+printf/ http://www.in-ulm.de/~mascheck/various/echo+printf/ is the raw data version. POSIX defines echo as only taking string parameters and no options, but notes that behaviour facing `-n` is implementation-defined. BSD and GNU echo implement `echo -n` as not printing a trailing newline, but `echo` commonly calls to a shell builtin which may or may not follow that behaviour (and may switch behaviour depending on whether the shell is in "sh mode" or not), so `echo -n` could print `-n<newline>` or nothing whatsoever (empty string and suppressed newline) depending on the utils set, the shell, and the shell's runmode. GNU echo also supports -e, -E, --version and --help options, and much like -n shells and other utils set may or may not support these. For instance on my machine (OSX 10.11) * zsh (builtin) interprets -e, -E and -n as options (but not version or help) * bash (builtin) also does, except when invoked as sh in which case it does not and all parameters are literal (this may also apply to zsh) * dash (builtin) interprets -n, but none of the others. bash note may also apply to it. * BSD echo interprets -n but will print -e, -E, version and help literally * GNU echo interprets all of the above So if you use echo with any non-literal parameter, or with one of the parameters listed above, in a script you distribute to un-controlled third-parties as an sh script (rather than e.g. a bash or zsh script specifically) you will suffer from portability issues. And that's just for measly trivial echo (and incidentally why you should always use printf rather than echo in scripts you try to make portable).

ape4 11y ago
Whoever wrote the POSIX spec was too conservative. -n should mean no newline(s). Anything else is wrong.
- gkya 11y ago
  ECHO(1) FreeBSD General Commands Manual ECHO(1) NAME echo — write arguments to the standard output For this definition, -n should mean merely a sequence of two bytes to be written to stdout. Why not just use printf instead? It is way more flexible and powerfull, and "printf x" always prints "{'x', 0}";.
- jandrese 11y ago
  The POSIX spec is basically the minimal intersection of all commercial UNIX distros of its day. It defines a minimal system that happened to be what everybody already had implemented. For the most part you are allowed to add features to a POSIX base to make a real OS, since that's what everybody had. This is also why the old Windows POSIX subsystem was so useless. It implemented only the minimal amount needed to check off the box on a feature list, and none of the stuff you need to actually make a system usable. That said, POSIX has a fair bit of braindamage baked in and people can be excused for ignoring the worst parts and instead doing the right thing.
peterwwillis 11y ago
The only operating systems that are certified to conform to POSIX are old Unix operating systems. GNU has always been non-POSIX. And honestly, a POSIX implementation would be more trouble than it's worth. The point of coreutils is to have utilities that make up the ability to write scripts for and interact with your operating system, right? Well, what operating system?? A POSIX-compliant one? Or just a mostly-POSIX-compliant one? Or one with POSIX extensions? How would your utilities know the difference? How would the OS know how to deal with these utilities? Would the user know the difference? Ultimately, each platform has quirks, and it is up to the developer to port and test their script or application to a platform and make any necessary changes. This extends to far more than just POSIX compliance.