问题描述
想要寻找一个好的Web控制台或工具，以帮助他们审查Shell脚本。通常在维护系统时，他们会运行一些经过管理的脚本，或者运行一次性脚本。然而，这些脚本必须经过审核，以确保它们是安全的、符合规范的，并且不会引发问题。用户希望能够让成员提交脚本，而不需要过多关注格式或文件夹结构。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
为了确保脚本的正确性，你可以结合使用测试和代码检查工具，并编写一些实用脚本来组织和限制脚本的提交。
以下是一些工具和框架，可以帮助你实现这个目标：
1. Bash Automated Testing System (BATS)：这是一个广泛使用的框架，用于编写测试脚本。你可以编写测试用例来检查脚本是否满足安全、符合规范和不会引发问题的要求。BATS 提供了生成和运行测试的框架。
2. Shellcheck：这是一个代码检查工具，可以检查新代码是否符合你的社区所采用的一套常规规则。你可以使用 Shellcheck 来确保新提交的代码符合规范。
将这些工具结合起来，你可以使用 GitHub Actions 或 Git 的 pre-commit hook 等方式，对新的贡献进行快速检查，帮助维护者。
这些工具可以提供定量的正确性度量。为了提供一些定性或更主观的接受度度量，这将大大取决于操作环境和哪些工具适合你的环境。
然而，有些工具确实可以通过设计来解决这个需求。根据你的操作环境和自然适应的工具，以下是两个选项的比较：
GitHub、GitLab 请求
如果代码将被提交到 GitHub 或 GitLab 仓库，你可以使用 GitHub 或 GitLab 作为“审查控制台”。贡献者可以 fork 仓库，通过 PR 的形式提交新的贡献，然后上述的检查将被执行。Actions 可以根据一些内部约定来组织代码，比如使用标签，将脚本文件放在带有 admin 标签的 admin 目录中。
Gerrit
另一个用于管理代码贡献的工具是 Gerrit。Gerrit 与 git 工作流程紧密结合，可能并不适用于你的情况，但我提到它是因为它是最早的软件同行评审系统之一。Gerrit 的工作流程如下：
1. 创建变更
2. 创建审查
3. 审查变更
4. 修改变更
5. 验证变更
6. 提交变更
7. 下一步
在这个工作流程中，实际的工作由审查者或贡献者完成，Gerrit 用于组织他们的协作。
然而，我怀疑这两个选项都不完全符合你的要求。一个通用的工具，可以接收任意贡献的提交，是一个很大的要求，可能是一个幻想。更可行的方法是在现有的代码协作平台中采用共享约定，而不是使用专门的服务来管理贡献的接收。
最后，你提到：
通常在维护系统时…
如果你指的是“维护系统的配置状态”，那么你可以考虑使用 Zuul。Zuul 是一个驱动持续集成、交付和部署系统的程序，重点是项目门控和相关项目。虽然它比较复杂，但它可以实际执行和评估所提议的脚本的结果。这提供了更有意义的反馈，但在设置和维护方面也更加繁琐。