spiritLHLS/ecs: the Shell VPS benchmark script that now points you to its Go successor

What spiritLHLS/ecs actually bundles, and who the README is written for

The repository is a Shell script, ecs.sh, that runs a menu of VPS tests. The README describes it as a fusion script: system information, CPU scoring, disk IO, network speed, return routing, streaming unlock checks and IP quality all live behind one entry point. The intended reader is someone who has just bought or rented a VPS and wants a single pass of measurements rather than assembling bench.sh, yabs, lemonbench and a speedtest client by hand.

The README is explicit about provenance. It credits bench.sh, superbench.sh, yabs and lemonbench for the base tests and states that each section has been modified, so results are not identical to the original scripts. That matters if you are comparing numbers against a friend's yabs output: the CPU score comes from sysbench by default, not from geekbench, and the README notes that geekbench 4, 5 or 6 can be selected with the -ctype flag if you need a comparable figure.

The audience is narrower than the feature list suggests. The README says to run it under /root to avoid dependency problems, and says not to use it in production because the package manager is updated automatically. This is a discretionary tool for a fresh or disposable machine, not something to schedule on a live server.

How the menu and the -m parameter mode drive the test flow

The mechanism is a menu tree rather than a flag-per-test CLI. In interactive mode you pick from the menu; in parameter mode you pass -m followed by up to three numbers that walk the same tree, so bash ecs.sh -m 5 1 1 selects the first sub-option under the first sub-option of main menu item 5. The README states that a single value is allowed, and that -m 1, -m 1 0 and -m 1 0 0 all mean the full fusion test.

The remaining flags modify what the selected run does. -en forces English output instead of the default Chinese. -base restricts the run to basic system information. -ctype picks the CPU benchmark (gb4, gb5, gb6, otherwise sysbench). -dtype chooses dd or fio for disk IO, and the README notes dd is fast but less accurate while fio is slower and constrained by disk and memory size. -mdisk extends IO testing to every mounted disk, including the system disk. -stype chooses .cn or .net speedtest data, with .net preferred and .cn as fallback. -bansp skips the network test and -banup skips share-link generation. Routing has its own flags: -i for a target IPv4 address, -r with b, g, s or c for Beijing, Guangzhou, Shanghai or Chengdu, and b6, g6 or s6 for the IPv6 equivalents.

Results are written to test_result.txt in the current directory, and the README suggests running inside screen or tmux so an unstable SSH session does not kill a long test. The full and lite runs upload the result to a pastebin and return a share link. Ctrl+C aborts and, according to the README, removes the leftover dependency files.

Running ecs.sh for the first time

The README gives several mirrors for the same script. The GitHub raw URL is the most straightforward; the GitLab mirror and the short domains bash.spiritlhl.net, ecs.0s.hk and ecs.12345.ing are listed as alternatives. This downloads the script, makes it executable and starts the interactive menu.

curl -L https://github.com/spiritLHLS/ecs/raw/main/ecs.sh -o ecs.sh && chmod +x ecs.sh && bash ecs.sh

Once the menu appears, you choose a test group. If you would rather skip the menu, the README documents the -m form, where -m 1 is the full fusion test and -m 1 0 and -m 1 0 0 are equivalent to it.

bash ecs.sh -m 1

For a lighter run, -base limits the script to basic system information, and -en forces English output. The README also documents the standalone IP quality check, which is a separate script from ecs.sh and queries 15 databases plus DNS blacklists, covering IPv4 and IPv6, ASN and address lookups, and mail port checks.

bash <(wget -qO- bash.spiritlhl.net/ecs-ipcheck)

Expect a long run on weak hardware. The README links an example of a very slow machine that took 47 minutes to finish, which is why the screen or tmux suggestion appears next to the result-file note.

Where the Shell version stops being the right tool

The README's own preface is the biggest limitation. It says the Shell version will receive no new feature development and is maintained only, with the tests rebuilt in a Go version at oneclickvirt/ecs. The stated reasons are telling: testing on systems or architectures the project does not list, dependency errors, wanting minimal changes to the local machine, wanting to test without sudo or root, and wanting a faster or self-compiled run.

If any of those describe you, the Shell script is the wrong entry point. The dependency footprint is real: the README warns that the script updates the package manager automatically and recommends running from /root to avoid dependency problems. On a machine you care about, that is a configuration change you did not ask for.

Platform support is uneven. The compatibility table lists Ubuntu 18+, Debian 8+, CentOS 7+, Fedora 33+, AlmaLinux 8.5+, OracleLinux 8+, RockyLinux 8+, AstraLinux CE and Arch as fully supported, with FreeBSD (after pkg install -y curl bash) and Armbian as half-supported. Architectures are amd64, arm64, i386 and arm. A machine with no public network cannot be tested at all, since the script downloads its components. And the README notes that CDN acceleration exists for both domestic and overseas installs, but loading can still be slow from inside China because of CDN connectivity or bandwidth limits.

spiritLHLS/ecs against yabs and lemonbench

The honest comparison is not feature count, because the README already says the tests are borrowed and modified from yabs, lemonbench, bench.sh and superbench.sh. The difference is packaging and defaults.

yabs is a single-purpose benchmark script that focuses on CPU, disk and network with a fixed output format. spiritLHLS/ecs wraps a menu around a wider set of checks and adds streaming unlock tests, return-route testing to named Chinese cities, and an IP quality module with 15 database lookups. If you want a stable, comparable CPU number across many machines, yabs and its geekbench path are the narrower tool; spiritLHLS/ecs defaults to sysbench and only reaches geekbench through -ctype.

lemonbench is credited for the dd disk test and the CPU test lineage. The README says the fusion script includes both a dd test and a yabs-style fio test, and notes the trade-off directly: dd is fast but can be inaccurate and has no disk-size limit, while fio is more representative but slower and constrained by disk and memory size. That dual approach is the main practical difference from picking one upstream script.

For IP reputation specifically, the standalone ipcheck.sh is the fuller version. The README states that the IP quality check inside the fusion script is simplified and omits the Cloudflare threat score, while the original IP quality command listed in the README is the complete one.

Maintenance, licence and what an upgrade costs you

The repository is not archived and the last push was on 2026-09-04, so it is still receiving changes. But the README's own statement that the Shell version is maintenance-only is the relevant signal: bug fixes and component bumps, not new tests. The most recent changelog entry listed in the README, dated 2026.08.27, upgrades the speedtest-go download to v1.8.3, which is exactly the kind of change to expect.

The upgrade cost is low if you use the curl one-liner, because you always fetch the current ecs.sh. It is higher if you pinned a local copy, since the script downloads its own components at run time and the README does not document a version pinning mechanism or a rollback path for those downloaded pieces.

The licence is MIT, stated in the repository. That is permissive and permits reuse and modification, but the README also notes that most sections are adapted from other projects, so anyone redistributing a modified copy should check the upstream licences of yabs, lemonbench, bench.sh and superbench.sh rather than relying on this repository's MIT file alone. That is a provenance question, not a legal opinion.

Editorial conclusion

Use spiritLHLS/ecs if you want a single interactive menu that covers system info, CPU, disk, network, streaming and IP quality checks on Ubuntu, Debian, CentOS, Fedora, AlmaLinux, OracleLinux, RockyLinux, AstraLinux CE or Arch, and you accept that the README itself says the Shell version gets maintenance only. Do not use it on a production host, since the README states the script updates the package manager automatically, and do not use it where you cannot run as root or sudo, because that is one of the cases the README sends to the Go version. Before adopting it, read the -m parameter table in the README and confirm which menu path matches the test you actually want, because -m 1 and -m 5 1 1 do very different amounts of work.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. spiritLHLS/ecs on GitHub