runsh

您的 bash 脚本的 CLI 前端。

解析脚本并格式化打印找到的函数。类似于 run_lib 但更 Rust 风格。

假设您有一个名为 script.sh 的脚本，其外观如下

#!/usr/bin/env bash

# This function is very clever and awesome and does a lot of neat stuff.
# And here is some more detailed description about this funciton. Isn't it great?
some_function() {
    echo "hello world from a script"
    echo "foobar"
    sleep 1
    echo "ending function now"
}

# More functions
yet_more_functions() {
    echo "hello from another function"
}

您可以将以下内容追加到文件中

runsh $(basename "$0") "$@" || "$@"

然后，当您执行 ./script.sh 时，您将看到以下内容：

然后您可以使用以下方式执行函数

./script.sh some_function

安装

从 crate

cargo install runsh

更新

cargo uninstall runsh
cargo install runsh

使用

将以下内容添加到脚本的末尾

runsh $(basename "$0") "$@" || "$@"

然后执行您的脚本并遵循使用说明。

在一些项目中，我发现我有很多脚本。例如 ops，test，aws，twitter。

隐藏函数

使用下划线 "_" 前缀来使 runsh 忽略函数并不要格式化打印它。这对于辅助函数很有用。"私有"函数。例如

_hidden_function() {
    echo "blah blah"
}

文件头

runsh 将提取文件头中的注释（如果有），并显示在所有可运行函数旁边。它依赖于这些注释遵循 Google Shell Style Guide 的形式，即如下所示

#!/usr/bin/env bash
#
# Some comments.
# And some more.

挑战

从 Rust 中执行 bash 函数

1. Command 直接执行程序而不创建 shell，因此您不能先 source 脚本然后调用它。
2. 可以使用 shellfn 来 source 和执行，但您将失去在脚本运行时查看脚本正在做什么的能力。这必须支持长时间运行的脚本，所以这不是一个好的选择。

让脚本自己调用自己会更容易，这正是最后一行所做的事情。这意味着runsh实际上并没有运行任何东西，它只是bash脚本的格式化打印器。我更希望它运行函数，因为我想要保持bash的简单性，所以如果任何阅读这篇文章的人有更好的想法，请随时联系。

为什么不运行run_lib呢？

我已经在bash中写好了这个脚本，并命名为run_lib。这里有几个原因说明它可能更好。以下是一些考虑因素。

1. Rust的可执行文件通过cargo更容易分发。人们更容易更新他们的版本。
2. 与脚本的集成几乎是相同的。
3. 在Rust中处理要容易得多，例如找到和显示多行注释。
4. Rust现在很热门。

集成是如何工作的

集成看起来是这样的：runsh $(basename "$0") "$@" || "$@"

这有两部分

1. runsh $(basename "$0") "$0"：这执行了runsh，传递两个参数
   1. 正在运行的脚本名称（$(basename "$0")）。例如，在./script some_function中，它将是script。
   2. 用户发布的shell命令的参数（"$@"）。这将是指函数名称和参数，例如在./script.sh some_function some_args中，它将是some_function some_args。这是为了验证。
2. || "$@"是当runsh返回非零退出代码时的后备。这是预期的。这就是函数最终被执行的方式。当发生这种情况时，"$@"将执行，这是快速bash方式来运行实际的函数。