最佳答案
有可能，问题是这样做的目的是什么。它们可能是以下的子集:
- 速度 解释的脚本可能更慢
- 可维护性也许你曾经对C有更多的经验
- 灵 active 脚本显示了通过合理努力可以实现的目标的局限性
- 集成也许您已经有了愿意与脚本紧密集成的代码库
- 便携性
还有其他原因，例如可扩展性、效率，可能还有更多。
基于“转换”的目标，有很多方法可以实现 C 语言的等价，改变“本地”代码的数量。例如，我们可以考虑两个极端。
在一个极端情况下，我们有一个编译后的 C 代码，它主要像 bash 一样执行，因此原始脚本的每一行都会产生等同于 fork/exec/wait 系统调用的代码，其中的更改将主要执行等同于通配符扩展、从环境变量中检索值、处理 fork 进程的同步，以及使用适当的系统调用处理管道。
请注意，这个“简单”的转换已经是大量的工作，这可能比只编写另一个 shell 解释器还要糟糕。此外，它不符合上述许多目标，因为在可移植性方面，它仍然可能依赖于操作系统的系统调用，在性能方面，唯一的好处是最初解析命令行。
在另一个极端，我们以更 C 的方式进行了完全重写。这将用 C 条件语句、ls、cd 和 rm 命令替换所有条件语句到它们各自的系统调用中，并可能用适当的库替换字符串处理。
这在实现某些目标方面可能会更好，但成本可能会比其他方式更高，而且会消除大量代码重用，因为您必须实现与简单命令等效的功能。
至于自动执行此操作的工具，我不知道有没有，如果有的话，它们可能没有得到广泛使用，因为将 Bash 转换为 C 或将 C 转换为 Bash 可能不是一个好主意。如果出现这种需求，它可能是设计问题的征兆，因此重新设计可能是更好的解决方案。编程语言和脚本语言是用于不同工作的不同工具，尽管它们可以完成的工作之间存在交叉领域。一般来说，
Don't script in C, and don't code in Bash
最好知道如何以及何时使用您拥有的工具，然后找到一个通用的通用工具(也就是没有银弹之类的东西)。
希望对您有所帮助 =)
关于将 Bash 脚本转换为 C。这可能吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13035005/