Pardon my soap box stilt, but I hate to see people struggle with UNIX
because of the goofy shell stuff.

The quotes are not quotes. They're backticks.
Quotes are a sore spot with me. The grammar for the shell is context
sensitive.
How quotes are are interpreted depends on what state the parser is in.
Eval causes the parser to re-evaluate the expression, effectively overriding
the parser's state machine.

This is one of the most confusing aspects of the shell. 
The "proper" syntax for backticks in the Korn shell is $(command)
The backtick syntax makes the construct backward-compatible(portable) with
the bourne and 'C' shells.

What is happening in the back tick expression is that the shell passes the
argument inside the ticks to the
Exec() system call after executing pipe() and fork() system calls to
redirect stdin and stdout. (see man pages)

There are some pitfalls. Only output on stdout from the command is placed
into the variable. 
Output on stderr is not placed in the variable, but bleeds out to whatever
file 
or device is associated with stderr (normally the controlling terminal). 
If the command fails the variable will be set but null if it produces no
output on stdout.
This is often the case when the command encounters and error.
$? Is assigned with the exit status of the command.
If commandline is a pipeline then only the rightmost command in the pipeline
is returned in $?.

I can't tell you how many times I've had to fix shell scripts that only work
on sunny days.
Pipelines in backticks are probably the most common source of trouble.
Script will hang if a command in the pipeline exits without closing stdout,
e.g. via kill -9

My general rule is that once you need to run a command and collect it's
output it's time to use a better tool.
Perl is a better shell for doing systems programming. Your scripts will be
more reliable. Pretty much everything you would need backticks for in the
shell has a built-in function to do in perl.
Perl at least checks syntax before execution. Perl has a goto so if your
script fails partway through a job
You can edit the script with a goto and skip the things that worked OK.
Shell won't tell you about syntactically incorrect code in branches not
taken! 
It's hard to test scripts that have code that normally doesn't execute.
Not nice to find out your script has syntax errors when something goes
wrong.


I recommend "Learning the Korn Shell" by Bill Rosenblattt ( nutshell series
O'reilly )
Book has tons of info, but unfortunately there's no good way to organize
information on
such an unruly program as the shell. 

To see what's under the hood run your script through tusc utility ( trace
unix system calls ).
It' available on HP's web site.

Here's something to illustrate my points. Try uncommenting things and watch
what happens

#!/usr/bin/ksh
unset s
set -o nounset
#set -o errexit
#set -o
#s=`ls foo`
s=$(ls)  #`ls`
print  $?
if [[ -z $s ]]
then 
  print "bad thing happened, s is null"
  print $s
else 
  print "it's a sunny day, s is [$s]"
Fi


Save script as pipe.ksh (chmod u+x) and run tusc -a -f ./pipe.ksh
Search for pipe in the output and you'll see the underlying system calls.









-----Original Message-----
From: HP9000 Computer Systems discussion list
[mailto:[log in to unmask]] On Behalf Of Dave Waroff
Sent: Wednesday, February 01, 2006 11:47 AM
To: [log in to unmask]
Subject: Re: [HP9000-L] quoting

-----Original Message-----
From: HP9000 Computer Systems discussion list
[mailto:[log in to unmask]] On Behalf Of donna garverick
Sent: Tuesday, January 31, 2006 4:37 PM
To: [log in to unmask]
Subject: Re: [HP9000-L] quoting


--- Tracy Pierce <[log in to unmask]> wrote:

> I'm confused.  Why doesn't the shell strip the quotes from date 
> '+args' when it comes from a var?  Is there a magic quote character 
> that WILL get stripped at the correct time?

---

The quoting rules, under the Bourne Shell, are:
  
  Quotes are used to delimit strings containing whitespace on the command
line.

  (Single quotes) ticks suppress immediate evaluation, (double) quotes do
not.

  Backticks (unshift ~) execute their contents and return the result.

  Quotes are not stripped every time anything, like a shell function,
touches the string.

  The quotes do not appear in the strings in argv (the argument vector
supplied to
  a program by the shell).

If you are new to unix get "The UNIX Programming Environment" by Brian W.
Kernighan and Rob Pike without delay; it is concise and complete as a
general guide.

Another good book is "Learning the UNIX Operating System" by Peek, Todino,
Strang (O'Reilly)

Two good references are:

  man sh

  http://en.wikipedia.org/wiki/Bourne_shell

If you are familiar with MPE, in unix
  Everything You Know Is Wrong