blocks|key|327231|text|eval语句告诉shell将eval的参数作为命令，并通过命令行运行它们。在下面这样的情况下，它很有用：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|327232|在你的脚本中，如果你将一个命令定义到一个变量中，然后你想要使用这个命令，那么你应该使用eval：|327233|/home/user1+>+a="ls+%7C+more"
/home/user1+>+$a
bash:+command+not+found:+ls+%7C+more
/home/user1+>+#+Above+command+didn't+work+as+ls+tried+to+list+file+with+name+pipe+(%7C)+and+more.+But+these+files+are+not+there
/home/user1+>+eval+$a
file.txt
mailids
remote_cmd.sh
sample.txt
tmp
/home/user1+>|code-block|syntax|javascript|327234|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

The eval statement tells the shell to take eval’s arguments as command and run them through the command-line. It is useful in a situation like below:

In your script if you are defining a command into a variable and later on you want to use that command then you should use eval:

<pre><code>/home/user1 &gt; a="ls | more"
/home/user1 &gt; $a
bash: command not found: ls | more
/home/user1 &gt; # Above command didn't work as ls tried to list file with name pipe (|) and more. But these files are not there
/home/user1 &gt; eval $a
file.txt
mailids
remote_cmd.sh
sample.txt
tmp
/home/user1 &gt;
</code></pre>

blocks|key|327293|text|根据我的经验，eval的一个“典型”用法是运行生成shell命令来设置环境变量的命令。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|327294|也许您有一个使用环境变量集合的系统，并且您有一个脚本或程序来确定应该设置哪些变量以及它们的值。无论何时运行脚本或程序，它都是在派生进程中运行的，因此当它退出时，它直接对环境变量所做的任何操作都会丢失。但是该脚本或程序可以将导出命令发送到stdout。|327295|如果不使用eval，则需要将stdout重定向到临时文件，获取该临时文件的源文件，然后将其删除。使用eval，您只需：|327296|eval+"$(script-or-program)"|code-block|syntax|javascript|327297|请注意，引号很重要。举个(人为的)例子：|327298|#+activate.sh
echo+'I+got+activated!'

#+test.py
print("export+foo=bar/baz/womp")
print(".+activate.sh")

$+eval+$(python+test.py)
bash:+export:+`.':+not+a+valid+identifier
bash:+export:+`activate.sh':+not+a+valid+identifier
$+eval+"$(python+test.py)"
I+got+activated!|327299|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|T|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|V|8|@]|9|@]|A|$I|J]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

In my experience, a "typical" use of eval is for running commands that generate shell commands to set environment variables.

Perhaps you have a system that uses a collection of environment variables, and you have a script or program that determines which ones should be set and their values. Whenever you run a script or program, it runs in a forked process, so anything it does directly to environment variables is lost when it exits. But that script or program can send the export commands to stdout.

Without eval, you would need to redirect stdout to a temp file, source the temp file, and then delete it. With eval, you can just:

<pre><code>eval "$(script-or-program)"
</code></pre>

Note the quotes are important. Take this (contrived) example:

<pre><code># activate.sh
echo 'I got activated!'

# test.py
print("export foo=bar/baz/womp")
print(". activate.sh")

$ eval $(python test.py)
bash: export: `.': not a valid identifier
bash: export: `activate.sh': not a valid identifier
$ eval "$(python test.py)"
I got activated!
</code></pre>

blocks|key|544262|text|在问题中：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|544263|who+%7C+grep+$(tty+%7C+sed+s:/dev/::)|code-block|syntax|javascript|544264|输出错误，声明文件a和tty不存在。我认为这意味着tty不会在grep执行之前被解释，而是bash将tty作为参数传递给grep，grep将其解释为文件名。|544265|还有一种情况是嵌套重定向，应该通过匹配的括号来处理，匹配的括号应该指定子进程，但bash基本上是一个单词分隔符，创建要发送到程序的参数，因此不是先匹配括号，而是解释为所见。|544266|我具体使用了grep，并将文件指定为参数，而不是使用管道。我还简化了基本命令，将命令的输出作为文件传递，这样i/o管道就不会嵌套：|544267|grep+$(tty+%7C+sed+s:/dev/::)+<(who)|544268|效果很好。|544269|who+%7C+grep+$(echo+pts/3)|544270|这并不是真正需要的，但它消除了嵌套管道，而且工作得很好。|544271|总而言之，bash似乎不喜欢嵌套管道。重要的是要理解，bash不是以递归方式编写的新浪潮程序。相反，bash是一个旧的1,2,3程序，它已经添加了一些特性。为了确保向后兼容，最初的解释方式从未修改过。如果重写bash以匹配第一个括号，那么会在多少bash程序中引入多少bug？许多程序员喜欢神秘莫测。|544272|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|10|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

In the question:

<pre><code>who | grep $(tty | sed s:/dev/::)
</code></pre>

outputs errors claiming that files a and tty do not exist. I understood this to mean that tty is not being interpreted before execution of grep, but instead that bash passed tty as a parameter to grep, which interpreted it as a file name.

There is also a situation of nested redirection, which should be handled by matched parentheses which should specify a child process, but bash is primitively a word separator, creating parameters to be sent to a program, therefore parentheses are not matched first, but interpreted as seen.

I got specific with grep, and specified the file as a parameter instead of using a pipe. I also simplified the base command, passing output from a command as a file, so that i/o piping would not be nested:

<pre><code>grep $(tty | sed s:/dev/::) &lt;(who)
</code></pre>

works well.

<pre><code>who | grep $(echo pts/3)
</code></pre>

is not really desired, but eliminates the nested pipe and also works well.

In conclusion, bash does not seem to like nested pipping. It is important to understand that bash is not a new-wave program written in a recursive manner. Instead, bash is an old 1,2,3 program, which has been appended with features. For purposes of assuring backward compatibility, the initial manner of interpretation has never been modified. If bash was rewritten to first match parentheses, how many bugs would be introduced into how many bash programs? Many programmers love to be cryptic.

blocks|key|544321|text|我最近不得不使用eval来强制按照我需要的顺序计算多个大括号扩展。Bash从左到右执行多个大括号扩展，因此|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|544322|xargs+-I_+cat+_/{11..15}/{8..5}.jpg|code-block|syntax|javascript|544323|扩展为|544324|xargs+-I_+cat+_/11/8.jpg+_/11/7.jpg+_/11/6.jpg+_/11/5.jpg+_/12/8.jpg+_/12/7.jpg+_/12/6.jpg+_/12/5.jpg+_/13/8.jpg+_/13/7.jpg+_/13/6.jpg+_/13/5.jpg+_/14/8.jpg+_/14/7.jpg+_/14/6.jpg+_/14/5.jpg+_/15/8.jpg+_/15/7.jpg+_/15/6.jpg+_/15/5.jpg|544325|但我需要首先完成第二个支架扩展，|544326|xargs+-I_+cat+_/11/8.jpg+_/12/8.jpg+_/13/8.jpg+_/14/8.jpg+_/15/8.jpg+_/11/7.jpg+_/12/7.jpg+_/13/7.jpg+_/14/7.jpg+_/15/7.jpg+_/11/6.jpg+_/12/6.jpg+_/13/6.jpg+_/14/6.jpg+_/15/6.jpg+_/11/5.jpg+_/12/5.jpg+_/13/5.jpg+_/14/5.jpg+_/15/5.jpg|544327|我能想到的最好的办法就是|544328|xargs+-I_+cat+$(eval+echo+_/'{11..15}'/{8..5}.jpg)|544329|这之所以有效，是因为在解析eval命令行的过程中，单引号可以保护第一组大括号不被扩展，让eval调用的子subshell对它们进行扩展。|544330|可能有一些巧妙的方案涉及到嵌套的括号扩展，可以让这在一步中发生，但如果有的话，我太老了，太愚蠢了，看不到它。|544331|entityMap^0|8|4|0|0|0|0|0|0|0|0|D|4|18|4|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|15|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|16|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|17|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|18|8|@]|D|@]|E|$]]|$1|Q|3|R|5|H|7|19|8|@]|D|@]|E|$I|J]]|$1|S|3|T|5|6|7|1A|8|@]|D|@]|E|$]]|$1|U|3|V|5|H|7|1B|8|@]|D|@]|E|$I|J]]|$1|W|3|X|5|6|7|1C|8|@$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1H|8|@]|D|@]|E|$]]|$1|10|3|-4|5|6|7|1I|8|@]|D|@]|E|$]]]|11|$]]

I've recently had to use <code>eval</code> to force multiple brace expansions to be evaluated in the order I needed. Bash does multiple brace expansions from left to right, so

<pre><code>xargs -I_ cat _/{11..15}/{8..5}.jpg
</code></pre>

expands to

<pre><code>xargs -I_ cat _/11/8.jpg _/11/7.jpg _/11/6.jpg _/11/5.jpg _/12/8.jpg _/12/7.jpg _/12/6.jpg _/12/5.jpg _/13/8.jpg _/13/7.jpg _/13/6.jpg _/13/5.jpg _/14/8.jpg _/14/7.jpg _/14/6.jpg _/14/5.jpg _/15/8.jpg _/15/7.jpg _/15/6.jpg _/15/5.jpg
</code></pre>

but I needed the second brace expansion done first, yielding

<pre><code>xargs -I_ cat _/11/8.jpg _/12/8.jpg _/13/8.jpg _/14/8.jpg _/15/8.jpg _/11/7.jpg _/12/7.jpg _/13/7.jpg _/14/7.jpg _/15/7.jpg _/11/6.jpg _/12/6.jpg _/13/6.jpg _/14/6.jpg _/15/6.jpg _/11/5.jpg _/12/5.jpg _/13/5.jpg _/14/5.jpg _/15/5.jpg
</code></pre>

The best I could come up with to do that was

<pre><code>xargs -I_ cat $(eval echo _/'{11..15}'/{8..5}.jpg)
</code></pre>

This works because the single quotes protect the first set of braces from expansion during the parsing of the <code>eval</code> command line, leaving them to be expanded by the subshell invoked by <code>eval</code>.

There may be some cunning scheme involving nested brace expansions that allows this to happen in one step, but if there is I'm too old and stupid to see it.

blocks|key|544477|text|我最初故意不学习如何使用eval，因为大多数人会建议像远离瘟疫一样远离它。然而，我最近发现了一个用例，它让我觉得不能更快地识别它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|544478|如果您希望以交互方式运行cron作业以进行测试，则可以使用cat查看文件的内容，然后复制并粘贴cron作业以运行该作业。不幸的是，这涉及到触摸鼠标，这在我的书中是一种罪过。|544479|假设您在/etc/cron.d/repeatme上有一个cron作业，其中包含以下内容：|544480|*/10+*+*+*+*+root+program+arg1+arg2|offset|length|style|CODE|544481|您不能将其作为前面有所有垃圾的脚本来执行，但我们可以使用cut来清除所有垃圾，将其包装在一个子subshell中，并使用eval执行字符串|544482|eval+$(+cut+-d+'+'+-f+6-+/etc/cron.d/repeatme)|544483|cut命令仅打印文件的第6个字段，以空格分隔。然后Eval执行该命令。|544484|我在这里使用了cron作业作为示例，但其概念是格式化来自stdout的文本，然后计算该文本。|544485|在这种情况下，eval的使用并不是不安全的，因为我们事先确切地知道要计算的是什么。|544486|entityMap^0|0|0|0|0|Z|0|0|0|1A|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|10|8|@$H|11|I|12|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|14|8|@$H|15|I|16|J|K]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|17|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|18|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|19|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|W|$]]

I originally intentionally never learned how to use eval, because most people will recommend to stay away from it like the plague. However I recently discovered a use case that made me facepalm for not recognizing it sooner.

If you have cron jobs that you want to run interactively to test, you might view the contents of the file with cat, and copy and paste the cron job to run it. Unfortunately, this involves touching the mouse, which is a sin in my book.

Lets say you have a cron job at /etc/cron.d/repeatme with the contents:

<code>*/10 * * * * root program arg1 arg2</code>

You cant execute this as a script with all the junk in front of it, but we can use cut to get rid of all the junk, wrap it in a subshell, and execute the string with eval

<code>eval $( cut -d ' ' -f 6- /etc/cron.d/repeatme)</code>

The cut command only prints out the 6th field of the file, delimited by spaces. Eval then executes that command.

I used a cron job here as an example, but the concept is to format text from stdout, and then evaluate that text.

The use of eval in this case is not insecure, because we know exactly what we will be evaluating before hand.

After reading the bash man pages and with respect to this <a href="http://www.unix.com/shell-programming-scripting/66063-eval-shell-scripting.html">post</a>.

I am still having trouble understanding what exactly the <code>eval</code> command does and which would be its typical uses. For example if we do:

<pre><code>bash$ set -- one two three # sets $1 $2 $3
bash$ echo $1
one
bash$ n=1
bash$ echo ${$n} ## First attempt to echo $1 using brackets fails
bash: ${$n}: bad substitution
bash$ echo $($n) ## Second attempt to echo $1 using parentheses fails
bash: 1: command not found
bash$ eval echo \${$n} ## Third attempt to echo $1 using 'eval' succeeds
one
</code></pre>

What exactly is happening here and how do the dollar sign and the backslash tie into the problem?

eval command in Bash and its typical uses

在阅读bash手册页之后，请参考此。我仍然无法理解eval命令到底做了什么以及它的典型用法是什么。例如，如果我们这样做：bash$ set -- one two three  # sets $1 $2 $3bash$ echo $1onebash$ n=1bash$ echo ${$n}       ## First ...

问Bash中的eval命令及其典型用法
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Bash中的eval命令及其典型用法EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Bash中的eval命令及其典型用法
EN