$ b=$( eval echo \$$_var ) # this method as expected$ b=`eval echo \$$_var` # this method not as expected ,should it be same result as previous method?

On OpenBSD-CURRENT, which exhibits the same behavior:

Quote:

Originally Posted by man ksh

For $(command) substitutions, normal quoting rules are used when command is parsed; however, for the `command` form, a `\' followed by any of `$', ``', or `\' is stripped (a `\' followed by any other character is unchanged).

Simply put, for `command` form substitution, \$ is treated in a special manner and what you get from \$$ is $$, or the pid of the shell you're working in right now.

The first form b=$( eval echo \$$_var ) which i understood is parsed like this:
pass1: eval echo $aa ## \$ is treated as dollar sign $, $_var is aa
pass2: eval it , and assign result (echo $aa 's output) to variable b
is it right to think of it ?

The manpage states "a `\' followed by any of `$', ``', or `\' is stripped", so the first strip is for \\, leaving \$...but since \$ is in the list, too, the second \ is stripped as well, leaving $$_var, which is $aa, which evals to AAAA.

For all practical intents and purposes, $(string) is just a synonym for `string`. $() was added as a more explicit way of doing `` around the 80s, so $() is not as portable as ``.

I have not seen any shell that does not support $(), that is not old as petrified dog poo. I personally use `` in scripts because it gains a small bit of portability at no sacrifice in readability over $(). Yes, I'm to lazy to change from ``to $() in case I get stuck in an antique sh.

CS, you'll just have to excuse those of us who test their scripts against shells who have yet to be certified as passing the standard, and prefer common-dialect portability over requiring the latest and greatest standards without real need of those features. Ditto for any C99 versus C89 debates. I'm a practical man not a theologian.

As to the OP, all I see is issues relating to $(), ``, and escaping, and wouldn't mind if the OP tried a more direct way of phrasing it.

The $() form of command substitution solves a problem of inconsistent behaviour
when using backquotes. For example:
Command Output
echo '\$x' \$x
echo `echo '\$x'` $x
echo $(echo '\$x') \$x
Additionally, the backquoted syntax has historical restrictions on the contents
of the embedded command. While the new $() form can process any kind of valid
embedded script, the backquoted form cannot handle some valid scripts that
include backquotes. For example, these otherwise valid embedded scripts do
not work in the left column, but do work on the right:
echo ` echo $(
cat <<\eof cat <<\eof
a here-doc with ` a here-doc with )
eof eof
` )
echo ` echo $(
echo abc # a comment with ` echo abc # a comment with )
` )
echo ` echo $(
echo '`' echo ')'
` )
Because of these inconsistent behaviours, the backquoted variety of command
substitution is not recommended for new applications that nest command substitutions
or attempt to embed complex scripts.

The manpage states "a `\' followed by any of `$', ``', or `\' is stripped", so the first strip is for \\, leaving \$...but since \$ is in the list, too, the second \ is stripped as well, leaving $$_var, which is $aa, which evals to AAAA.

ex1:
The interpreter read in command line, and first two backslash is treated as \ literally, and \$ is treated as $ literally, $_var is replaced by $_var's value, "aa"
after first interpreted, the interpreter also find it there's \$ because of result of first read, and \$ is treated as $ literally ,
is it right ot understand it ?

ex2:
the interpreter read in , and first two backslash is treated \ literally , and following two backslash is also, and following two dollar sign is replaced by current pid value.
after first read(the first four backslash is interpreted \\), then this \\ is also interpreted \.

ex3:
the interpreter read in command, the first two backslash is \, the second pair is also \, the third pair is also \, and the following two dollar sign is shell pid
after first read, the text is look like this: \\\1018_var, however, as you can see, the result is not expand $$ to pid, i think it interpret byte by byte, instead of read a line whole, like this: the first three pair backslash is interpreted three literal \, then \\\$$_var(assume it read byte by byte ) is interpreted as first two backslash is \ , third backslash and fourth dollar sign is literal $, and result of this is \$aa.

question 1: how the interpreter interpret command line , line by line or byte by byte, or otherwise?
question 2: why the \$ sequence not be interpreted, it's also in the list `$', ``', or `\'?