LinuxWave 3.0.1

Release Note 更新日志

本次为兼容更新：3.0 装过的用户可以直接 wave selfupdate 升到 3.0.1，不需要重装。

新功能：--dir-option=<路径> 可以省略菜单编号

以前要指定自定义安装目录，必须写成 --dir-option=<编号>=<路径>，其中编号是「other」那一项在目录菜单里的序号（LinuxWave 是 5）：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)" -- --silent --dir-option=5=/opt/mylw

3.0.1 起，编号可以直接省略，把路径写在等号后面即可：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)" -- --silent --dir-option=/opt/mylw

对全部三种写法等价：

写法	含义
--dir-option=N	静默选目录菜单第 N 项（1–5）
--dir-option=DIR	自定义目录 DIR（= --dir-option=5=DIR）
--dir-option=N=DIR	选第 N 项；N 为 5（自定义项）时用 DIR 作为安装目录

这是纯语法糖，旧的 --dir-option=N=DIR 完全保留，脚本与 CI 都能继续用。

细节

• 只有当 = 左边是纯数字时才按 N=DIR 拆分；所以 --dir-option=/opt/a=b 这种路径本身带 = 的写法不会被误拆，整条按路径处理。
• 路径仍然支持 ~（会展开成 $HOME）与空格（用引号括起来即可）。
• 编号越界、给非自定义项传路径等错误情况，报错信息与之前一致。

这个改动装得上吗

--dir-option 属于安装引导脚本（install.sh / selfupdate.sh，直接从仓库拉取运行），不在文件清单里、不会被安装到本地。所以：

• 已经装好 3.0 的用户：wave selfupdate 可以直接升到 3.0.1（同大版本，守卫放行）。本次功能对已装用户无影响，想用新写法时重跑一次上面的 install.sh 命令即可。
• 全新安装：直接用新写法即可。

升级方式

wave selfupdate

或重新安装（不是必须）：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

其他改动

• lib/install.sh：--dir-option 解析与帮助文本更新（见上）。
• scripts/sandbox_test.sh：新增两个用例覆盖简写与含空格路径。
• README.md / README.zh-Hans.md：--dir-option 文档更新为「编号可省略」。
• 官网 linuxwave.org 版本信息同步到 3.0.1 / 2026-10-09（英文区与中文区都改了）。
• LinuxWaveOrg/pkgtest 的 README 标题从旧的 LinuxWavePkgTest 改为 LinuxWave pkgtest（仅文档，仓库地址不变）。

---

Release Notes

Compatible update: users already on 3.0 can upgrade with wave selfupdate — no reinstall needed.

New: --dir-option=<path> no longer needs the menu number

Previously, a custom install directory required --dir-option=<number>=<path>, where the number was the "other" entry in the directory menu (5 on LinuxWave):

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)" -- --silent --dir-option=5=/opt/mylw

From 3.0.1 the number may be omitted and the path written directly after the =:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)" -- --silent --dir-option=/opt/mylw

The three forms are equivalent:

Form	Meaning
--dir-option=N	Silently pick entry N of the directory menu (1–5)
--dir-option=DIR	Custom directory DIR (= --dir-option=5=DIR)
--dir-option=N=DIR	Pick entry N; use DIR when N is 5 (the custom entry)

This is pure sugar — the older --dir-option=N=DIR form is kept as is, so existing scripts and CI keep working.

Details

• An = is only treated as the N=DIR separator when the left side is all digits, so a path that itself contains =, e.g. --dir-option=/opt/a=b, is not split and is taken as the path.
• Paths still support ~ (expanded to $HOME) and spaces (quote them).
• Error messages for out-of-range numbers or a path passed with a non-custom entry are unchanged.

Does this change reach installed users?

--dir-option lives in the bootstrap scripts (install.sh / selfupdate.sh), which are fetched from the repository and run directly — they are not in the file list and are never installed locally. Therefore:

• Existing 3.0 users: wave selfupdate upgrades you to 3.0.1 (same major version, guard allows it). This feature does not affect an existing install; re-run the install.sh command above if you want to use the new form.
• Fresh installs: use the new form right away.

How to upgrade

wave selfupdate

Or reinstall (not required):

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

Other changes

• lib/install.sh: --dir-option parsing and help text updated (see above).
• scripts/sandbox_test.sh: two new cases covering the shorthand and a path with a space.
• README.md / README.zh-Hans.md: --dir-option docs updated to "the number may be omitted".
• Website linuxwave.org version info synced to 3.0.1 / 2026-10-09 (both the English and the Chinese block).
• LinuxWaveOrg/pkgtest README heading renamed from the old LinuxWavePkgTest to LinuxWave pkgtest (docs only; the repository URL is unchanged).

LinuxWave 3.0

Release Note 更新日志

本次为不兼容更新：包与版本数据从「代码仓库的分支」迁出到独立仓库，依赖数据目录由 surfboard/ 改名为 deps/；并且 LinuxWave 3.0 不能通过 wave selfupdate 升级，必须用 install.sh 重新安装。

本次是不兼容更新

3.0 之前，包元数据与版本数据都放在代码仓库 LinuxWaveOrg/LinuxWave 的分支里（infosource / configdata），依赖数据则放在该分支的 surfboard/ 目录下。

3.0 起：

• 数据迁到各自的独立仓库，路径与引用全部改变；
• 依赖数据的目录名 surfboard/ → deps/；
• 官网站点从代码仓库的 gh-pages 分支迁到独立仓库；
• 测试包 test_bin_* 从 MacWave 的测试仓库改用 LinuxWave 自己的。

旧版本（≤ 2.6.5）读的仍是旧地址。 旧分支目前还在，但已冻结、不再更新——老版本继续能用，只是拿不到 3.0 之后的内容。要拿到 3.0，请按下文用 install.sh 重装。

不能通过 selfupdate 升级到 3.0

3.0 的 selfupdate.sh 增加了跨大版本守卫：当目标版本与当前已装版本的大版本号不同时，直接拒绝并提示改用 install.sh。

当前版本	目标	行为
2.x（任意）	3.0	拒绝，提示改用 install.sh ⛔
3.0	3.0	已是最新，短路退出
3.0	3.x	正常自更新 ✅

这是一条通用规则，不是 3.0 专属：每个大版本的第一个版本、以及任何跨大版本升级，都不能走 selfupdate（这类升级通常同时改动仓库与目录结构）。守卫写在 selfupdate.sh 里、随目标分支下发，因此以后每个大版本都自动生效，无需逐版写死在数据里。

仓库 / 分支迁移前后地址

内容	迁移前	迁移后
代码仓库	LinuxWaveOrg/LinuxWave	不变（仍是 LinuxWaveOrg/LinuxWave；main 与 3.0 自动同步）
包元数据（描述 / 下载地址 / 校验值）	LinuxWave 仓库的 infosource 分支 raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/infosource/pkg/…	LinuxWaveOrg/infosource 仓库的 main 分支 raw.githubusercontent.com/LinuxWaveOrg/infosource/main/pkg/…
依赖数据	同一分支的 surfboard/ 目录 …/LinuxWaveOrg/LinuxWave/infosource/surfboard/depsinfo_{arch}/…	新仓库、目录改名 deps/ …/LinuxWaveOrg/infosource/main/deps/depsinfo_{arch}/…
包列表 API	api.github.com/repos/LinuxWaveOrg/LinuxWave/contents/pkg/pkginfo_{arch}?ref=infosource	api.github.com/repos/LinuxWaveOrg/infosource/contents/pkg/pkginfo_{arch}?ref=main
版本 / 迁移数据	LinuxWave 仓库的 configdata 分支 raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/configdata/…	LinuxWaveOrg/configdata 仓库的 main 分支 raw.githubusercontent.com/LinuxWaveOrg/configdata/main/…
官网站点	LinuxWave 仓库的 gh-pages 分支	LinuxWaveOrg/Pages 仓库的 main 分支（自定义域仍是 linuxwave.org）
测试包（格式测试用）	MacWaveOrg/MacWavePkgTest（MacWave 那边）	LinuxWaveOrg/pkgtest（自有副本，同一份 1.0 release 与附件）
迁移前的历史归档	—	新增 LinuxWaveOrg/legacy-LinuxWave：迁移前的完整镜像，已归档只读，保留全部提交历史

为什么要发一版

这次迁移改动的是数据来源，而不是功能，但必须发一版才能把「怎么升级」送达用户：

因为 3.0 无法用 wave selfupdate 到达（见上），release 说明本身就是升级通知——存量用户需要知道要改用 install.sh 重装，而不是等一个永远不会到来的自更新。

这次发布也顺带修复了「判断要不要重新登录」时查错地方的老问题（见下）。

升级方式

重新安装：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

安装脚本现在从 configdata 读取版本号与代码来源分支（不再写死在脚本里），因此它会自动安装 configdata 当前公布的版本（本次为 3.0）。

其他改动

• lib/install.sh：LINUXWAVE_VERSION 与代码来源分支改为从 configdata 的 versiondata/latest_version 读取（version / branch 一起读，保证「下载的代码」与「写进 VERSION.json 的版本号」对应同一版本）
• lib/selfupdate.sh：新增跨大版本守卫（见上）
• 新增工作流 Sync main with the release branch：main 与「发布分支」自动互相检测并快进同步；发布分支由 configdata 的 branch 字段决定（现为 3.0），分叉时直接报错交人工处理，历史分支（2.0.0-dev / 2.5 等）不会被触碰
• configdata：versiondata/latest_version 更新为 3.0（构建号 282D1414，branch: "3.0"），并新增 updatedata/3.0（N，沿用 2.6.x 的惯例）
• format-test.yml：数据改从 LinuxWaveOrg/infosource 检出，触发分支改为 LinuxWave 自己的分支名并加入 3.0
• 官网与 README 显示的版本号同步为 3.0

验证方式

• CI 全绿：3.0 分支上的 Format Test 通过，其中「跨大版本 selfupdate 必须被拒绝、且 VERSION.json 不被改动」的用例为新增项
• 跨大版本守卫实测：已装 2.x、目标 3.0 时被拒绝并提示改用 install.sh；同大版本（3.0 → 3.x）不被误拦
• 数据地址实测：LinuxWaveOrg/infosource（pkg/ 与 deps/）与 LinuxWaveOrg/configdata 的 raw 地址均返回 200，包列表 API 可用
• 测试包实测：LinuxWaveOrg/pkgtest 的 1.0 release 附件与数据里声明的 sha256 逐字节一致
• 站点实测：linuxwave.org 返回 200，页面显示 Latest Version : 3.0
• 双向同步实测：main 与 3.0 自动保持同步（推送任一侧即快进另一侧）

---

Release Notes

This is a breaking update: package and version data moved out of the code repository's branches into dedicated repositories, the dependency data folder was renamed surfboard/ → deps/, and LinuxWave 3.0 cannot be reached with wave selfupdate — it must be installed with install.sh.

This is a breaking update

Before 3.0, the package metadata and the version data both lived in branches of the code
repository LinuxWaveOrg/LinuxWave (infosource / configdata), with the dependency data
under a surfboard/ directory on that branch.

As of 3.0:

• the data moved into dedicated repositories, changing every path and reference;
• the dependency data folder was renamed surfboard/ → deps/;
• the website moved from the code repository's gh-pages branch into its own repository;
• the test_bin_* test packages moved from MacWave's test repository to LinuxWave's own.

Older versions (<= 2.6.5) still read the old addresses. Those branches are still
present but frozen — old installs keep working, they simply stop receiving anything
published after 3.0. To get 3.0, reinstall with install.sh as described below.

You cannot update to 3.0 with selfupdate

selfupdate.sh now carries a cross-major guard: when the target version's major
number differs from the installed one, it refuses outright and points at install.sh.

Installed	Target	Behaviour
2.x (any)	3.0	refused, points at install.sh ⛔
3.0	3.0	already up to date, exits early
3.0	3.x	self-update runs ✅

This is a general rule, not a 3.0 special case: the first release of every major
version — and any cross-major upgrade — cannot go through selfupdate (such upgrades
usually change both repositories and directory layout). The guard lives in
selfupdate.sh and is delivered by the target branch, so every future major gets it
automatically instead of it being hardcoded per release.

Repository / branch addresses before and after

What	Before	After
Code repository	LinuxWaveOrg/LinuxWave	unchanged (still LinuxWaveOrg/LinuxWave; main and 3.0 kept in sync)
Package metadata (description / download url / checksum)	infosource branch of LinuxWave raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/infosource/pkg/…	main branch of LinuxWaveOrg/infosource raw.githubusercontent.com/LinuxWaveOrg/infosource/main/pkg/…
Dependency data	surfboard/ on that same branch …/LinuxWaveOrg/LinuxWave/infosource/surfboard/depsinfo_{arch}/…	new repository, folder renamed deps/ …/LinuxWaveOrg/infosource/main/deps/depsinfo_{arch}/…
Package listing API	api.github.com/repos/LinuxWaveOrg/LinuxWave/contents/pkg/pkginfo_{arch}?ref=infosource	api.github.com/repos/LinuxWaveOrg/infosource/contents/pkg/pkginfo_{arch}?ref=main
Version / migration data	configdata branch of LinuxWave raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/configdata/…	main branch of LinuxWaveOrg/configdata raw.githubusercontent.com/LinuxWaveOrg/configdata/main/…
Website	gh-pages branch of LinuxWave	main branch of LinuxWaveOrg/Pages (custom domain is still linuxwave.org)
Test packages (format tests)	MacWaveOrg/MacWavePkgTest (MacWave's)	LinuxWaveOrg/pkgtest (its own copy, same 1.0 release and assets)
Pre-migration archive	—	new LinuxWaveOrg/legacy-LinuxWave: a full mirror of the repository as it was, archived read-only, all commit history kept

Why cut a release at all

This migration changed where the data comes from, not what it does, yet a release is
the only way to deliver the "how to upgrade" message:

because 3.0 cannot be reached with wave selfupdate (see above), these release notes
are themselves the upgrade notice — existing users need to know they must reinstall
with install.sh rather than wait for a self-update that will never arrive.

How to upgrade

Reinstall:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

The installer now reads the version and the code source branch from configdata
instead of hardcoding them, so it installs whatever version configdata currently
publishes (3.0 as of this release).

Other changes

• lib/install.sh: LINUXWAVE_VERSION and the code source branch are now read from
  configdata's versiondata/latest_version (version / branch are read together so
  the code downloaded and the version recorded in VERSION.json always match)
• lib/selfupdate.sh: the cross-major guard described above
• new workflow Sync main with the release branch: main and the release branch
  detect each other and fast-forward automatically; the release branch comes from
  configdata's branch field (3.0 today), divergence fails the run for a human, and
  historical branches (2.0.0-dev / 2.5 …) are never touched
• configdata: versiondata/latest_version bumped to 3.0 (build 282D1414,
  branch: "3.0") plus updatedata/3.0 (N, following the 2.6.x convention)
• format-test.yml: checks the data out from LinuxWaveOrg/infosource, uses LinuxWave's
  own branch names and adds 3.0
• the version shown on the site and in the READMEs is now 3.0

How it was verified

• CI green: Format Test passes on the 3.0 branch, including the new case that a
  cross-major selfupdate is refused and leaves VERSION.json untouched
• Cross-major guard, exercised for real: an installed 2.x asked to reach 3.0 is
  refused and told to use install.sh; a same-major upgrade (3.0 → 3.x) is not blocked
• Data addresses: the raw URLs under LinuxWaveOrg/infosource (pkg/ and deps/)
  and LinuxWaveOrg/configdata all return 200, and the package listing API works
• Test packages: the 1.0 release assets under LinuxWaveOrg/pkgtest match the
  sha256 values declared in the data byte for byte
• Site: linuxwave.org returns 200 and shows Latest Version : 3.0
• Two-way sync: main and 3.0 keep each other up to date (pushing either side
  fast-forwards the other)

Index Update-2026100901

Index Update 索引更新

Add packages: yq 4.54.1

新增软件包：yq 4.54.1

yq comes from the official mikefarah/yq Linux binary (yq_linux_amd64 / yq_linux_arm64), the same way jq does: a bare executable, so the version file points straight at the release asset. No dependencies are declared.

yq 取自 mikefarah/yq 官方的 Linux 二进制（yq_linux_amd64 / yq_linux_arm64），做法与 jq 相同：裸可执行文件，版本文件直接指向 release 资产。不声明任何依赖。

数据在 LinuxWaveOrg/infosource 仓库的 main 分支。

由于wave install会自动拉取最新数据，你无需手动更新

Because of wave install automatically pulls the latest data, you don't need to update manually.

LinuxWave 2.6.5

Release Note 更新日志

本次修一处提示判断错误：判断「要不要重新登录」时查错了地方。

问题

安装器与 selfupdate 都会在需要重新登录时提示用户。判断依据原本写成了 id -G <用户名>，但 id 的两种形式语义不同（已用隔离实验确认）：

形式	实际读的是什么	后果
id -G <用户名>	/etc 数据库	把用户写进 /etc/group 后立刻就报出该组，看不见会话
id -G（不带参数）	当前会话的进程组	写进库也不认，必须重登才生效

于是「已被写进组、但当前 shell 还没重登」的用户会被告知「已经在组里，无需重登」——而实际上那一刻安装树对他依然是写不进去的。影响不大、而且会自愈（他随后 wave install 失败时报错信息会明确说明要重登），但这是句错话。

修法

两个判断各用各的语义，不再混用：

• 要不要 usermod → 用 id -G <用户名>（查库：此人配在组里了吗）；
• 要不要重新登录 → 用 id -G 不带参数（看会话：这个 shell 真的具备该组身份了吗）。

代码里对这一点留了注释，PROJECT_CONTEXT.md 也记了这条陷阱。

一并带上 2.6.4 / 2.6.3 的内容

从更早版本升上来的话，本版同时包含：

• 2.6.4：selfupdate.sh 也会配好共享写 —— 交回安装树属主（下载是拿 root 跑的，新文件以前会落成 root 属主），并给共享安装树补上组共享写（groupadd / usermod -aG / chmod -R g+w / 目录 setgid）。于是存量共享安装升级一次就到位，不必重装。
• 2.6.3：共享安装本身改成 Linuxbrew 式组共享，装包不再需要 sudo，也不需要写全路径。

wave selfupdate

装完之后要不要重新登录？

情形	要不要重登
这次才把你加进组	要 —— 重登，或在当前 shell 跑 newgrp linuxwave
你已在组里，但当前 shell 是入组之前开的	要 —— 同上
你已经入组、并且入组之后重登过	不要 —— 权限位与组身份都已生效

chgrp / chmod g+w / setgid 是立即生效的，只有「你个人的组身份」要等新的登录会话。

升级路径

当前版本	目标	行为
2.5.0 ~ 2.6.4	2.6.5	执行自更新 ✅
2.6.5	2.6.5	已是最新，短路退出

本次不涉及目录结构变更，updatedata/2.6.5/dir_structure_change 显式声明为 N。

为什么必须抬版本号：selfupdate 在「当前版本不低于线上版本」时直接短路。不抬版本的话，已经升到 2.6.4 的用户跑 wave selfupdate 只会被回一句「已是最新」，永远走不到修正后的 selfupdate.sh。

另外，wave selfupdate 仍然需要 sudo：它要重写 root 属主的 /etc/linuxwave_config/VERSION.json。

验证方式

• id 两种语义的隔离实验：在用户命名空间里建影子 /etc，把用户写进一个新组，然后对比 id -G <用户名>（立刻报出新 gid）与 id -G 不带参数（不报，必须重登）—— 修正正是基于这个结论。
• 回归套件：隔离命名空间里 133 条断言全绿（133 PASS / 0 FAIL / 0 SKIP）。沙箱里 linuxwave 组的 gid 只能是 0、而命名空间内 root 的会话本来就带 gid 0，所以「会话里还没有该组」这一分支在沙箱里走不到，已在 PROJECT_CONTEXT.md 的「已知限制」里写明，并由上面的隔离实验覆盖。
• bash -n：install.sh、selfupdate.sh、sandbox_test.sh 通过。

其他改动

• 版本号 2.6.4 → 2.6.5，构建号 281D0135

---

Release Notes

This release fixes one wrong decision: "do you need to log in again?" was looking in the wrong place.

The bug

Both the installer and selfupdate tell you when a re-login is needed. The check was written as id -G <user>, but the two forms of id mean different things (confirmed with an isolated experiment):

Form	What it actually reads	Consequence
id -G <user>	the /etc database	writing the user into /etc/group shows up immediately - it cannot see the session
bare id -G	the current session's process groups	a database change is not seen until you re-login

So a user already written into the group but not yet re-logged-in was told "already in the group; nothing to re-login for" - while at that moment the tree was still unwritable for them. The impact is small and self-correcting (the next wave install fails and its error message explains the re-login), but the sentence was wrong.

The fix

Each question now uses the form that answers it:

• whether to run usermod → id -G <user> (the database: is this person configured in the group?);
• whether a re-login is needed → bare id -G (the session: does this shell actually have the group?).

The code carries a comment about it, and PROJECT_CONTEXT.md records the trap.

This also carries 2.6.4 and 2.6.3

Coming from an older version, this release also includes:

• 2.6.4: selfupdate.sh now sets up shared write as well - it hands the tree's ownership back (downloads run as root, so new files used to land root-owned) and gives a shared tree its group write access (groupadd / usermod -aG / chmod -R g+w / setgid on directories). So an existing shared install gets this from one update, with no reinstall.
• 2.6.3: a shared install became a Linuxbrew-style group install, so installing a package needs neither sudo nor a full path.

wave selfupdate

Do you need to log in again afterwards?

Situation	Re-login needed?
This is what added you to the group	Yes - log out and back in, or run newgrp linuxwave
You are in the group, but this shell predates that	Yes - same as above
You are in the group and have logged in since	No - both the permission bits and your group identity are in place

chgrp / chmod g+w / setgid take effect immediately; only your group identity waits for a new login session.

Upgrade path

From	To	Behaviour
2.5.0 - 2.6.4	2.6.5	self-update runs ✅
2.6.5	2.6.5	already up to date, exits early

No directory structure change is involved - updatedata/2.6.5/dir_structure_change states N explicitly.

Why the version had to be bumped: selfupdate exits early when the installed version is not older than the published one. Without a bump, a user already on 2.6.4 running wave selfupdate would just be told "already up to date" and would never reach the corrected selfupdate.sh.

Also, wave selfupdate still needs sudo: it rewrites /etc/linuxwave_config/VERSION.json, which is root-owned.

How this was verified

• Isolated experiment on the two id semantics: inside a user namespace with a shadow /etc, a user was written into a new group and the two forms compared - id -G <user> reported the new gid immediately, bare id -G did not until a re-login. The fix rests on that result.
• Regression suite: all 133 assertions pass in the isolated namespace (133 PASS / 0 FAIL / 0 SKIP). In the sandbox the linuxwave group's gid can only be 0, and root's session inside the namespace already carries gid 0, so the "this session lacks the group" branch is unreachable there; that is recorded in the "known limitations" of PROJECT_CONTEXT.md and covered by the experiment above.
• bash -n: install.sh, selfupdate.sh and sandbox_test.sh parse.

Other Changes

• Version 2.6.4 → 2.6.5, build number 281D0135

---

安装

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

Install

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

LinuxWave 2.6.4

Release Note 更新日志

本次把 wave selfupdate 也补上了组共享：存量共享安装升级一次就到位，不必重装。

改了什么

1. selfupdate.sh 现在也配好共享写

安装器从 2.6.3 起会给共享安装自动配组共享写；但已经装好的那棵树不会凭空获得它。这一版让 selfupdate.sh 做同一套事：

• 把安装树的属主交回去 —— 下载是拿 root 跑的（NEED_SUDO=true 时 run_cmd 就是 sudo），新文件会落成 root 属主，以前一直没交回，共享安装树会慢慢变成 root 的；
• 给共享安装树补上组共享写：groupadd -f / usermod -aG / chmod -R g+w / 目录 setgid。

升级路径于是变成一句话：

wave selfupdate

属组是 root 的系统级安装（/opt、/usr/local）不碰这套，也不会劝人去加入 root 组 —— 与安装器同一个判断。

2. 装完之后要不要重新登录？分三种情形

情形	要不要重登
这次 selfupdate 才把你加进组	要 —— 重登，或在当前 shell 跑 newgrp linuxwave
你已在组里，但当前 shell 是入组之前开的	要 —— 同上
你已经入组、并且入组之后重登过	不要 —— 权限位与组身份都已生效

chgrp / chmod g+w / setgid 是立即生效的，只有「你个人的组身份」要等新的登录会话。所以这句提示不是每次都打：只在真需要的时候出现，已经有了就明说不用重登。

3. 安装器的提示挪到更显眼的位置

共享安装的「装完要重登一次」以前藏在收尾大段文字里，现在提到选完安装目录之后的前置说明里，用黄色单独成块。安装器与 selfupdate 的措辞也统一了。

一并带上 2.6.3 的内容

如果你是从 2.6.2 或更早升上来，2.6.4 同时包含 2.6.3 的改动：共享安装本身改成 Linuxbrew 式组共享（建 linuxwave 组、把调用者加进去、整棵树交给该组并打开组写位、目录加 setgid），于是装包不再需要 sudo，也不再需要写全路径：

wave install <package>

代价照实说：组内成员可以改动整棵树，包括 lib/ 里的 wave 本体。不需要多人装包的话，别配这套组共享写即可。

升级路径

当前版本	目标	行为
2.5.0 ~ 2.6.3	2.6.4	执行自更新，并补上组共享 ✅
2.6.4	2.6.4	已是最新，短路退出

本次不涉及目录结构变更，updatedata/2.6.4/dir_structure_change 显式声明为 N，自更新会跳过迁移步骤。

为什么必须抬版本号：selfupdate 在「当前版本不低于线上版本」时会直接短路退出。不抬版本的话，已经升到 2.6.3 的用户跑 wave selfupdate 只会被回一句「已是最新」，永远走不到新的 selfupdate.sh。

另外，wave selfupdate 仍然需要 sudo，与写权限无关：它要重写 root 属主的 /etc/linuxwave_config/VERSION.json。

验证方式

• 回归套件：隔离命名空间里 133 条断言全绿（133 PASS / 0 FAIL / 0 SKIP）。本次改的是提示措辞与 selfupdate，套件里与组共享相关的断言（调用者入组、组写位、setgid、需重登提示、重复安装不再谎称刚入组、usermod 失败仍安装成功、组名反查、root:root 的树不劝人加入 root 组）逐条通过。
• bash -n：install.sh、selfupdate.sh、sandbox_test.sh 全部通过。
• 权限模型与端到端安装（2.6.3 时做的，本次未改这部分逻辑）：真实非 root 用户免 sudo 写满五个数据目录；真实跑 wave install jq 成功，输出里 sudo 出现 0 次。

其他改动

• 版本号 2.6.3 → 2.6.4，构建号 281D0117

---

Release Notes

This release extends the group-shared install to wave selfupdate: an existing shared install now gets it from one update, with no reinstall.

What changed

1. selfupdate.sh now sets up shared write too

Since 2.6.3 the installer configures group-shared write for a shared install; but an already installed tree does not gain it by itself. This release makes selfupdate.sh do the same work:

• it hands the tree's ownership back - downloads run as root (run_cmd is sudo when NEED_SUDO=true), so new files land root-owned, and they were never handed back, which slowly turned a shared tree into root's;
• it gives a shared tree its group write access: groupadd -f / usermod -aG / chmod -R g+w / setgid on directories.

The upgrade path is therefore one command:

wave selfupdate

System-level installs whose group is root (/opt, /usr/local) are left alone, and nobody is told to join the root group - the same test the installer uses.

2. Do you need to log in again afterwards? Three cases

Situation	Re-login needed?
This update is what added you to the group	Yes - log out and back in, or run newgrp linuxwave
You are in the group, but this shell was started before that	Yes - same as above
You are in the group and have logged in since	No - both the permission bits and your group identity are already in place

chgrp / chmod g+w / setgid take effect immediately; only your group identity waits for a new login session. That is why the notice is not printed every time - it appears only when it is actually needed, and says so explicitly when nothing is required.

3. The installer's notice moved somewhere more visible

"Log out and back in after this install" used to be buried in the closing notes; it now sits in the pre-flight block right after you pick the install directory, highlighted on its own. The installer and selfupdate now use the same wording.

This also carries the 2.6.3 changes

If you are coming from 2.6.2 or older, 2.6.4 includes what 2.6.3 did: a shared install is now a Linuxbrew-style group install (it creates the linuxwave group, adds the caller to it, hands the tree to that group, opens the group write bits and sets setgid on directories). Installing a package then needs neither sudo nor a full path:

wave install <package>

The cost, stated plainly: members of the group can modify the whole tree, lib/wave itself included. If you do not need several users installing packages, simply do not set the group write bit up.

Upgrade path

From	To	Behaviour
2.5.0 - 2.6.3	2.6.4	self-update runs and sets up shared write ✅
2.6.4	2.6.4	already up to date, exits early

No directory structure change is involved - updatedata/2.6.4/dir_structure_change states N explicitly - so the self-update skips the migration steps.

Why the version had to be bumped: selfupdate exits early when the installed version is not older than the published one. Without a bump, a user already on 2.6.3 running wave selfupdate would just be told "already up to date" and would never reach the new selfupdate.sh.

Also, wave selfupdate still needs sudo, independently of write permissions: it rewrites /etc/linuxwave_config/VERSION.json, which is root-owned.

How this was verified

• Regression suite: all 133 assertions pass in the isolated namespace (133 PASS / 0 FAIL / 0 SKIP). This change is about prompt wording and selfupdate; every group-shared assertion (the caller joins the group, the group write bit, setgid, the re-login notice, a second install no longer claiming a fresh group change, a failing usermod still leaving a successful install, the gid-to-name lookup, a root:root tree not being told to join the root group) passes one by one.
• bash -n: install.sh, selfupdate.sh and sandbox_test.sh all parse.
• Permission model and end-to-end install (done for 2.6.3; that logic is unchanged here): a real non-root user wrote to all five data directories with no sudo; a real wave install jq succeeded with sudo appearing 0 times in its output.

Other Changes

• Version 2.6.3 → 2.6.4, build number 281D0117

---

安装

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

Install

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

LinuxWave 2.6.3

Release Note 更新日志

本次改的是共享安装的写法：/home/linuxwave/.linuxwave 改成 Linuxbrew 式组共享，装包不再需要 sudo。

改了什么

1. 共享安装（选项 4）自动做成组共享

以前装完共享安装，只有 linuxwave 账号和 root 能装包，普通用户必须写 sudo /home/linuxwave/.linuxwave/lib/wave install <package> 这种全路径命令（sudo wave … 还必然失败，因为 sudo 用的是它自己那套 PATH）。

现在安装器会自己把这件事做完：

• 建 linuxwave 组（已存在就跳过）；
• 把运行安装器的人加进该组；
• chgrp -R 把安装树交给该组，chmod -R g+w 打开组写位；
• 给所有目录加上 setgid —— 不加的话组员新建的文件会落回他自己的主组，下一个组员就改不动了。

于是装包既不用 sudo，也不用全路径：

wave install <package>

2. 一句必须说清的话：组身份要重新登录才生效

组身份只在新的登录会话里生效。所以装完（或后来被 usermod -aG 加进组）之后，要退出重登一次，或在当前 shell 里跑 newgrp linuxwave，装包才会成功——在那之前树依然是写不进去的。这不是实现缺陷，是 Unix 的组语义。安装器的收尾提示、以及写不进树时的报错，都会把这一点讲明白。

3. 写不进树时的报错重写了

新增/改写后的提示会给出：

• 一条能跑通的 sudo 全路径命令；
• 如果安装树的属组不是 root，再加一条 sudo usermod -aG <组> <你>，并点明「刚被加进组、还没重登」正是最常见的原因——不说这句，用户会以为是装坏了；
• 组名是按 gid 反查出来的，不是写死的。树属 root:root（/opt、/usr/local 这类系统级安装）时故意不提组，免得建议用户去加入 root 组。

4. usermod 失败不会毁掉整个安装

账号由 LDAP/SSSD 管理、/etc/group 里有重复条目等情况下 usermod 会失败。这时安装照常成功（树已经装好、也仍然能用），只是如实报告并打出手工命令。

升级路径

当前版本	目标	行为
2.5.0 ~ 2.6.2	2.6.3	执行自更新 ✅
2.6.3	2.6.3	已是最新，短路退出

本次不涉及目录结构变更，updatedata/2.6.3/dir_structure_change 显式声明为 N，自更新会跳过迁移步骤。

wave selfupdate

已经装好的共享安装要额外做一步

自更新不会让原有的共享安装树变成组共享：selfupdate.sh 只替换代码文件（外加把下载来的脚本 chmod +x），不动属组与权限。想要这套权限，两条路：

• 重新跑一次安装器并选共享安装（选项 4）；或
• 按 .templates/SPECIAL/INSTALL_BY_INTERNET.md 末尾「可选：让多个用户都能安装软件包」的手工步骤配一次（groupadd / usermod -aG / chgrp / g+w / setgid），然后重新登录。

另外，wave selfupdate 仍然需要 sudo，与写权限无关：它要重写 root 属主的 /etc/linuxwave_config/VERSION.json。

代价（照实说）

组内成员可以改动整棵树，包括 lib/ 里的 wave 本体。这是 INSTALL_BY_INTERNET.md 早就写明的那笔代价，本次只是把它自动化了。如果不需要多人装包，只做「读 + 执行」那一档（不要组共享写）即可。

验证方式

三条互相独立的证据：

1. 回归套件：隔离命名空间里的断言从 117 条扩到 133 条，全绿（133 PASS / 0 FAIL / 0 SKIP）。新增覆盖：调用者被加进组、树目录打开组写位、目录带 setgid、提示写明需重新登录、重复安装不再谎称刚入组、usermod 失败时安装仍成功并如实报告、root:root 的树不劝人加入 root 组、组名反查判定。
2. 权限模型对照实验（真实非 root 用户，全程无 sudo）：不成组时写入被拒（EACCES）；按新方式设好权限后，downloads/、bin/、pkg/、links/、deps/ 五个数据目录全部可写，且新文件自动继承组。
3. 端到端安装：以非 root 用户真实跑 wave install jq，下载 2.3 MB → sha256 校验 → 解包 → 装二进制 → 建版本链接与不带版本的软链接，退出码 0，输出里 sudo 出现 0 次，装出来的 jq --version 可正常运行。

其他改动

• 版本号 2.6.2 → 2.6.3，构建号 281D0052
• 文档同步：README（中英）、官网、INSTALL_BY_INTERNET.md、PROJECT_CONTEXT.md

---

Release Notes

This release changes how a shared install works: /home/linuxwave/.linuxwave is now a Linuxbrew-style group install, so installing packages needs no sudo.

What changed

1. A shared install (option 4) is now set up as a group install automatically

Previously, after a shared install only the linuxwave account and root could install packages; everyone else had to spell out sudo /home/linuxwave/.linuxwave/lib/wave install <package> (and sudo wave … cannot work at all, because sudo searches its own PATH).

The installer now does that work itself:

• creates the linuxwave group (skipped if it already exists);
• adds the user who ran the installer to it;
• chgrp -Rs the tree to that group and opens the group write bits with chmod -R g+w;
• sets setgid on every directory - without it, a file created by one member lands back in that member's own primary group and the next member cannot touch it.

So installing needs neither sudo nor a full path:

wave install <package>

2. One thing that has to be said plainly: group membership needs a new login

Group membership only takes effect in a new login session. So after the install (or after being added to the group later with usermod -aG), log out and back in, or run newgrp linuxwave in the current shell, before installing. Until then the tree is still unwritable. That is not an implementation defect - it is Unix group semantics. Both the installer's closing notes and the error you get when writing fails say this explicitly.

3. The write-permission error was rewritten

The message now gives you:

• a sudo command with the full path that actually works;
• if the tree's group is not root, also sudo usermod -aG <group> <you>, and it points out that "just added to the group, not re-logged-in yet" is the most common reason - without that sentence users assume the install is broken;
• the group name is looked up by gid, not hard-coded. When the tree is root:root (system-level installs such as /opt or /usr/local) the group suggestion is deliberately omitted, so nobody is told to join the root group.

4. A failing usermod no longer ruins the install

usermod fails when the account is managed by LDAP/SSSD, when /etc/group has duplicate entries, and so on. The install now still succeeds (the tree is installed and remains usable) and simply reports the failure with the manual command.

Upgrade path

From	To	Behaviour
2.5.0 - 2.6.2	2.6.3	self-update runs ✅
2.6.3	2.6.3	already up to date, exits early

No directory structure change is involved - updatedata/2.6.3/dir_structure_change states N explicitly - so the self-update skips the migration steps.

wave selfupdate

An existing shared install needs one extra step

Self-update will not turn an existing shared tree into a group install: selfupdate.sh only replaces code files (plus chmod +x on the scripts it downloads) and never touches ownership or permissions. To get the new permissions, either:

• re-run the installer and choose the shared install (option 4); or
• follow the manual steps in .templates/SPECIAL/INSTALL_BY_INTERNET.md, section "optional: let several users install packages" (groupadd / usermod -aG / chgrp / g+w / setgid), then log out and back in.

Also, wave selfupdate still needs sudo, independently of write permissions: it rewrites /etc/linuxwave_config/VERSION.json, which is root-owned.

The cost, stated plainly

Members of the group can modify the whole tree, lib/wave itself included. That is the cost INSTALL_BY_INTERNET.md has always documented; this release only automates it. If you do not need several users installing packages, stay on the read-and-execute-only level (no group write).

How this was verified

Three independent pieces of evidence:

1. Regression suite: assertions in the isolated namespace grew from 117 to 133, all green (133 PASS / 0 FAIL / 0 SKIP). New coverage: the caller joins the group, the tree opens its group write bits, directories carry setgid, the notes say a re-login is needed, a second install no longer claims a fresh group change, a failing usermod still leaves the install successful and reported, a root:root tree is not told to join the root group, and the gid-to-name lookup.
2. Permission-model control experiment (a real non-root user, no sudo anywhere): writing is refused without the group (EACCES); with the new permission scheme all five data directories - downloads/, bin/, pkg/, links/, deps/ - are writable and newly created files inherit the group.
3. End-to-end install: as a non-root user, wave install jq really ran - 2.3 MB downloaded, sha256 verified, unpacked, binary installed, versioned link and unversioned symlink created, exit code 0, sudo appearing 0 times in the output, and the installed jq --version runs.

Other Changes

• Version 2.6.2 → 2.6.3, build number 281D0052
• Documentation synced: READMEs (English and Chinese), the website, INSTALL_BY_INTERNET.md, PROJECT_CONTEXT.md

---

安装

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

Install

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

LinuxWave 2.6.2

Release Note 更新日志

本次为域名迁移发布：官网由 linuxwave.macwave.org 迁移至 linuxwave.org。

为什么需要单独发一版

官网自定义域已经迁移到 linuxwave.org。旧域 linuxwave.macwave.org 现在返回 301，
自动跳转到新域，所以旧链接仍然可用，不会报错。代码里所有指向官网的链接都已改掉，
共 22 处 / 5 个分支。

但仍然推荐迁移：301 是重定向在兜底，不等于旧地址本身还有效——它依赖重定向一直被配置着，
撤掉就会立刻变成死链；不跟随重定向的工具（例如不带 -L 的 curl）在旧域上拿到的也只是
301 而不是内容。

而且只改代码不够。selfupdate 在「当前版本不低于线上版本」时会直接短路退出：

🌊 LinuxWave is already up to date (current: 2.6.1).

也就是说，只改代码的话，已装 2.6.1 的用户跑 wave selfupdate 会被答复「已是最新」，
本地 lib/help.py 里印的官网地址会一直停在旧域，只能靠 301 兜底。抬版本号，存量用户才拿得到。

改了什么

1. 官网域名 linuxwave.macwave.org → linuxwave.org（22 处）

位置	说明
lib/install.sh	安装器结尾的许可协议提示行
lib/help.py	wave help 里印的官网地址
README.md / README.zh-Hans.md	顶部「官方网站」链接
.templates/SPECIAL/*	安装交互与示例文档
官网条款第 17 条	「官方唯一网址」（中英两版）
gh-pages/CNAME	GitHub Pages 的自定义域

2. 有意保持不变的部分

• 反馈邮箱仍是 hi@macwave.org：macwave.org 这个域还在，邮箱没有迁移；
  官网条款第 22 条对这个地址有专门约定，不随官网域名一起改。
• https://macwave.org 与 https://sw.macwave.org 不动：它们分别指向 MacWave 项目
  与 MacWave 团队，不属于 LinuxWave 的官网迁移范围。

升级路径已验证

当前版本	目标	行为
2.5.0 / 2.5.1 / 2.5.2 / 2.5.3 / 2.6.0 / 2.6.1	2.6.2	执行自更新 ✅
2.6.2	2.6.2	已是最新，短路退出

本次不涉及目录结构变更，已在 updatedata/2.6.2/dir_structure_change 里显式声明为 N，
因此自更新会跳过迁移步骤，不会搬动你的配置目录。

wave selfupdate

验证方式

• 域名：linuxwave.org 返回 200，且 /install.sh 短链返回 200 并内含新版本号——
  这条短链就是安装入口，已确认可用。旧域已配置 301 跳转到新域。
• 回归套件：隔离命名空间里的 117 条断言全部通过（117 PASS / 0 FAIL / 0 SKIP），
  本次为纯字符串改动，未触碰任何逻辑分支。
• 分支一致性：main / 2.5 / gh-pages 三处的 install.sh 逐字节相同；
  main 与 2.5 整树逐字节相同（diff -rq 无输出）。
• 站点：本地渲染核查，正文里旧域只剩你有意保留的反馈邮箱。

其他改动

• 版本号 2.6.1 → 2.6.2，构建号 280H2020

---

Release Notes

A domain-migration release: the official site moved from linuxwave.macwave.org to linuxwave.org.

Why this needs a release of its own

The site's custom domain has moved to linuxwave.org. The old linuxwave.macwave.org now returns
301 and redirects to the new domain, so old links still work without an error. Every link
to the site in the code has been updated - 22 occurrences across 5 branches.

Migrating is still recommended, though: the 301 is a redirect doing the catching, not the old
address being valid - it depends on the redirect staying configured, and taking it away turns the
old links into dead ones immediately. Tools that do not follow redirects (a curl without -L,
say) get the 301 rather than any content.

And updating the code alone is not enough. selfupdate exits early when the installed version is
not older than the published one:

🌊 LinuxWave is already up to date (current: 2.6.1).

So with a code change alone, a user on 2.6.1 running wave selfupdate would be told they are
up to date, and the URL printed by their local lib/help.py would keep pointing at the old domain,
with only a 301 to catch it. Bumping the version is what actually delivers the fix.

What changed

1. Site domain linuxwave.macwave.org → linuxwave.org (22 occurrences)

Where	What
lib/install.sh	the licence notice printed at the end of an install
lib/help.py	the site URL printed by wave help
README.md / README.zh-Hans.md	the "official website" link at the top
.templates/SPECIAL/*	install-interaction and install-example docs
Site terms, clause 17	"the only official website" (both languages)
gh-pages/CNAME	the GitHub Pages custom domain

2. Deliberately left alone

• The feedback address is still hi@macwave.org: the macwave.org domain still exists and
  the mailbox did not move. Clause 22 of the site terms has specific wording about this address,
  so it does not follow the site domain.
• https://macwave.org and https://sw.macwave.org are untouched: they point at the MacWave
  project and the MacWave team, which are outside the scope of this LinuxWave site migration.

Upgrade path verified

From	To	Behaviour
2.5.0 / 2.5.1 / 2.5.2 / 2.5.3 / 2.6.0 / 2.6.1	2.6.2	self-update runs ✅
2.6.2	2.6.2	already up to date, exits early

No directory structure change is involved - updatedata/2.6.2/dir_structure_change
states N explicitly - so the self-update skips the migration steps and leaves your
configuration directory where it is.

wave selfupdate

How this was verified

• Domains: linuxwave.org returns 200, and its /install.sh short link returns 200 containing
  the new version number - that short link is the install entry point, and it is confirmed working.
  The old domain is configured to return 301 and redirect to the new one.
• Regression suite: all 117 assertions pass inside an isolated namespace
  (117 PASS / 0 FAIL / 0 SKIP). This change is purely textual and touches no logic branch.
• Branch consistency: install.sh is byte-identical across main / 2.5 / gh-pages, and the
  main and 2.5 trees are byte-identical (diff -rq reports nothing).
• Site: checked in a locally rendered page; the only remaining macwave.org text in the body
  is the feedback address deliberately kept.

Other Changes

• Version 2.6.1 → 2.6.2, build number 280H2020

---

安装

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

Install

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

LinuxWave 2.6.1

Release Note 更新日志

本次为缺陷修复发布：修掉 6 个真实缺陷，全部来自一份用户终端实录。

致谢

感谢 Stephen Zhang（@Robzhdev） 提供了一份完整的安装终端实录。
下面 6 项里有 5 项是照着实录复现出来的——没有那份记录，这些问题在开发机上很难被碰到，
因为它们的共同前提是「普通用户 + 网络不稳 + 共用安装」。

修了什么

1. sudo wave install 报「找不到命令」

sudo 用的是它自己那套 PATH，里面没有安装树的 bin / lib，所以 sudo wave …
必然失败——而安装器此前推荐的正是这条命令。现在共享安装的收尾提示与安装器的
共享安装说明都给出可直接复制的全路径写法：

sudo /home/linuxwave/.linuxwave/lib/wave install <package>

2. 写不进安装树时报原始 [Errno 13]，而且要等到下载到一半才失败

在共用安装树下用普通账号装包，此前会先联网取版本、再下载、最后才在落盘时抛出一个
原始 [Errno 13] Permission denied: …，用户既看不出原因，也不知道该用什么命令。

现在在联网取版本之前就先检查下载目录与落盘目录能否写入，不能写就立刻停下，
并打印：树属于哪个账号、为什么写不进去、要执行哪条 sudo 全路径命令、以及
想让多个用户免 sudo 装包该看哪份文档。

3. Ctrl-C 打出一整段 Python traceback

下载卡住时按 Ctrl-C，此前会把调用栈整段喷出来。现在只有一行：

🌊 Interrupted. Nothing was installed.

退出码 130。另外，停在 Do you want to retry? [y/N] 提示上按 Ctrl-C，此前会被
当成「不想重试」而打印 Error: Failed to download package——把用户自己按的打断
说成下载失败；现在同样报成 interrupted。

4. 目录菜单输入无效时会静默换到别的目录

在安装目录菜单里输错内容，此前会静默回落到 ~/.local/linuxwave 并继续安装——
等于把东西装到了用户没选的位置。现在会明确报错，最多重试 3 次，然后退出（退出码 1），
绝不静默换目录。

5. 单个文件下载失败没有重试

实录里用户因为一个文件传输被重置，手工重跑了 8 次以上。现在 20 个程序文件里
任何一个失败都会自动重试，每个文件最多 5 次（退避等待，单次连接 20 秒、总时长 180 秒上限）。
重试提示始终打印——它解释了这次安装为什么变慢；--silent 只压掉逐文件的进度输出。

6. --silent 单独使用时仍会弹菜单

README 承诺 --silent 会自动应答目录菜单，但不带 --dir-option 时它其实仍会去读终端，
没有终端时就喷出 /dev/tty 的原始报错。现在它会明确选择默认项并说出来是哪一个：

🌊 --silent without --dir-option: using the default, $HOME/.local/linuxwave

升级路径已验证

当前版本	目标	行为
2.5.0 / 2.5.1 / 2.5.2 / 2.5.3 / 2.6.0	2.6.1	执行自更新 ✅
2.6.1	2.6.1	已是最新，短路退出

本次不涉及目录结构变更，已在 updatedata/2.6.1/dir_structure_change 里显式声明为 N，
因此自更新会跳过迁移步骤，不会搬动你的配置目录。

wave selfupdate

验证方式

这些改动都在隔离命名空间里跑过：影子 /etc、/home、/opt、/usr/local、/root、
/var、/srv，宿主的这些目录一个字节都不会被写。回归套件已从 82 条断言扩到 117 条，
覆盖安装目录、许可协议回滚、卸载确认语义、中途失败指引、下载重试、菜单校验、
--silent、共用安装的写入权限、Ctrl-C（下载中与重试提示两处）以及软链接回归。

其中「共用安装树不可写」用只读挂载真实复现；「Ctrl-C」用本地挂起代理与本地关闭端口
真实复现；修完还把旧代码临时打回去确认新断言确实会失败，避免写出永远通过的测试。

其他改动

• 版本号 2.6.0 → 2.6.1，构建号 280H1920

---

Release Notes

A defect-fix release: 6 real bugs, all reproduced from a user's terminal transcript.

Credit

Thanks to Stephen Zhang (@Robzhdev) for sending a complete
transcript of an install session. 5 of the 6 items below came straight out of it - they are
hard to hit on a development machine, because they all need the same combination of an
ordinary user, an unreliable network and a shared install.

What was fixed

1. sudo wave install said "command not found"

sudo searches its own PATH, which does not contain the install tree's bin / lib,
so sudo wave … cannot work - and that was the command the installer recommended.
The shared-install summary and the installer's shared-install notes now give the
copy-pasteable form:

sudo /home/linuxwave/.linuxwave/lib/wave install <package>

2. An unwritable install tree reported a raw [Errno 13], and only after downloading

Installing as a normal user into a shared tree used to fetch version info, download the
package, and only then fail while writing, with a bare [Errno 13] Permission denied: ….
The user could see neither the cause nor the command that would work.

The installer now checks that the download and install directories are writable
before going online for version info, and stops immediately with: who owns the tree,
why it is not writable, the exact sudo command to run, and a pointer to the
shared-write group documentation.

3. Ctrl-C printed a full Python traceback

Pressing Ctrl-C while a download stalled printed the whole call stack. It now prints
one line:

🌊 Interrupted. Nothing was installed.

and exits with code 130. Separately, pressing Ctrl-C at the Do you want to retry? [y/N]
prompt used to be read as "do not retry" and reported as
Error: Failed to download package - calling the user's own interrupt a download failure.
It is now reported as an interrupt too.

4. An invalid menu answer silently switched directories

A wrong answer at the directory menu used to fall back to ~/.local/linuxwave and carry on,
installing into a directory the user had not chosen. It now reports the error, retries up to
3 times, and then exits (code 1) - never silently choosing another directory.

5. A single failed file download was not retried

In the transcript the user re-ran the installer more than 8 times because one file's transfer
kept getting reset. Any of the 20 program files is now retried automatically, up to 5 times
each (with a back-off pause, a 20-second connect timeout and a 180-second total cap).
The retry notice is always printed - it explains why the install is taking longer - while
--silent still suppresses the per-file progress output.

6. --silent on its own still opened the menu

The README promises that --silent answers the directory menu, but without --dir-option
it still tried to read a terminal and leaked a raw /dev/tty error when there was none.
It now picks the default explicitly and says which one it used:

🌊 --silent without --dir-option: using the default, $HOME/.local/linuxwave

Upgrade path verified

From	To	Behaviour
2.5.0 / 2.5.1 / 2.5.2 / 2.5.3 / 2.6.0	2.6.1	self-update runs ✅
2.6.1	2.6.1	already up to date, exits early

No directory structure change is involved - updatedata/2.6.1/dir_structure_change
states N explicitly - so the self-update skips the migration step and will not move
your config directory.

wave selfupdate

How this was verified

Everything ran inside an isolated namespace with shadow copies of /etc, /home, /opt,
/usr/local, /root, /var and /srv; not one byte of the host's copies is written.
The regression suite grew from 82 to 117 assertions, covering install directories, the
licence-agreement rollback, uninstall confirmations, mid-install failure guidance, download
retries, menu validation, --silent, write permission on a shared tree, Ctrl-C (both while
downloading and at the retry prompt), and the symlink regression.

"Unwritable shared tree" is reproduced with a real read-only mount; Ctrl-C with a local
hanging proxy and a local closed port. After fixing, the old code was temporarily put back to
confirm the new assertions do fail - so the tests are not ones that can never fail.

Other Changes

• Version 2.6.0 → 2.6.1, build number 280H1920

---

安装

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

Install

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

LinuxWave 2.6.0

Release Note 更新日志

本次发布只为迁移，功能没有任何变化。

仓库迁移

LinuxWave 的代码仓库已从 github.com/Sha0huaZhang/LinuxWave 迁移到
github.com/LinuxWaveOrg/LinuxWave。

这是 2.6.0 唯一的改动：新版本的代码里所有地址都直接指向新组织，不再依赖旧地址的跳转。

为什么发一个版本

迁移本身不需要改代码，但需要用户拿到指向新地址的代码。而 wave selfupdate 在
「已是最新」时会直接短路退出（当前版本 ≥ 远端版本即不动作），所以仅改地址的老用户
不会主动去取新地址——于是本次把版本号提到 2.6.0，让 2.5.x 的用户执行
wave selfupdate 时真正触发更新，一次性完成迁移。

你要做什么

推荐：执行一次自更新

wave selfupdate

执行后你的本地代码会换成指向新组织的版本，从此不再依赖旧地址跳转。

或者：重新安装

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

什么都不做也可以

旧地址目前仍然可用（实测：返回内容与新地址一致），wave install / list /
uninstall 都不受影响。已安装的软件包、配置、软链接也不会被动到——
本次自更新只覆盖程序自身的代码文件与 VERSION.json。

升级路径已验证

当前版本	目标	行为
2.5.0 / 2.5.1 / 2.5.2 / 2.5.3	2.6.0	执行自更新 ✅
2.6.0	2.6.0	已是最新，短路退出

本次不涉及目录结构变更，已在 updatedata/2.6.0/dir_structure_change 里显式声明为 N，
因此自更新会跳过迁移步骤，不会搬动你的配置目录。

新地址

仓库	https://github.com/LinuxWaveOrg/LinuxWave
发布页	https://github.com/LinuxWaveOrg/LinuxWave/releases
网站	https://linuxwave.macwave.org （不变）

请认准官方地址

官方仓库只有 LinuxWaveOrg/LinuxWave，官方网站只有 linuxwave.macwave.org，
官方反馈邮箱只有 hi@macwave.org。从其它来源获取的安装命令请勿执行。

其他改动

• 版本号 2.5.3 → 2.6.0，构建号 280H1140

---

Release Notes

This release exists only for the migration. Nothing about the feature set changed.

Repository migration

The LinuxWave repository has moved from github.com/Sha0huaZhang/LinuxWave to
github.com/LinuxWaveOrg/LinuxWave.

That is the only change in 2.6.0: the code now points straight at the new
organisation and no longer depends on the old location redirecting.

Why cut a release at all

The move needed no code change, but users do need to obtain the code that
points at the new address. wave selfupdate short-circuits when there is
nothing newer (it exits as soon as the local version is >= the published one),
so simply changing the address would leave existing installs on the old URL.
Raising the version to 2.6.0 makes wave selfupdate actually run for anyone on
2.5.x, completing the migration in one step.

What you need to do

Recommended: run the self-update once

wave selfupdate

Your local copy then carries the new addresses and no longer relies on the old
location redirecting.

Or: reinstall

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

Or: do nothing

The old address still works today (verified: it serves the same content as
the new one), and wave install / list / uninstall are unaffected. Your
installed packages, configuration and unversioned links are untouched - this
self-update only rewrites LinuxWave's own code files and VERSION.json.

Upgrade path verified

From	To	Behaviour
2.5.0 / 2.5.1 / 2.5.2 / 2.5.3	2.6.0	self-update runs ✅
2.6.0	2.6.0	already up to date, exits early

No directory structure change is involved - updatedata/2.6.0/dir_structure_change
states N explicitly - so the self-update skips the migration step and will
not move your config directory.

New addresses

Repository	https://github.com/LinuxWaveOrg/LinuxWave
Releases	https://github.com/LinuxWaveOrg/LinuxWave/releases
Website	https://linuxwave.macwave.org (unchanged)

Only the official addresses

The only official repository is LinuxWaveOrg/LinuxWave, the only official
website is linuxwave.macwave.org, and the only official feedback address is
hi@macwave.org. Do not run install commands from anywhere else.

Other Changes

• Version 2.5.3 → 2.6.0, build number 280H1140

---

安装

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

Install

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

Site Notice-2026100701

Site Notice 站点公告

官网域名已迁移：linuxwave.macwave.org → linuxwave.org

旧地址现在返回 301，会自动跳转到新域，所以旧链接不会报错。但仍推荐迁移：请更新你的书签，
把文档和脚本里留的地址也一并换成新的——301 只是重定向在兜底，撤掉就会立刻变成死链。

你需要做什么

没有装过 LinuxWave 的：什么都不用做。安装命令一个字都没变——它指向的是
raw.githubusercontent.com，跟官网域名无关，所以以前复制过的命令照样能用：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

已经装过的：请升级到 2.6.2：

wave selfupdate

为什么要专门升这一版：selfupdate 在版本相同时会直接短路，回一句
LinuxWave is already up to date。所以光改代码不够——只有把版本号抬上去，
2.6.1 及更早的用户才真的能拿到新域名。这一版修的就是这件事。

升级后，wave help 里印的官网地址才会是 linuxwave.org；在此之前它印的是旧域，只能靠 301 兜底。

没有变的部分

• 反馈邮箱仍是 hi@macwave.org。邮箱没有跟着官网一起迁移，请继续用它。
• MacWave 自己的域名没有变（macwave.org、sw.macwave.org）。那是 MacWave 项目，
  不属于 LinuxWave 的官网迁移范围。
• 安装目录、配置文件、已装软件包的位置都没有变。本次不涉及目录结构变更，
  自更新会跳过迁移步骤，不会搬动你的任何数据。

一句话

官网换了，命令没换，装过的跑一次 wave selfupdate。有问题请发邮件到 hi@macwave.org。

---

Site Notice

The official website has moved: linuxwave.macwave.org → linuxwave.org

The old address now returns 301 and redirects to the new one, so old links still work.
Migrating is still recommended, though: please update your bookmarks and any links you keep in
docs or scripts - the 301 is only a redirect doing the catching, and taking it away turns the old
links into dead ones.

What you need to do

If you have not installed LinuxWave: nothing. The install command is unchanged - it points at
raw.githubusercontent.com, not at the site domain - so a command you copied earlier still works:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

If you already have LinuxWave installed: please upgrade to 2.6.2:

wave selfupdate

Why a release is needed for this: selfupdate exits early when the installed version is not
older than the published one, answering LinuxWave is already up to date. Updating the code alone
would therefore not reach anyone - only bumping the version actually delivers the new domain to
users on 2.6.1 and older. That is what this release fixes.

After the upgrade, the site address printed by wave help is linuxwave.org; before it, it prints
the old domain, with only a 301 to catch it.

What did not change

• The feedback address is still hi@macwave.org. The mailbox did not move with the site;
  please keep using it.
• MacWave's own domains are unchanged (macwave.org, sw.macwave.org). That is the MacWave
  project, not part of the LinuxWave site migration.
• Your install directory, configuration and installed packages are all where they were. No
  directory structure change is involved, so the self-update skips the migration steps and moves
  none of your data.

In one line

The site moved, the commands did not, and an existing install just needs one wave selfupdate.
Questions: hi@macwave.org.