Package Details: wps-office-cn 12.1.2.25882-1

Git Clone URL: https://aur.archlinux.org/wps-office-cn.git (read-only, click to copy)
Package Base: wps-office-cn
Description: Kingsoft Office (WPS Office) CN version - an office productivity suite
Upstream URL: https://linux.wps.cn
Licenses: LicenseRef-WPS-EULA
Conflicts: kingsoft-office, wps-office
Provides: wps-office
Submitter: Universebenzene
Maintainer: Clover_Yan
Last Packager: Clover_Yan
Votes: 62
Popularity: 1.06
First Submitted: 2020-01-10 04:38 (UTC)
Last Updated: 2026-04-13 11:38 (UTC)

Dependencies (24)

Required by (20)

Sources (1)

Pinned Comments

asduhkv commented on 2026-01-14 14:15 (UTC) (edited on 2026-01-14 14:17 (UTC) by asduhkv)

如果从Dolphin无法用WPS打开PDF等文件，启动器中无法启动WPS文档、WPS表格等，可能是WPS默认的整合模式导致的，可以进入WPS的 设置\其他\切换窗口管理模式 改成多组件模式，即可解决问题；其后也可以再改回整合模式。前面的朋友的方法很有效。

Universebenzene commented on 2020-01-10 08:31 (UTC) (edited on 2020-01-10 08:45 (UTC) by Universebenzene)

[Attention] The zh_CN mui files (including all the Simplified Chinese support) are splitted into the wps-office-mui-zh-cn package. If you want zh_CN support, DO NOT FORGET to install the mui-zh-cn package.

Also the mui-zh-cn package can be installed to recover the zh_CN support of the Intl version https://aur.archlinux.org/packages/wps-office , but the login and some other supports are still only available in the CN version.

Latest Comments

1 2 3 4 5 6 .. 23 Next › Last »

alampy commented on 2026-05-30 18:16 (UTC) (edited on 2026-05-30 18:28 (UTC) by alampy)

eternalterminal: 文件系统中存在 /usr/bin/et （由 wps-office-cn 所有）

有办法给 wps 的组件改个名吗？和 EternalTerminal 项目的惯用 CLI 名称冲突了。

补充： 参考 https://github.com/Rongronggg9/wps-office-repack 把 et 改成 wpset，把 wpp 改成 wpswpp 我觉得是比较合理的选择。et 是个更纯粹的 CLI 工具，而 wps 几乎不需要在命令行中被调用。

peeeee commented on 2026-05-26 14:08 (UTC) (edited on 2026-05-26 14:10 (UTC) by peeeee)

https://gist.githubusercontent.com/slashiewn/a4665e6ec67d91e4467896df49f0c685/raw/ac14f733367d73c0fe49844864bbe345bbeeb40e/gistfile1.txt

强制wps界面默认语言为zh-cn，不受系统环境变量默认语言设置影响

clack commented on 2026-05-20 01:50 (UTC)

xlsx、docx等文件图标会被系统图标覆盖，通过以下命令可以让wps的图标优先显示

sudo sed -i 's/<generic-icon /<icon /g' /usr/share/mime/packages/custom-wps-office.xml

jy0x0 commented on 2026-05-04 08:24 (UTC)

wps 'PhD topic intro ABC_DE.pptx' /usr/bin/wps: 第 70 行：[: 参数太多

solution: sudo sed -i 's/if \[ \${gFilePath:0:7}/if [ "${gFilePath:0:7}"/g' /usr/bin/wps

my-self commented on 2026-04-25 12:02 (UTC)

WPS Office 2023 在 Arch Linux 下“带文件参数秒退 / 双击无反应”问题记录

更新时间：2026-04-25 18:59:46 CST

1. 问题现象

当前环境：

  • 系统：Arch Linux
  • WPS 包：wps-office-cn 12.1.2.24722-2
  • 语言包：wps-office-mui-zh-cn 12.1.2.24722-2
  • 字体包：wps-office-fonts 1.0-2
  • 桌面会话：Wayland，会话变量显示为 XDG_CURRENT_DESKTOP=niri，XDG_SESSION_TYPE=wayland

实际症状：

  • 直接运行 wps 可以正常启动欢迎界面。
  • 直接运行 wps /绝对/路径/文件.docx 时，WPS 无法正常打开文件。
  • 在文件管理器中双击 .docx 看起来“没有反应”。
  • 根因上，文件管理器双击本质也是执行带参数启动，例如：
wps /path/to/file.docx

因此只要“带路径参数启动”有问题，双击打开就一定会失效。

2. 已确认的事实
2.1 /usr/bin/wps 只是包装脚本

系统里的 wps 并不是真实二进制，而是一个 Bash 包装脚本：

which wps
# /usr/bin/wps

这个脚本最终调用真实程序：

/usr/lib/office6/wps

同时该脚本无论内部子进程是否失败，最后都会：

exit 0

因此：

  • 从 wps 脚本本身的退出码，无法可靠判断内部真实失败状态。
  • 诊断时必须直接看 /usr/lib/office6/wps 的行为。
2.2 配置目录不是主要矛盾

测试过将 HOME 指向一个全新的临时目录，让 WPS 在“空白用户配置”下启动：

HOME=/tmp/wps-clean-home /usr/lib/office6/wps /tmp/test.docx

结果仍然是 255 退出。

这说明：

  • ~/.config/Kingsoft 里的旧配置不是本问题的主因。
  • 即使清空用户配置，也不能解决“带参秒退”。
2.3 这不是“底层依赖库缺失”问题

现象上 WPS 裸启动正常，说明：

  • ELF 主程序可执行。
  • 主要动态库链条没有整体断裂。
  • Qt/XCB 至少在基本启动路径上是可用的。

如果是典型缺库问题，通常连裸启动都过不去。

3. 关键诊断结论
3.1 真正的问题不是“所有带参都死”，而是“绝对路径触发了 bug”

这是本次定位里最关键的一步。

失败路径：给绝对路径

直接执行真实二进制：

/usr/lib/office6/wps /tmp/codex-wps-test.docx

返回：

rc=255

并且 strace 显示：

  • 程序拿到了参数；
  • 读取了 /usr/lib/office6/cfgs/setup.cfg；
  • 读取了 ~/.config/Kingsoft/Office.conf；
  • 但在真正 open() 目标文档之前，直接执行了：
exit_group(-1)

也就是说：

  • 它不是“打开文档时崩了”；
  • 而是“看到某种参数形态后，内部判定失败，主动退出”。
成功路径：先进入文档目录，再给相对路径

测试方式：

cd /tmp/wps-reltest
/usr/lib/office6/wps a.docx

这条路径不再立即 255 秒退，而是继续进入图形初始化流程，说明：

  • WPS 并不是完全不能接收文件参数；
  • 它能处理相对路径；
  • 问题集中在绝对路径处理逻辑。
3.2 根因判断

基于实际行为，最合理的判断是：

wps-office-cn 12.1.2.24722-2 这一版在 Linux/Arch 当前环境下，对“绝对本地文件路径”的启动参数处理存在 bug。

更准确地说：

  • 绝对路径会触发内部某段前置校验或参数分流逻辑；
  • 该逻辑失败后直接 exit(-1)；
  • 由于失败点发生在真正打开文件之前，所以用户表面看到的是“无反应”；
  • 双击失败只是这个 bug 的连锁表现，不是 MIME 关联本身坏了。
4. 为什么不是之前怀疑的那几类问题
4.1 不是 Qt 平台插件主因

单独跑真实二进制且不在完整图形上下文时，确实能看到 Qt 类报错，例如：

qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
qt.qpa.xcb: could not connect to display :0

但这类报错只说明：

  • 裸终端环境下图形初始化不完整；
  • 与“绝对路径才秒退”不是同一个层面的故障。

真正关键的差异是：

  • 给绝对路径时，程序连文档都还没碰到就提前退出；
  • 给相对路径时，它会继续往后走。

因此主矛盾不是 Qt 插件本身。

4.2 不是 MIME 关联错误

系统查询结果显示 .docx 默认关联本来就是：

wps-office-wps.desktop

所以关联本身没坏。

问题在于：

  • 文件管理器传给 WPS 的通常是绝对路径；
  • 而当前 WPS 恰好对绝对路径处理异常；
  • 于是表现为双击无反应。
5. 已实施修复

采用的思路不是继续硬改 WPS 本体，而是在它外面加一层“路径改写”包装。

核心策略：

  1. 如果没有传文件参数，正常启动 WPS。
  2. 如果传入的是本地绝对路径或 file:// URI：
  3. 先解析出真实本地路径；
  4. cd 到文件所在目录；
  5. 再把参数改成相对文件名传给 WPS。
  6. 如果参数不是本地文件路径，则原样透传。

这样就能把：

wps /tmp/demo.docx

改造成逻辑等价的：

cd /tmp
wps demo.docx

从而绕开 WPS 的绝对路径 bug。

6. 实际修改的文件
6.1 包装脚本

新增：

/home/myself/.local/bin/wps-pathfix

用途：

  • 处理 wps、et、wpp 的文件路径参数；
  • 对绝对路径做“切目录 + 相对路径”改写。
6.2 本地 desktop 覆盖

新增：

/home/myself/.local/share/applications/wps-office-wps.desktop
/home/myself/.local/share/applications/wps-office-et.desktop
/home/myself/.local/share/applications/wps-office-wpp.desktop

它们覆盖了系统自带 desktop 项的 Exec=，分别改为：

Exec=/home/myself/.local/bin/wps-pathfix wps %U
Exec=/home/myself/.local/bin/wps-pathfix et %F
Exec=/home/myself/.local/bin/wps-pathfix wpp %F

这样做的好处：

  • 不修改系统包文件；
  • WPS 包升级后仍然容易回看和维护；
  • 用户级回退简单；
  • 文件管理器双击、xdg-open、MIME 打开路径都能走到修复逻辑。
7. 修复后的结果

验证结果：

  • 通过包装脚本传绝对路径后，不再立即返回 255；
  • 用户实际测试反馈：双击文件已经可以正常打开；
  • 因此该问题已通过用户级 workaround 修复。
8. 回退方法

如果以后 WPS 官方/AUR 新版本已经修掉这个问题，可以回退当前 workaround。

删除以下文件即可：

rm -f ~/.local/bin/wps-pathfix
rm -f ~/.local/share/applications/wps-office-wps.desktop
rm -f ~/.local/share/applications/wps-office-et.desktop
rm -f ~/.local/share/applications/wps-office-wpp.desktop
update-desktop-database ~/.local/share/applications

如果文件管理器仍缓存旧 desktop 条目，可重启文件管理器或重新登录图形会话。

9. 后续建议
9.1 如果以后要继续深挖

可继续追的方向：

  • 对比 WPS 处理绝对路径与相对路径时的内部启动分支；
  • 检查是否和 file:// URI、工作目录、单实例通信有关；
  • 关注 AUR wps-office-cn 新版本是否修复该问题。
9.2 当前最实用的结论

当前这台机器上，最靠谱的结论是：

WPS 本体可用，文档也能打开；坏掉的是“直接把绝对路径交给 WPS”的入口。

所以最稳妥、最小代价的方案就是保留本次用户级路径重写修复。

10. 一句话总结

这次故障不是“WPS 完全打不开文档”，而是：

这版 WPS 在 Arch/Linux 当前环境里对绝对路径参数有缺陷，导致文件管理器双击传参时秒退；通过把绝对路径改写成相对路径，问题已被稳定绕过。

与 " WPS的 设置\其他\切换窗口管理模式 改成多组件模式，即可解决问题；其后也可以再改回整合模式 " 应属同一问题,提供另外一种解决方法

kde_fcitx5 commented on 2026-03-19 09:26 (UTC)

asduhkv 在 2026-01-14 22:15 (CST) 发表了评论 (在 2026-01-14 22:17 (CST) 被 asduhkv 编辑) 如果从Dolphin无法用WPS打开PDF等文件，启动器中无法启动WPS文档、WPS表格等，可能是WPS默认的整合模式导致的，可以进入WPS的 设置\其他\切换窗口管理模式 改成多组件模式，即可解决问题；其后也可以再改回整合模式。前面的朋友的方法很有效。

要么上游修复，要么锁定评论

cont1nu1ty commented on 2026-03-11 11:01 (UTC)

对于wps-office-cn，在配置了 “解决方式：在 desktop 文件中，如wps-office-et.desktop 文件中，启动命令增加 参数： --ozone-platform=x11，如 Exec=/usr/bin/et --ozone-platform=x11 %F” ，仍不可用时，推荐配置：sudo nano /usr/bin/wps export QT_IM_MODULE=fcitx export GT_IM_MODULE=fcitx export XMODIFIERS=@im=fcitx 来提供IM配置

asduhkv commented on 2026-01-14 14:15 (UTC) (edited on 2026-01-14 14:17 (UTC) by asduhkv)

如果从Dolphin无法用WPS打开PDF等文件，启动器中无法启动WPS文档、WPS表格等，可能是WPS默认的整合模式导致的，可以进入WPS的 设置\其他\切换窗口管理模式 改成多组件模式，即可解决问题；其后也可以再改回整合模式。前面的朋友的方法很有效。

Yrd commented on 2025-12-30 04:20 (UTC)

命令行，文件夹打不开

claude code 找到的方案

把 Exec=/usr/bin/wps %U 改成了 Exec=/usr/lib/office6/wpsoffice /prometheus %U

从 WPS 自己的启动脚本里看到的。之前我读取了 /usr/bin/wps，第 128-129 行：

elif [ 1 -eq ${gIsFushion} ] && [ "$1" != "/prometheus" ]; then { unset GIO_LAUNCHED_DESKTOP_FILE && ${gInstallPath}/office6/${gApp} /prometheus ${gOptExt} ${gOpt} "$@"; } > /dev/null 2>&1

/prometheus 是 WPS 的融合模式（Fusion Mode）启动参数：

  • WPS 新版本有一个"融合模式"，把文字、表格、演示整合到一个统一界面
  • 当配置文件中 AppComponentMode=prome_fushion 时，脚本会自动加上 /prometheus 参数
  • 但问题是：从 Dolphin 双击打开文件时，走的是另一个代码分支（第 131 行），没有加这个参数

你的 WPS 可能默认启用了融合模式，但启动脚本的逻辑有 bug —— 只有在特定条件下才会加 /prometheus，而从文件管理器打开时条件不满足。

1 2 3 4 5 6 .. 23 Next › Last »