[ On Wednesday, June 19, 2002 at 17:19:06 (+0700), Robert Elz wrote: ]
> Subject: Re: This has GOT to be a bug in ksh... 
>
> What the stds docs might claim should be done is all very nice, but
> anywhere they're wrong, they're ignored - which is exactly as it
> should be.   Eventually they can be corrected.

I would respectuflly suggest that it seems you have not ported a wide
variety of shell scripts to a wide variety of Unix and Unix-like systems
over the years.  I spent a great deal of my professional (and also quite
a bit of my personal hobby time) between 1989 and 1994, through the
thick of the commercial UNIX wars, porting a very wide variety of
software, including tens of thousands of lines of shell scripts written
by dozens of different programmers, to almost every Unix and Unix-like
implementation available during those years.  One of the most
interesting, in this context, of those programs was C-News, right from
it's early alpha days through to its final releases.  One of the
companies I worked for during those years used it as part of a service
offering.  As you may know, C-News contains a lot of shell scripts, some
of which are quite complex and use some tricky idioms.

> Here, they're broken.   Because of gross stupidity, echo ended up
> having two wildly different forms 

Perhaps you should re-read the K&P description of 'echo' and while doing
so try to keep in mind that the widest variety of commercial unix
offerings necessarily chose to follow the SysV way of implementing
'echo'.  Note that K&P agree there's no right/wrong way to do this, and
that each implementation has its advantages and disadvantages.

>   and now scripts that want to be
> portable all have to cope with that, and do ...

Yes well written scripts have to resort to such sillyness (and when you
get deep into the thick of it there are even more traps to worry about).
(I've already shown the similar code fragments I use in my ~/.profile.)

However that's not what I was trying to resolve in the other thread we
were discussing 'echo' in.  There I tried to show how it is possible to
define a standards-compliant implementation that allows most
non-portable scripts to work regardless of which ancient implementation
they were originally written to expect.

> Unlike other utilities that had diverged, there is/was no way to
> reconcile this one.   The choices had to be to deprecate echo completely
> (omit it from the standards - which is probably the choice that should
> have been made) or pick one or the other.

Actually given the way 'echo' is most commonly used in shell scripts
there is a simple way to reconcile these problems.  It is defined by my
proposed implementation (the one I discussed in that other thread).  My
version allows the widest variety of uses to function in the way their
authors expected them to, without change.  I.e. it makes the greatest
number of existing shell scripts portable without change.  Remember too
that my proposed implementation is compliant with the first edition of
1003.2 (1992).  It would be nice if the upcoming revision of POSIX
1003.2 were to fully describe my implementation, but it's not necessary
so long as it doesn't ban the implementation-defined behavior I depend
upon.

> If one was to be picked, the one that best achieved the purpose should
> have been picked, rather than the one that happened to be supported
> by the largest number of people attending the meeting...

I believe the problem was defining the purpose of 'echo' in the first
place.  I seem to remember discussion on Usenet about how best to get
raw arbitrary variable contents into stdin of a process, or redirected
to a file, without tripping over any of the "extra" features of 'echo'
and the consensus at the time was to use 'here' docs as I've shown.

IMVNSHO the SysV style implementation best achieves the purpose of
'echo', as it is most commonly used in shell scripts.  The original V7
implementation is just not quite flexible enough for all common uses.

> ps: I cannot imagine why anyone would do:
> 
> 		echo "Now processing:  \c"
> 		vis -ctl <<__END__
> $file
> __END__

The trailing echo "" is necessary, btw....

> instead of just:
> 
> 	vis -ctl <<__END__
> Now processing: $file
> __END__

You should try the original 'for' loop I showed in my example and see!  :-)
Also consider the effect of 'vis -cw'.  For the purposes of an example
that demonstrates the technique it's best to isolate the fluff of the
extra text phrase from the meat of how to get at the raw contents of a
variable without using 'echo'.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>