using cat and <<
in [Shell]
|
From: Chris F.A. Johnson on 11 Jun 2010 17:03 On 2010-06-11, Thomas 'PointedEars' Lahn wrote: > Seebs wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Seebs wrote: >>>> Thomas 'PointedEars' Lahn wrote: >>>>>> Obviously, in this case, they're identical. However, if you have any >>>>>> variable expansion going on, it is quite easy for echo to blow up in >>>>>> inconvenient and/or surprising ways, where printf will be just fine. >>>>> -v please >> >> echo $foo is a variable. >> >> What does this do? >> >> What if someone had executed: >> foo="-n" >> >> What if someone had executed: >> foo='\' >> >> What about: >> foo='-e' >> >> What about: >> foo='\c' >> >> The problem is, echo can easily blow up on some systems (but not on >> others!) for a broad variety of inputs, and for all we know, there's more >> to come. >> >> Imagine: >> for i in $known_opts >> do >> eval description=description_$i >> echo "--$i" " $description" >> end >> >> Now what happens when you hit a version of echo which "helpfully" accepts >> some of $known_opts as extensions? > > You can make up inherently buggy code all you want, that does not change the > fact that `echo' in itself is not more error-prone than `printf'. > >>>> But there are some echos which will do surprising things with other "-x" >>>> type arguments, at least a couple which "helpfully" interpret \ >>>> sequences without any prompting, and so on... >> >>> So do not use those options either as they are not portable. >> >> You don't seem to be comprehending. >> >> The problem is not intentionally using them. The problem is expanding >> values which, being runtime values, you *did not know in advance*, and >> yet, which turn out to accidentally trip those options. > > The problem appears to be that you don't know about `--'. Nor does echo. -- Chris F.A. Johnson, author <http://shell.cfajohnson.com/> =================================================================== Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) ===== My code in this post, if any, assumes the POSIX locale ===== ===== and is released under the GNU General Public Licence =====
From: Ed Morton on 11 Jun 2010 17:32 On 6/11/2010 3:41 PM, Thomas 'PointedEars' Lahn wrote: > Ed Morton wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Seebs wrote: >>>> than if you try to figure out whether you need echo or printf, and >>>> sometimes you guess wrong, >>> How could I guess wrong if I don't use any options? >> >> Sometimes with echo not using options is the wrong choice. For >> example: >> >> ---------------- >> bash on Cygwin: >> >> $ printf "hello\nworld\n" >> hello >> world >> >> $ echo "hello\nworld\n" >> hello\nworld\n >> $ echo -e "hello\nworld\n" >> hello >> world > > Unfortunately, you don't seem to pay attention. Did I or did I not > recommend _not_ to use `echo -e'? Did I or did I not recommend to use > `printf' *in* *that* *case* instead? Did you or did you not say "How could I guess wrong if I don't use any options?". Did I or did I not answer your question? Do I or do I not care? All good questions but hopefully you've now seen enough examples of why people are telling you it's good practice to use printf that you'll stop posturing and everyone can stop trying to explain it to you. Ed.
From: Seebs on 11 Jun 2010 20:09 On 2010-06-11, Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: > Unfortunately, you don't seem to pay attention. Did I or did I not > recommend _not_ to use `echo -e'? You did, but in that case, it may produce the wrong answers. But on another machine, it might do something else. > Did I or did I not recommend to use > `printf' *in* *that* *case* instead? Let us phrase the question another way. You have two choices about how to do something. One works about 80% of the time, unless there are surprises you haven't thought of yet, or user input changes things. One works 100% of the time, regardless of anything users could ever provide as input. You suggest that we should try to identify the 80% of the time the first one works, and use it in those cases. I suggest that you should always use the one that is guaranteed to work. What is your argument for why we shouldn't always use printf? -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Seebs on 11 Jun 2010 20:42 On 2010-06-11, Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: > You can make up inherently buggy code all you want, that does not change the > fact that `echo' in itself is not more error-prone than `printf'. Nonsense. Across a variety of systems, there are a huge number of inputs which will behave differently between different systems. Since people usually expand variables in shell scripts, that means that some portion of the inputs to echo will usually be outside the immediate control of the script, meaning that it is likely to occasionally behave surprisingly. >> The problem is not intentionally using them. The problem is expanding >> values which, being runtime values, you *did not know in advance*, and >> yet, which turn out to accidentally trip those options. > The problem appears to be that you don't know about `--'. Hah! Gotcha. $ echo -- -- How about backslashes? What's your guarantee that no user-provided string given to you at runtime will ever have a backslash in it that echo might interpret on some systems but not others? "--" is not special to echo. Unless you find an echo where it is special. > I don't buy it. I see that, but I don't see why. >> The scripter. > And what about the user? At worst, there is no difference at all. The only case in which there's a difference in when echo is misbehaving, at which point, that likely makes things more complicated for the user. > Lengths of 2. I can live with that. Except that, as shown above, your best theory as to how to make echo behave more predictably was wrong. > Your logic is flawed. So you say, but you haven't explained why. Undisputed fact #1: There exists no string whatsoever for which printf "%s" "$var" will fail to print the contents of $var without a following newline, and there likewise exists no string whatsoever for which printf "%s\n" "$var" will fail to print the contents of $var followed by a newline. Undisputed fact #2: There exist an extremely large set of strings which will behave differently on different varieties of echo, such that you cannot reliably predict in advance what the effect of echo "$var" will be without knowing both the contents of $var and the implementation of echo which will try to echo it. So. Given that one of these things is 100% reliable and cannot fail, and the other can easily fail *whether or not* you intentionally pass any special arguments to it... The problem here is that you're stuck on the theory that "don't use those features" is all it takes. The problem is that, to do that, you have to know what all of them are and avoid them, and to avoid them, you have to ensure not only that the literals you pass to echo never trip any of these features, but also that variables which are being expanded never trip them. And that is Too Hard. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Seebs on 11 Jun 2010 20:44
On 2010-06-11, Chris F.A. Johnson <cfajohnson(a)gmail.com> wrote: > On 2010-06-11, Thomas 'PointedEars' Lahn wrote: >> The problem appears to be that you don't know about `--'. > Nor does echo. In his defense, I suspect that at least one person has created at least one version of "echo" which did. Trying to predict the possible ways in which someone somewhere has broken echo is hopeless. I am reasonably sure there has been at least one version of false which could be persuaded to print a version message and exit successfully, just because people really are that stupid. I'm quite sure that I've seen an implementation where "true --version" produced output on stdout or stderr... I believe it's since been fixed. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! |