using cat and <<
in [Shell]
|
From: Ben Bacarisse on 11 Jun 2010 13:21 Seebs <usenet-nospam(a)seebs.net> writes: <snip> > That's brilliant! I suppose your solution to SQL injection attacks > is that you don't do any special quoting, and you just don't actually > write "DROP TABLE USERS;" in any of your SQL. In case anyone has not seen it: http://xkcd.com/327/ <snip> -- Ben.
From: Ed Morton on 11 Jun 2010 15:18 On Jun 11, 9:35 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> 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 > > > ? > > (How can you be posting here and not knowing about `-v'? ;-)) > > I mean, please be verbose. IOW, please provide an example that explains > your argument. > > >>> Add in the portability hassles induced by the whole -n\c thing, and > >>> the difficulty of sanitizing inputs enough to make sure that you aren't > >>> going to run afoul of some "helpful" extension... > >> Yes, don't use `echo -n', or `echo -e' for that matter. That's not a > >> good reason to always use printf(1), though. > > > 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. That is still > no reason to insist on printf(1) when not necessary. > > > And here's the thing. It's never *bad* to use printf(1) on anything newer > > than, I think, SunOS 4.1. So if you just always use it, life is simpler > > and better > > Simpler and better *for whom*? > > > 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 ---------------------- ksh on Solaris: $ printf "hello\nworld\n" hello world $ echo "hello\nworld\n" hello world $ echo -e "hello\nworld\n" -e hello world -------------- Having said that, I almost always use echo anyway. I'm a rebel like that... Ed. > > > and sometimes later revisions to the code break an echo but would have > > been fine with a printf, and so on. > > printf(1) needs to scan the entire string argument for formatting strings > and escape sequences; echo(1) without arguments does not. > > PointedEars
From: Thomas 'PointedEars' Lahn on 11 Jun 2010 16:41 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? PointedEars
From: Thomas 'PointedEars' Lahn on 11 Jun 2010 16:37 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 `--'. >> That is still no reason to insist on printf(1) when not necessary. > > It's not an insistance, it's a piece of advice about good style and > effective defensive coding. > > If you use printf to display output, you have one less point of failure > when trying a new machine or running with user input. I don't buy it. >>> And here's the thing. It's never *bad* to use printf(1) on anything >>> newer than, I think, SunOS 4.1. So if you just always use it, life is >>> simpler and better > >> Simpler and better *for whom*? > > The scripter. And what about the user? >>> 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? > > That's brilliant! I suppose your solution to SQL injection attacks > is that you don't do any special quoting, and you just don't actually > write "DROP TABLE USERS;" in any of your SQL. You're jumping to conclusions. > The problem, again, is not intentionally using these features, but that > you have to know what every possible innovative version of echo will do, > and go to great lengths to ensure that nothing you ever pass to echo will > trip any of these. Lengths of 2. I can live with that. >> printf(1) needs to scan the entire string argument for formatting strings >> and escape sequences; echo(1) without arguments does not. > > This is why: > printf "%s\n" "$var" > is the ideal idiom. You can be confident that NOTHING in $var will > result in anything but the plain literal text being output. Your logic is flawed. PointedEars
From: pk on 11 Jun 2010 16:36
Thomas 'PointedEars' Lahn wrote: >> 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 `--'. It seems *you* don't know about it. (no wonder, uh) |