我正在编写一个R程序包以支持可重复的研究。此时，工作流大部分由bash脚本合并在一起，我可以通过发送单个命令(如./runscript.sh)来运行分析。我将bash用于以下用途：

在我看来，从R函数或R脚本执行整个工作流程将更加高效(更加简洁)。我偏爱R，因为我比较熟悉它，并且大多数都在emacs ESS中工作。

问题

笔记

遵循Al3xa的回答，我意识到必须注意使用eg的速度损失。 R-bash版本的tar和gsub在1000-2000个文件上可能会比工作流中当前的速率限制步骤小：用JAGS(?10-20min)和FORTRAN(> 4hrs)进行计算

我非常喜欢使用R作为bash脚本的"集成"环境。我正在将所有bash和ruby脚本移至Rscript，因为我需要对其进行更改。

我想到的只有几个原因不能将所有内容都转移到R中。我主要是指使用Rscript完成此操作

1)速度，根据我的测试，它对我遇到的任何情况均会产生中等程度的影响，相对于您提到的时间而言，这是微不足道的。

2)可移植性，因为跨系统到Rscript等的路径可能不同。我在OS X上编写东西并将它们移到Linux服务器上没有问题，但是在Windows上可能会损坏。

我的书的优点是：

1)我写起来容易多了。我不必在轻微的特质与条件语句和for循环之间来回切换。

2)更宽容。我无法描述我花了多少时间尝试使bash脚本正常工作，因为我不小心有一个本来不应该有的空间。 R在这方面要好得多(是的，当然，我们都应该完全遵循R中的约定，但我宁愿不要让我停顿好几个小时)。

3)我做得更好。对于tar文件并不重要，但是例如，我发现我在R与awk/sed之间的文本处理效果更好。

Re：有用的软件包-就我所知，这还不存在，但是我很喜欢基于R的make版本。make的语法是目前最不灵活的语法之一(制表符还是空格？ ？)-我很想写一个基于R的替代方案。有一天，我会...

好吧，有tar，gsub等功能。无论如何，我想您愿意创建一个跨平台的解决方案。为了提高速度，您应该首选bash，并且仅将R用于特定于R的功能。我发现将所有基于系统的命令包装在system和/或file.*中不是很有用...会慢很多...如果您使用的是Linux，我建议在littler >界面。