Hi All

When using indent program to reformat shell program as below. how to
using cat << as normal ?

k=1
if [ k != 0 ] ; then
    cat <<-EOF
    Hello World.
    EOF
fi

test_eof.ksh[2]: 0403-057 Syntax error at line 2 : `<' is not matched.

In article <a613dd2b-e13d-4bfa-9778-749c561f9973@v12g2000prb.googlegroups.com>,
moonhkt  <moonhkt@gmail.com> wrote:
>Hi All
>
>When using indent program to reformat shell program as below. how to
>using cat << as normal ?
>
>k=1
>if [ k != 0 ] ; then
>    cat <<-EOF
>    Hello World.
>    EOF
>fi
>
>test_eof.ksh[2]: 0403-057 Syntax error at line 2 : `<' is not matched.

Replace the above with:

echo "Hello World."

-- 
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

On 2010-06-11, moonhkt <moonhkt@gmail.com> wrote:
> When using indent program to reformat shell program as below. how to
> using cat << as normal ?

Don't use a indent to reformat a shell program.  Indent is a tool
for formatting C code.  It does not support shell particularly well,
in any of the versions I've used.

<<- strips tabs, not all whitespace.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

gazelle@shell.xmission.com (Kenny McCormack) writes:

> Replace the above with:
>
> echo "Hello World."

Or, more portably:

    printf "Hello World.\n"

-- 
 \       Moriarty: “Forty thousand million billion dollars? That money |
  `\            must be worth a fortune!” —The Goon Show, _The Sale of |
_o__)                                                       Manhattan_ |
Ben Finney

In article <87k4q65l6u.fsf@benfinney.id.au>,
Ben Finney  <ben+unix@benfinney.id.au> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>
>> Replace the above with:
>>
>> echo "Hello World."
>
>Or, more portably:
>
>    printf "Hello World.\n"

Good point.

-- 
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

On Thu, 10 Jun 2010 21:26:28 -0400, moonhkt <moonhkt@gmail.com> wrote:

> When using indent program to reformat shell program as below. how to
> using cat << as normal ?
>
> k=1
> if [ k != 0 ] ; then
>     cat <<-EOF
>     Hello World.
>     EOF
> fi
>
> test_eof.ksh[2]: 0403-057 Syntax error at line 2 : `<' is not matched.

unexpand -t 4 test_eof.ksh>test2.ksh

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On 6=E6=9C=8811=E6=97=A5, =E4=B8=8A=E5=8D=8811=E6=97=B633=E5=88=86, "David =
W. Hodgins" <dwhodg...@nomail.afraid.org>
wrote:
> On Thu, 10 Jun 2010 21:26:28 -0400, moonhkt <moon...@gmail.com> wrote:
> > When using indent program to reformat shell program as below. how to
> > using cat << as normal ?
>
> > k=3D1
> > if [ k !=3D 0 ] ; then
> > =C2=A0 =C2=A0 cat <<-EOF
> > =C2=A0 =C2=A0 Hello World.
> > =C2=A0 =C2=A0 EOF
> > fi
>
> > test_eof.ksh[2]: 0403-057 Syntax error at line 2 : `<' is not matched.
>
> unexpand -t 4 test_eof.ksh>test2.ksh
>
> Regards, Dave Hodgins
>
> --
> Change nomail.afraid.org to ody.ca to reply by email.
> (nomail.afraid.org has been set up specifically for
> use in usenet. Feel free to use it yourself.)

Any good indent program for ksh ?
Some of programs, using cat << to build text file.

I download someone perl program for indent ksh.
fmt.pl -s4 -ksh test_eof.ksh > abc.ksh


usage:
fmt.pl -help
fmt.pl [-t|-s#] [-ksh|-sh] [infile [outfile]]
-t              indent is one tab character (default)
-s#             indent is <#> space characters
-sh             script is Bourne shell
-ksh            script is Korn shell
infile          input  file name (default STDIN)
outfile         output file name (default STDOUT)
notes:
* you can use '-' for STDIN/STDOUT
* fmt.pl gives outfile execute permissions when possible
example:
* to convert an ugly script into a pretty script, using a 4space
indent:
fmt.pl -s4 script.ugly script.pretty

Ben Finney wrote:

> gazelle@shell.xmission.com (Kenny McCormack) writes:
>> Replace the above with:
>>
>> echo "Hello World."
> 
> Or, more portably:
> 
>     printf "Hello World.\n"

How did you get that idea?


PointedEars

In article <2348862.I6sBWrkQq0@PointedEars.de>,
Thomas 'PointedEars' Lahn  <usenet@PointedEars.de> wrote:
>Ben Finney wrote:
>
>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>> Replace the above with:
>>>
>>> echo "Hello World."
>> 
>> Or, more portably:
>> 
>>     printf "Hello World.\n"
>
>How did you get that idea?

It is one of the doctrinaire points of this NG that echo is "non-portable".
So, you use the equivalent printf if you want people to think you are cool.

-- 
(This discussion group is about C, ...)

Wrong.  It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...

On 2010-06-11, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> Ben Finney wrote:
>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>> Replace the above with:

>>> echo "Hello World."

>> Or, more portably:

>>     printf "Hello World.\n"

> How did you get that idea?

In this particular case, there's no real difference.  As a general rule,
if you have a choice between echo(1) and printf(1), you should use printf(1)
often enough that it's probably best to just always use it.

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.
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...

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Ben Finney wrote:
>>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>>> Replace the above with:
>>>> 
>>>> echo "Hello World."
>>> 
>>> Or, more portably:
>>> 
>>>     printf "Hello World.\n"
>> 
>> How did you get that idea?
> 
> In this particular case, there's no real difference.  As a general rule,
> if you have a choice between echo(1) and printf(1), you should use
> printf(1) often enough that it's probably best to just always use it.

IBTD.  I use printf(1) only when necessary, i.e. when I don't want a 
trailing newline, or when I need a value to be formatted.
 
> 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

> 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.


PointedEars

On 2010-06-11, Thomas 'PointedEars' Lahn <PointedEars@web.de> 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

?

>> 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...

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 than if you try to figure out whether you need echo or printf,
and sometimes you guess wrong, and sometimes later revisions to the code
break an echo but would have been fine with a printf, and so on.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

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?

> 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

In article <slrni14h94.iv2.usenet-nospam@guild.seebs.net>,
Seebs  <usenet-nospam@seebs.net> wrote:
....
>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 than if you try to figure out whether you need echo or printf,
>and sometimes you guess wrong, and sometimes later revisions to the code
>break an echo but would have been fine with a printf, and so on.

Like a stopped clock, and against all odds, Mr. Seebs is actually right
here.  I realized quite a while ago that it was easier and better to
just always use printf.

-- 
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

On 2010-06-11, Thomas 'PointedEars' Lahn <PointedEars@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 know about it, but not about that usage.

> I mean, please be verbose.  IOW, please provide an example that explains 
> your argument.

	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?

>> 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.

> 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.

>> 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.

>> 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.

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.

> 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.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-nospam@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.

On Jun 11, 9:35=A0am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Seebs wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >>> Obviously, in this case, they're identical. =A0However, if you have a=
ny
> >>> 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. =A0IOW, please provide an example that explain=
s
> 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. =A0That'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 \ sequenc=
es
> > without any prompting, and so on...
>
> So do not use those options either as they are not portable. =A0That is s=
till
> no reason to insist on printf(1) when not necessary.
>
> > And here's the thing. =A0It's never *bad* to use printf(1) on anything =
newer
> > than, I think, SunOS 4.1. =A0So if you just always use it, life is simp=
ler
> > 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

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)

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

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

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    =====

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.

On 2010-06-11, Thomas 'PointedEars' Lahn <PointedEars@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@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-06-11, Thomas 'PointedEars' Lahn <PointedEars@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@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-06-11, Chris F.A. Johnson <cfajohnson@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@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-06-12, Seebs wrote:
> On 2010-06-11, Chris F.A. Johnson <cfajohnson@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.

$ /bin/true --version
true (GNU coreutils) 7.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


-- 
   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)

On 2010-06-12, Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
> On 2010-06-12, Seebs wrote:
>> On 2010-06-11, Chris F.A. Johnson <cfajohnson@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.
>
> $ /bin/true --version
> true (GNU coreutils) 7.1
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.

You coreutils is a year old:

20:03,501$ /bin/true --version
true (GNU coreutils) 8.5
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Jim Meyering.

On 2010-06-12, Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
> $ /bin/true --version
> true (GNU coreutils) 7.1
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.

Ahh, but does "/bin/false --version" exit successfully, because it
successfully printed the version?  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-06-12, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-06-12, Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
>> $ /bin/true --version
>> true (GNU coreutils) 7.1
>> Copyright (C) 2009 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>
> Ahh, but does "/bin/false --version" exit successfully, because it
> successfully printed the version?  :)

22:25,501$ /bin/false --version
false (GNU coreutils) 8.5
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Jim Meyering.

22:25,502,(1)$

Nope, returns 1.

Seebs wrote:
> On 2010-06-12, Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
>> $ /bin/true --version
>> true (GNU coreutils) 7.1
>> Copyright (C) 2009 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
> 
> Ahh, but does "/bin/false --version" exit successfully, because it
> successfully printed the version?  :)
> 
> -s

Why would you care????

i don't use --version in my scripts
and when I type
false --version, then I don't care for it's exit status.

You can always construct failing scenario, but I cannot imagine whenever
 an exit code of 0 would have killed me or my scripts.

On 2010-06-12, News123 <news1234@free.fr> wrote:
> Why would you care????

Because unexpected behaviors can cause serious problems.

> i don't use --version in my scripts
> and when I type
> false --version, then I don't care for it's exit status.

One idiom one occasionally sees is:

	: ${foo:=$bar}

or

	true ${foo:=$bar}

which serves as a way to expand a variable for the side-effects of the
expansion.  This idiom can have unexpected results if ANY argument to
true can cause it to do something.

> You can always construct failing scenario, but I cannot imagine whenever
>  an exit code of 0 would have killed me or my scripts.

If you were counting on false returning false, it could cause surprises.

On the other hand, more likely is that the output would cause problems.
One of the most obnoxious bits of code I ever encountered was a configure
script (not an autoconf one) which attempted to test for compiler
functionality as follows:

	$CC <options> -o foo.o foo.c > conf.out 2>&1
	if [ -s conf.out ]; then echo >&2 "Not supported."; fi

This assumed that the only circumstances under which a compiler could
ever yield a message of any sort would be compilation failure; however,
we had a compiler which, in a development environment, would sometimes
print a warning that it hadn't found a license manager.  It was a purely
advisory warning, and compilation succeeded.

I am sure there is other code out there which will blow up if programs
which are not expected to produce output to.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

>>>>> "Seebs" == Seebs  <usenet-nospam@seebs.net> writes:

Seebs> One works 100% of the time, regardless of anything users could
Seebs> ever provide as input.

Unless "printf" isn't installed.  It's a relatively recent addition to
Unix, and therefore, non-portable, while every version of Unix I've used
has had echo (although there are variations in argument interpretation).

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Randal L. Schwartz wrote:

> Unless "printf" isn't installed.  It's a relatively recent
> addition to Unix, and therefore, non-portable,

printf was introduced with 9th edition and then added to more
widely distributed Unix flavours with 4.3BSD-Reno and SVR4.
(And apart from traditional portability, it's required by
POSIX/SUSv2.)

I believe the only possibly relevant systems nowadays which
are missing it are SunOS 4 and SVR3 derivatives.
-- 
http://www.in-ulm.de/~mascheck/various/echo+printf/

On 2010-06-12, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Seebs" == Seebs  <usenet-nospam@seebs.net> writes:
>Seebs> One works 100% of the time, regardless of anything users could
>Seebs> ever provide as input.

> Unless "printf" isn't installed.  It's a relatively recent addition to
> Unix, and therefore, non-portable, while every version of Unix I've used
> has had echo (although there are variations in argument interpretation).

You echo my own thoughts, and those of my technical reviewer.  I thought it
was a BSD introduction, and I believe he thought it was a Linuxism.  We
both thought it was not particularly portable.

Then we actually TESTED it.  And we have found nothing -- no SVRx, no
BSD, no Linux -- which lacks it, except SunOS 4.1, or things even older
than that.

"Relatively recent", it turns out, appears to be upwards of twenty years
ago.  Tru64, OSF/1, Solaris, BSD, Linux, you name it.  It helps, of course,
that it's a built-in in at least one common shell.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-06-13, Seebs wrote:
> On 2010-06-12, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>>> "Seebs" == Seebs  <usenet-nospam@seebs.net> writes:
>>Seebs> One works 100% of the time, regardless of anything users could
>>Seebs> ever provide as input.
>
>> Unless "printf" isn't installed.  It's a relatively recent addition to
>> Unix, and therefore, non-portable, while every version of Unix I've used
>> has had echo (although there are variations in argument interpretation).
>
> You echo my own thoughts, and those of my technical reviewer.  I thought it
> was a BSD introduction, and I believe he thought it was a Linuxism.  We
> both thought it was not particularly portable.
>
> Then we actually TESTED it.  And we have found nothing -- no SVRx, no
> BSD, no Linux -- which lacks it, except SunOS 4.1, or things even older
> than that.
>
> "Relatively recent", it turns out, appears to be upwards of twenty years
> ago.  Tru64, OSF/1, Solaris, BSD, Linux, you name it.  It helps, of course,
> that it's a built-in in at least one common shell.

   It's a builtin in all the most common shells: bash, ksh93, dash,
   BSD's sh.

-- 
   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)

Chris F.A. Johnson wrote:

> [printf]
> It's a builtin in all the most common shells: bash, ksh93, dash,
> BSD's sh.

Only on NetBSD (ash variant), but not FreeBSD (ash variant) since ~5.0
or OpenBSD (pdksh).

And not in ksh88 (might still count as common shell).

>>>>> "Seebs" == Seebs  <usenet-nospam@seebs.net> writes:

Seebs> "Relatively recent", it turns out, appears to be upwards of
Seebs> twenty years ago.  Tru64, OSF/1, Solaris, BSD, Linux, you name
Seebs> it.  It helps, of course, that it's a built-in in at least one
Seebs> common shell.

Since I started working with Unix in 1977, I *do* consider 1990
to be "relatively recent". :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

On 2010-06-14, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Seebs" == Seebs  <usenet-nospam@seebs.net> writes:
>Seebs> "Relatively recent", it turns out, appears to be upwards of
>Seebs> twenty years ago.  Tru64, OSF/1, Solaris, BSD, Linux, you name
>Seebs> it.  It helps, of course, that it's a built-in in at least one
>Seebs> common shell.

> Since I started working with Unix in 1977, I *do* consider 1990
> to be "relatively recent". :)

To some extent, I do too, but in terms of portability, in practice, I
really haven't cared about stuff that old in a long time.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

> k=1
> if [ k != 0 ] ; then
>     cat <<-EOF
>     Hello World.
>     EOF
> fi
> 
> test_eof.ksh[2]: 0403-057 Syntax error at line 2 : `<' is not matched.

I don't think anyone has actually solved your problem.
There are two errors.  One, is that -EOF does not match EOF.
The other, is that you are actually trying to match "\tEOF"
at the end.  So:

k=1
if [ k != 0 ] ; then
    cat << EOF
    Hello World.
EOF
fi

    Hello World.

You probably don't want the tab in front of
'Hello World' either.

Toby

Tobiah <toby@rcsreg.com> writes:

> > k=1
> > if [ k != 0 ] ; then
> >     cat <<-EOF
> >     Hello World.
> >     EOF
> > fi
> > 
> > test_eof.ksh[2]: 0403-057 Syntax error at line 2 : `<' is not matched.
[…]

> There are two errors.  One, is that -EOF does not match EOF.
> The other, is that you are actually trying to match "\tEOF"
> at the end.

The above ‘cat’ command is using the ‘<<-’ operator, and the delimiter
word is ‘EOF’. From the SUSv7 specification for “Here Documents”:

    The redirection operators "<<" and "<<-" both allow redirection of
    lines contained in a shell input file, known as a "here-document",
    to the input of a command.
    […]

    If the redirection symbol is "<<-" , all leading <tab> characters
    shall be stripped from input lines and the line containing the
    trailing delimiter. If more than one "<<" or "<<-" operator is
    specified on a line, the here-document associated with the first
    operator shall be supplied first by the application and shall be
    read first by the shell.

    <URL:http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04>

-- 
 \           “Never express yourself more clearly than you are able to |
  `\                                               think.” —Niels Bohr |
_o__)                                                                  |
Ben Finney