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