v0.10.10

👉 View Full Changelog on X-CMD Website
👉 Version compare: v0.10.9...v0.10.10

✅ Upgrade Guide

x upgrade 

📃 Changelog

fskv

• New fskv module — a simple filesystem-directory-shared key-value store.

Passing state between scripts used to mean environment variables or standing up a service, both overkill. This time we just lean on the filesystem: every key is a file with the same name, and the root directory defaults to .x-cmd/fskv under the current directory. Any process or user with read/write access to that directory shares the same state.

A few things I find handy:

• / in a key is just directory nesting; abc//cde collapses to abc/cde automatically; if a file collides with a directory name, the module quietly migrates it to the directory's default-value file — nothing for you to babysit
• x fskv root <path> switches the storage root — point it at an NFS / shared mount and multiple machines share the same state
• x fskv :<root> <op> or -r <path> runs a single operation against another root without touching the session state

Example:

# Write and read a key-value pair
x fskv put greeting hello
x fskv get greeting

# Switch to a shared root so multiple processes/users share state
x fskv root ~/shared/fskv

# One-off operation against /tmp/fskv-demo, session state untouched
x fskv -r /tmp/fskv-demo put msg hello

# List all keys under the user namespace
x fskv ls user

# Check if a key exists / remove a key
x fskv has user/name
x fskv rm user/name

str

• Fixed a bug in the str module — thanks to @shubo83 for the report in #487.

Following the docs and running echo "a,b,c" | x str split "," failed with a missing-array-name error — the documented example didn't match actual usage, which was a real gotcha. split now behaves as documented.

Also fixed a sneaky latent bug along the way (#489): in startswith / endswith, the pattern slot was unquoted, so prefixes/suffixes containing * or ? were glob-expanded against the current directory first, and ones with whitespace got word-split — the result depended on which directory you happened to be in. E.g. x str startswith "hello" "*" should return non-match, but the old code could report otherwise. Patterns are now treated as literals, so behavior matches intuition.

Example:

# split works as documented out of the box
echo "a,b,c" | x str split ","

# glob chars treated literally, no CWD-dependent surprises
x str startswith "hello" "*"          # returns non-zero
x str endswith "hello world" " world"  # matches

eget

• Fixed x eget selecting the wrong asset from some GitHub Releases.

The previous matching algorithm scored assets primarily by how well their names aligned with the current platform. When a release ships a mix of library archives, source tarballs, and binaries built for different architectures, it could end up picking the library, the source tarball, or a binary built for a different platform.

The bug first surfaced while testing epicgames/lore (#471). A related case then showed up while testing h5i-dev/h5i (#483): when no Release binary is available for the current platform — for example, on an Intel macOS (x86_64) machine where only arm64 builds exist — the old algorithm would still happily download the arm64 binary instead of correctly reporting that no build is available for the current platform.

We have now improved the matching algorithm. The new algorithm evaluates each asset against all platforms at once — checking not only whether it matches the current platform, but also whether it matches other platforms better.

An asset is only treated as a valid candidate for the current platform when its score for the current platform is strictly higher than its score for every other platform. Assets that score identically across all platforms (for example, source tarballs or generic archives that carry no clear platform info) are now skipped outright.

Example:

# Now reliably picks the asset that actually matches the current OS/arch
x eget use epicgames/lore

# When no asset is available for the platform, it now fails clearly
# instead of pulling an incompatible binary
x eget use h5i-dev/h5i

Thanks to @Koukyosyumei for reporting the related issue upstream via h5i-dev/h5i#601.