Question

直接在提示

上运行控制台应用程序有什么区别

# myapp --arg=val1 --arg2=val2

与通过shell脚本运行它相比

./ myscript.sh

#!/bin/sh
myapp --arg=val1 --arg2=val2

通过scipt产生的额外开销

很好找出shell将通过fork和exec执行该过程。

我正在考虑的任务。假设xinetd请求是处理请求：

调用bash脚本来处理请求我可以先进行一些预处理，比如首先解析varibales，然后调用C app。 C代码会更少，并且首先在bash脚本上更改变量值会更快。此外，我可以将任务分解为多个较小的c应用程序

如果我直接调用c来处理请求肯定会更快，更少资源但更多编码。

因为bash选项更容易，但当然有bash中间过程。

我在想有可能让我们说成千上万的请求，所以我想知道bash流程对中介胶的影响是什么

Answer 1

在实践中，没有太大的区别（对于你正在展示的剧本）。

当然，有fork(2) - 然后execve(2)的开销（几毫秒） - 并且在某些罕见情况下它们都会失败，并且有你的（新的） shell解释该脚本。

更重要的是，您在shell脚本中执行的任何其他操作（尤其是cd，export，ulimit，exit ....以及其他shell内置函数）都会影响只有那个shell进程。

另请阅读source内置（影响shell执行此操作）和bash函数。

Answer 2

开销来自于在执行命令之前读取脚本文件。

作为一个简单的测试，您可以执行以下操作：

strace myapp --arg=val1 --arg2=val2 2> strace_noscript.log
strace ./myscript.sh 2> strace_script.log

看看系统调用的差异。您还可以运行time以了解运行应用程序的实际时间差异，例如：

kom@thinky:~/c_practice/tmp$ time cat tmp.c > /dev/null

real    0m0.004s
user    0m0.004s
sys     0m0.000s
kom@thinky:~/c_practice/tmp$ time ./myscript.sh

real    0m0.010s
user    0m0.007s
sys     0m0.001s

myscript.sh包含的位置：

#!/bin/sh
cat tmp.c > /dev/null

在提示符上直接运行控制台应用程序有什么区别

2 个答案: