> You don't explain why `print' is more efficient than `echo'.
Short answer: I'm an idiot who didn't realize that `echo' and `[' are
shell builtins. The only parts of my change that still seem worthwhile
to me now are the ones related to the awkward X-comparisons, but there
are few enough of those and they're handled in an idiomatic way, so I'm
not going to bother pushing it. Anybody who has real work to do can
stop reading the email now. The advantage of continuing to read is that
you get some insight into the psychology of a naive user.
Long answer (written partly in a pointless attempt to save face, and
partly to show appreciation to Jeremie's non-condescending response to
what turned out to be a stupid suggestion):
While I vaguely remember reading long ago that `echo' and `[' were
shell builtins, I'm much more strongly aware that /bin/echo and /bin/[
are also available as separate executables. Their man pages don't
mention that they have builtin ksh implementations, and I'm very aware
that `[[' parses arguments differently from `[', e.g.
$ foo="two words"
$ [[ $foo = "two words" ]] && echo True || echo False
True
$ [ $foo = "two words" ] && echo True || echo False
ksh: [: words: unexpected operator/operand
False
which I interpreted as further evidence that `[' and `[[' were
fundamentally different in implementation. Of course, this is wrong,
as "type [" and "type echo" prove. And I remember now that /bin/echo
and /bin/[ are available as separate executables for POSIX reasons,
and that their man pages don't cover the behavior of ksh because they
*aren't* ksh. The point of all of this is that I made an assumption
that seemed reasonable and while I checked some things in the manual,
there were some things I didn't even think to check because they seemed
so obvious. Oops. That happened in another way:
> Nope, ''set -o sh'' sets strict mode on, ''set +o sh'' disables it.
I checked to make sure that "sh" stood for strict mode and not
unstrict mode (since I couldn't understand how that comment could be
so flagrantly wrong), but it never occurred to me to check that `-'
enables something and `+' disables it. Oops again.
In any event, my main goal was to keep us from spawning needless
processes, and my first draft of the change was pretty much just
replacing `[' with `[[' and `echo' with `print.' But since I already
had to change things like [ "$foo" ] to [[ -n "$foo" ]] it seemed
wasteful not to take advantage of the improved argument-parsing of the
`[[' operator and remove the quotation marks, to get [[ -n $foo ]].
But if I'm doing it in some places, I should do it in all places. So
a lot of quotation marks went away to take advantage of the improved
parsing characteristics of `[['.
Some of my other "readability improvements" felt a little awkward and I
couldn't find any reference to shell scripts in style(9) (which I *did*
check before mailing in the proposed change), so I was careful to make
them only in places where I was already breaking stuff. Replacing ``
with $() was an example of that---I left backticks in place in yppasswdd
when I didn't already have a "legitimate" reason to touch the line, and
then I made a point to state explicitly what I had done to see if anyone
would comment on it. Which you did. (I won't try to rationalize my
change to numeric comparisons, since as you say it was a personal
preference, and it was also fairly dubious.)
There's one more specific point I want to make while I'm here about
the awkward X-comparisons: if you search for the phrase "A common
mistake" in the ksh manual, you'll find an example of a comparison
that fails when a variable is unset. Oddly, it only works when the
"if" keyword is used; the "[ foo ] && do_something" construct does not
have any problems.
So, this is the last you'll hear from me on this proposal---it was a
bad idea from the start, and if I had typed "whence -v [" from the
beginning I wouldn't have bothered. But overall I think my
misunderstanding was reasonable, and my "needless churn" would have
been better-received if the underlying reason for the change had been
valid.
And finally, I would again like to thank you (Jeremie) for a thorough
and non-condescending response to a stupid idea. You assumed that I was
sensible enough to read your reviewi and taught me something about the
quote behavior of the eval operator---I hope this (otherwise pointless)
email validates your faith that not all people with stupid ideas are
themselves stupid. And sometimes we read the man pages and we still
miss important things!
Regards,
Anthony
