Subject: Re: This has GOT to be a bug in ksh...
To: NetBSD User's Discussion List <netbsd-users@netbsd.org>
From: Robert Elz <kre@munnari.OZ.AU>
List: netbsd-users
Date: 06/19/2002 17:19:06
Date: Tue, 18 Jun 2002 14:27:50 -0400 (EDT)
From: woods@weird.com (Greg A. Woods)
Message-ID: <20020618182750.9CE98AC@proven.weird.com>
| Why are you still longing after all these years
| for something that really does not exist in the same form any more?
Hmmm...
delta$ /bin/sh
\h\$ echo "hello\tand more"
hello\tand more
\h\$ delta$ /bin/csh
delta % echo "hello\tand more"
hello\tand more
delta % exit
delta$ /usr/pkg/bin/bash
delta$ echo "hello\tand more"
hello\tand more
delta$ exit
delta$ /bin/echo "hello\tand more"
hello\tand more
delta$
What is it exactly that is no longer existing ??
(No accident that I omitted ksh, its echo is broken...)
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.
Here, they're broken. Because of gross stupidity, echo ended up
having two wildly different forms and now scripts that want to be
portable all have to cope with that, and do ...
case `echo '\c'` in
'\c') N=-n C='';;
'') N= C='\c';;
esac
echo $N prompt$C
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.
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...
| all we need to do is get the contents of the variable containing the
| filename written verbatim to some tool that'll copy it to stdout and of
| course that's pretty easy to do with a Bourne-compatible shell:
That's certainly a possibility I guess, though an exceedingly ugly one.
| If your definition of "works" is to print exactly the name of the file
| then you've got other far more serious problems to deal with -- you'll
| need to know the exact type of device you're writing to
No, that's a different problem - for now, you can consider that stdout is
being redirected to a file, there are no strange device characteristics to
consider.
kre
ps: I cannot imagine why anyone would do:
echo "Now processing: \c"
vis -ctl <<__END__
$file
__END__
instead of just:
vis -ctl <<__END__
Now processing: $file
__END__