Re: Bash script variables question[Scanned]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux