Bob Proulx <b...@proulx.com> writes: > The "-n" in the "string" position is listed specifically as an > exception to the general rule previously stated. Basically an > interpretation might be don't implement getopt option processing in > general but look specifically at the first argument for this specific > case, it being implementation defined.
Ok, this looks like a reasonable interpretation. Though in my mind, exceptions need to be more explicit (like in "Hey ho ! Beware ! This is a EXCEPTION ! ..."). Otherwise I tend to see "Don't do X. When doing X do Y" as an inconsistency. > Originally POSIX was not the design document it has become in later > years. Originally POSIX was an operating system feature > non-proliferation treaty trying to keep the differences among systems > from becoming even more different. At the time it was created there > were already two major flavors of echo on different systems. And it > was already a portability problem. Therefore the standard tried to > freeze the common feature set and allow the existing differences. I trust you on this. >> > Unix v7 echo accepted -n as an option and did not print it. Same >> > with BSD. It is too late to mess with it now. >> >> Then these implementations are broken as well. > > That point is similar to saying that one should choose their parents > better. It may be true! But it is pointless because one does not > have the possibility of choosing their parents. > > And similarly when echo was originally created it was done without the > benefit of 50 years of hindsight looking back at the problems the > choices made then have caused over the years and still continue to > cause now. > >> Also, I can understand that one may not want to change the behavior >> of a command that has been used for 30 years. > > That's the main point of the discussion. It's been 50 years and some > expectation of stability should be maintained. Ok, I understand your point. > On the other hand if people want to fix everything then I think they > should be free to create their own new operating system and do so > there. That's fine. New systems don't have legacy and don't need to > be backward compatible. So break whatever you want there. But don't > break the existing system for others along the way. I'm not there yet ; ) >> On a practical level, I have seen the 'echo' command being used in >> many shell scripts to process arbitrary strings. Which means that in >> some cases (when processing the strings "-n", "-e" or "-E") these >> scripts won't behave as expected by the programmer. > > Then those are the bugs to have fixed. Indeed, 'printf' for the win ! (Like in "if you can't fix something use something else" ; ) > I still use echo to this very day. > > echo "Hello world!" > > But that does not include any options and does not include any > backslash escape sequences. If it did or if there was any possibility > of it doing so then I would program it differently. > > printf "What do you want me to say? " > IFS= read -r phrase > echo $phrase # Noooo! > > printf "What do you want me to say? " > IFS= read -r phrase > printf "%s\n" "$phrase" # Yes! > > The above shows input from an untrusted source. It's "tainted". It > should not be used without caution. Indeed, this looks like a fair use of echo and printf. >> That is also true, though chances are that the shell builtin >> implementations of 'echo' be probably inspired (if not copied) from >> the GNU echo implementation. > > Actually no. Their behaviors were based upon existing echo > implementations that pre-date GNU echo that GNU echo was itself also > based upon. Ok, I trust you on this one as well. >> What I would expect from a good implementation of the 'echo' command >> is to interpret the '--' argument to signify the end of the options, >> therefore removing any ambiguity in the interpretation of the strings >> to display. That would be the (non-posix) default behavior. Then the >> command would have a POSIX compliant behavior with the POSIXLY_CORRECT >> flag, which wouldn't interpret any option at all. > > Please no. That would create yet another different behavior case. It > would be yet again one of the different odd unusual unique things that > would need to be programmed around with horrid code. Plus we have > already been there and done that. The result of which was "printf" > which was created as the answer to the problem. Fair enough. >> Besides, I understand that the current implementation of the GNU >> 'echo' command has been used for several decades now, and that it >> may be difficult to change its behavior. > > Yes. A very long time. Try 50 years of "echo"! Didn't think an issue could last that long ; ) >> In which case, thoroughly documenting the edge cases of the 'echo' >> command and inviting programmers to use 'printf' instead on its >> manpage (I know 'printf' is mentioned on the coreutils info page, >> but it's one additional level of indirection) would probably be >> helpful for the community. I'd gladly try to update the manpage if >> that be the way to go. > > That's an excellent idea. I agree completely. We should document > echo behavior and invite programmers to use printf instead. :-) Let's do that then. Cheers, Florent
