On Thu Oct 10, 2024 at 1:22 AM CEST, G. Branden Robinson wrote: > [...] > > The value of printf(1) lies not in its firepower (which is indeed > supercharged for many [most?] shell applications) but its > _predictability_. > > printf(1) is a POSIX invention because of an old BSD vs. System V > conflict over how `echo` should behave. > > [...] > > Worse, I can't ever remember the rules about how a backslash is > interpreted in echo...do I need to double it? Should I not even bother > because it's not going to be portable anyway? > > My very rough rule of thumb (and I don't promise that all of groff's > test scripts follow this principle perfectly) is that echo is okay if no > literal `\` appears in its argument list. If one does, I need to switch > to printf(1). If a shell variable might expand to include a `\`, I also > don't know what to expect and typically retreat to printf(1) in fear.
The interpretation of backslashes depends on the implementation, which is why I don't use echo in most scripts. (It seems easier than to think about the input every time like you do :).) For instance, running `echo '\n'` outputs \n followed by newline in bash and two newlines in dash. Checking the manpages of dash and bash reveals that dash's echo always interprets escape sequences, whereas bash's interprets them only with the -e flag (which dash's doesn't know and treats as an argument, i.e. it prints it like anything else). This clearly shows that your suspicion is correct -- there is no portable way to include a backslash in an argument to echo. ~ onf
