2025-05-07 00:00:00

左侧栏，右键选择Feeds->Organize Feeds

在Import OPML的左侧，点击这个不起眼的箭头

可以下载了。

2025-05-06 00:00:00

最近在执行一个用于计算月度时间统计的脚本时，遇到了一个有趣的错误。这个脚本本应计算当月已经过去的小时数，但在每月的8日和9日却会神秘地失败。错误信息十分具有误导性，让人一时难以找到问题所在：

./tmp.sh: line 20: 08: value too great for base (error token is "08")
(standard_in) 1: syntax error
(standard_in) 1: syntax error

问题代码

出错的脚本片段如下：

timecheck=$(date "+%Y-%m-%d_%H:%M:%S")

# 固定使用30天720小时计算
month_days=30
total_hours=720

# 获取当前日期、小时和分钟
current_day=$(date +%d)
current_hour=$(date +%H)
current_minute=$(date +%M)

# 计算已过去的小时数（当前日的小时 + 已过去的天数*24）
hours_passed=$(( (current_day - 1) * 24 + current_hour ))

错误发生在第20行，也就是计算hours_passed的那一行。

问题原因

这个问题看似简单的计算为何会出错？原因在于Shell中数字解析的一个隐藏陷阱：在Bash等Shell环境中，以0开头的数字默认会被解析为八进制（base-8）数字。

在八进制系统中，只允许使用0-7这八个数字。而在每月的8日和9日，date +%d命令返回的是”08”和”09”，这在八进制中是非法的，因此导致了”value too great for base”的错误。

这是一个典型的Shell编程陷阱，特别容易在处理日期和时间时遇到，因为日期和时间格式通常会包含前导零。

解决方案

针对这个问题，有两种有效的解决方案：

方案1：使用无前导零的日期格式

# 获取不带前导零的日期和时间
current_day=$(date +%-d)
current_hour=$(date +%-H)
current_minute=$(date +%-M)

通过在格式说明符前添加-符号（如%-d而不是%d），可以让date命令返回没有前导零的数字，从而避免八进制解析的问题。

方案2：强制使用十进制解析

如果你的系统不支持无前导零的日期格式（例如某些macOS版本），可以使用以下方法强制以十进制解析：

# 明确指定使用十进制解析
current_day=$((10#$(date +%d)))
current_hour=$((10#$(date +%H)))
current_minute=$((10#$(date +%M)))

通过添加10#前缀，我们明确告诉Shell使用十进制（base-10）来解析这些数字，无论它们是否有前导零。

2025-05-03 00:00:00

最近在尝试用 Selenium 复用本地 Chrome 浏览器的登录状态时，遇到了 Profile 路径的问题。记录一下 macOS 下快速定位 Chrome 用户 Profile 的方法。

什么是 Chrome 的 Profile？

Chrome 的 Profile 是浏览器用户数据的隔离单元，每个 Profile 独立保存书签、密码、扩展程序等信息。默认情况下，Chrome 会创建名为 Default 的主 Profile，你也可以手动添加多个 Profile（如 Profile 1、Profile 2）。

在自动化测试中，通过 --user-data-dir 参数加载已有 Profile，可保留 Cookie 和密码自动填充功能。

查看当前 Profile 的路径

1. 打开 Chrome 地址栏，输入 chrome://version 并回车。

2. 在页面中找到 “Profile Path” 字段，显示的路径类似：

    /Users/你的用户名/Library/Application Support/Google/Chrome/Default
   

   这里的 Default 文件夹即为当前用户的 Profile 数据目录 。在父目录下，会看到多个文件夹，如 Default、Profile 1 等，每个文件夹对应一个 Profile 。

快速启动

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=/Users/kelu/Library/Application\ Support/Google/Chrome --profile-directory=Profile\ 1

2025-05-02 00:00:00

最近在使用 conda 管理 Python 环境时，遇到了一个诡异的问题：明明已通过 conda activate 切换到目标环境，但运行 python --version 时版本仍显示 Homebrew 安装的 3.13.1，而非 conda 环境中指定的 3.11.x。经过一番折腾，最终确认是 PATH 路径冲突 导致的。

问题现象

激活 conda 环境后，系统仍优先调用了 Homebrew 的 Python。

原因分析

1. Python 别名干扰

通过 which python 发现，python 命令被别名指向了 Homebrew 的路径 /opt/homebrew/bin/python3。这种别名会直接覆盖 conda 环境的路径优先级，导致环境切换失效 。

2. PATH 路径顺序问题

conda 环境依赖 PATH 环境变量的优先级。正常情况下，激活环境后，conda 会将当前环境的 bin 目录（如 /opt/anaconda3/envs/pandas/bin）添加到 PATH 的最前面。但如果 Homebrew 的路径（/opt/homebrew/bin）在此之上，系统仍会优先调用全局安装的 Python 。

解决方案

步骤 1：移除 Python 别名

检查并删除 ~/.zshrc 或 ~/.bash_profile 中的 Python 别名配置：

unalias python  # 临时移除当前会话的别名  

若希望永久生效，需手动编辑配置文件，删除类似 alias python='/opt/homebrew/bin/python3' 的行 。

步骤 2：调整 PATH 顺序

确保 conda 环境路径在 Homebrew 之前。编辑 ~/.zshrc，添加以下内容：

# 优先加载 conda 环境路径  
export PATH="/opt/anaconda3/envs/pandas/bin:$PATH"  

保存后运行 source ~/.zshrc 使配置生效 。

步骤 3：验证 conda 初始化

运行 conda init zsh 确保 conda 能正确管理 shell 环境变量。检查 ~/.zshrc 是否包含 conda 的自动加载脚本：

# >>> conda initialize >>>  
__conda_setup="$('/opt/anaconda3/bin/conda' 'shell.zsh' 'hook' 2>/dev/null)"  
eval "$__conda_setup"  
# <<< conda initialize <<<  

若未初始化，conda 无法动态调整 PATH 。

验证结果

完成上述步骤后，重新激活环境并检查 Python 版本：

conda activate pandas  
which python  # 应显示 conda 环境路径，如 /opt/anaconda3/envs/pandas/bin/python  
python --version  # 应显示 Python 3.11.x  

总结

此次问题的核心是 环境变量冲突。通过清理别名、调整 PATH 顺序并确保 conda 正确初始化，即可解决版本切换失败的问题。

2025-05-01 00:00:00

Colima是一个免费的开源容器运行时，它使用QEMU在虚拟机中运行Docker容器。它是由Lima Project创建的，Lima项目是一群致力于创建工具以方便在 macOS上运行容器化应用程序的开发人员。

Lima (Linux virtual machines (on macOS, in most cases)) 项目由一群MacBook开发人员用户于2019年启动，出于对macOS缺乏良好的容器运行时和工具的不满而DIY。当时，在 macOS 上运行Docker容器的唯一选择是适用于macOS的Docker Desktop，它需要大中型公司的许可证。Lima项目着手为macOS创建 Docker Desktop的免费开源替代方案，以提供更好的性能和更多功能。

Colima的主要特点包括：

• 支持多种芯片架构 - 完美支持搭载Intel和Apple Silicon芯片的Mac设备，以及Linux系统

• 简单的命令行界面 - 提供直观的CLI操作方式，并采用合理的默认配置

• 自动端口转发 - 智能处理容器端口映射，简化网络配置

• 卷挂载支持 - 支持在容器和主机之间共享文件系统

• 多实例管理 - 可以同时运行多个独立的Colima实例

• 灵活的运行时选择

  - 支持多种容器运行时：

  • Docker（可选择性集成Kubernetes）
  • Containerd（可选择性集成Kubernetes）
  • Incus（支持容器和虚拟机）

在底层实现上，Colima 通过 Lima 启动一个专用的Linux虚拟机来运行容器。

一、安装

brew install colima
brew install docker
brew install docker-compose

注意不要使用brew install docker --cask命令，我们不需要安装图形化界面。

二、启动

colima start --foreground  # 前台运行
brew service start colima  # 后台运行
docker ps -a # 可以执行docker命令了

奇怪的是我没办法后台运行，先跳过了（反正前台能运行）：

Bootstrap failed: 5: Input/output error
Try re-running the command as root for richer errors.
Error: Failure while executing; `/bin/launchctl bootstrap gui/501 /Users/kelu/Library/LaunchAgents/homebrew.mxcl.colima.plist` exited with 5.

三、停止/删除

停止 Docker 只需要停止 Colima 虚拟机即可：

colima stop # 停止虚拟机
colima start # 启动虚拟机
colima delete # 清理colima，删除虚拟机

四、配置

查看配置：

colima list # 运行的虚拟机

colima template

将会打开自定义的配置文件~/.colima/_templates/default.yaml：

主要包含以下配置项：

五、进阶：运行x86的容器

清理已有的colima

colima stop # 停止虚拟机
colima delete # 清理colima，删除虚拟机

安装qemu

brew install qemu

运行虚拟机

colima start --profile rosetta --cpu 2 --memory 2 --disk 100 --arch x86_64 --vm-type=vz --vz-rosetta --mount-type virtiofs

x86_64容器运行

version:  '3.5'

volumes:
  pgdata: {}
  pgdump: {}

services:
  pgsql:
    image: kelvinblood/pgsql:v9.4-alpine
    restart: always
    network_mode: bridge
    container_name: pgsql
    volumes:
      - pgdata:/var/lib/postgresql/data:rw
      - pgdump:/var/lib/postgresql/dump:rw

参考资料

• Colimaでvz+RosettaのVMでx86用Dockerコンテナを実行する場合にはarchにaarch64を指定する
• 告别Docker Desktop：用Colima在macOS上优雅运行Docker容器

2025-04-30 00:00:00

之前发过了这篇《如何在 tmux 中 kill 掉一个 windows？》，我自定义2个常用的命令：

我解绑了 & z m 和 backspace 键，然后将他们重新分配：

1. M : 最大化panel和恢复(原本是z)
2. bspace： 删除窗口

另外还有一个特别常用的快捷键： ], 可以在当前panel下用键盘上下滚动。

unbind-key &
unbind-key z
unbind-key m
unbind-key bspace
bind-key bspace kill-window
bind-key m resize-pane -Z

然后重新加载：

tmux source-file ~/.tmux.conf