On Sunday 06 August 2006 12:08, Steven W. Orr wrote:
> Never use backquotes when the $( cmd ) is available. The backquotes
> are deprecated in bash and ksh and are only available in antique
> Bourne shells. In addition there are subtle differences in quoting
> between the two.
Actually backquotes (grave accents) are the defined syntax in both sh
and ksh. The ksh added the $(...) syntax, but did not deprecate the
backquotes. Here's a look at Solaris 9:
$ sh -c 'echo `ls`'
file1 file2
$ sh -c 'echo $(ls)'
sh: syntax error at line 1: `(' unexpected
$ ksh -c 'echo `ls`'
file1 file2
$ ksh -c 'echo $(ls)'
file1 file2
>From the manual page for ksh(1), the backquotes are not described as
deprecated (although the manual page calls them "archaic"):
Command Substitution
The standard output from a command enclosed in parenthesis
preceded by a dollar sign (that is, $(command)) or a pair of
grave accents (``) may be used as part or all of a word;
trailing new-lines are removed. In the second (archaic)
form, the string between the quotes is processed for special
quoting characters before the command is executed.
The ksh(1) manual page discusses historical restrictions, but still
falls short of calling backquotes deprecated:
Because of these inconsistent behaviors, the backquoted
variety of command substitution is not recommended for new
applications that nest command substitutions or attempt to
embed complex scripts.
It looks like the author of ksh went out of his way to assure his
claim that ksh was downward-compatible with sh(1) by retaining
"historical restrictions".
Of course, command substitution is *defined* using the backquotes in
the (current version of) sh.
I think that the author of the ksh(1) manual page was editorializing
when he called backquotes archaic because the Borne shell is assumed
to be available on any UNIX-like system and coding scripts to it is
commonly expected to be portable across many different systems and
because the Korn shell does not deprecate it.
The bash(1) manual page doesn't call the backquotes deprecated either.
The author of that manual page calls them "old-style". Not quite as
pejorative. :-)
My editorial remark is that the authors of bash make a mistake when
they do not reject $(...) in a script run by /bin/sh. That breaks the
portability that most expect using /bin/sh. Granted, it's not a
terrible break because correct /bin/sh scripts behave as expected (I
think).
If you want an example of what kind of havoc breaking historical
precedents like this does, take a look at what IBM did with AIX's
/bin/sh. They really placed ksh in that binary (renaming the original
Borne shell to /bin/bsh). This silly and capricious change broke the
Perl Configure script among other irritating nonsense.
People really do rely on historical standards. UNIX defined /bin/sh a
certain way that became expected for portability. IBM broke that for
no good reason. The bash shell flirts with the same mistake.
--
Garry T. Williams --- +1 678 656-4579
