Tag: linux

6 notes found.

2026-02-01

/usr/bin/env 的作用与用法

/usr/bin/env 是 Unix/Linux 系统中用于查找并运行程序的工具，主要用于 Shebang 中以提高脚本可移植性。

核心作用与用法

核心作用：提高脚本的可移植性

1. 硬编码路径（不推荐）

#!/usr/bin/python3 - 直接指定路径，跨系统兼容性差。

2. 使用 env（推荐）

#!/usr/bin/env python3 - 在 $PATH 中搜索，兼容性极佳。

工作流程

内核读取 Shebang，运行 env
env 查看 $PATH 环境变量
按顺序搜索 python3
找到后启动该程序

对比表

特性	直接路径	使用 `env`
可移植性	差	极佳
虚拟环境支持	不支持	完美支持
灵活性	低	高

进阶技巧：临时设置环境变量

# 临时设置语言
env LANG=en_US.UTF-8 check_system_status

# 查看所有环境变量
env

注意事项

env 不支持传递多个参数，如 #!/usr/bin/env python3 -u 在旧系统上可能失效。

#linux #shell #unix

2026-01-12

git 下处理换行问题

配置方法

在所有的 git 全局配置中，配置：

# Configure Git to ensure line endings in files you checkout are correct for macOS
git config --global core.autocrlf input

或者在对应的 ~/.gitconfig 中配置：

[core]
	autocrlf = input

但是 github 推荐在 windows 中将这个选项设置为 true，我查了下觉得在三端均采用 input 是非常合理的。

配置说明

配置值	含义
true	双向转换： • 输入（commit）时：CRLF → LF • 输出（checkout）时：LF → CRLF
input	仅输入时转换： • 输入（commit）时：CRLF → LF • 输出（checkout）时：不做转换（保留 LF）
false	完全不转换

参考链接：https://docs.github.com/en/get-started/git-basics/configuring-git-to-handle-line-endings?platform=linux

#git #linux #macos #windows

2026-01-01

终端的输出自带换行

根据 POSIX 标准：文本行必须以换行符结尾。这意味着 rbw get xxx 的时候，实际上屏幕输出的是带有空格的。但是为什么 export a = $(rbw get xxx) 不会存在问题呢？因为 ${} (命令替换|Command Substitution) 会去掉尾部的换行。

参考链接：

#linux #posix #rbw #terminal

2025-12-24

kitty 下使用 fcitx5 的问题

kitty 默认不支持 Fcitx 的输入，但是在 fctix5 下可以通过使用命令 GLFW_IM_MODULE=ibus kitty 启用的 kitty 来输入中文。

链接：https://github.com/kovidgoyal/kitty/issues/5549#issuecomment-1264867941

#fcitx5 #kitty #linux #terminal #输入法

2025-12-12

获取终端命令运行的平均时间

使用 hyperfine 来运行，参考：https://github.com/chinanf-boy/hyperfine-zh#%E7%94%A8%E6%B3%95

比如：hyperfine 'sleep 0.3', 运行结果如下

[nix-shell:~/ghq/github.com/zhaochunqi/til]$ hyperfine 'sleep 0.3'
Benchmark 1: sleep 0.3
  Time (mean ± σ):     319.5 ms ±   4.8 ms    [User: 6.8 ms, System: 3.8 ms]
  Range (min … max):   311.0 ms … 326.1 ms    10 runs

#cli #hyperfine #linux #terminal

2025-10-05

linux 中寻找 docker 中运行的进程

vps 内存爆炸了，上来查原因，使用 bottom 查看之后发现是 uwsgi 进程占用高内存，但我印象中我是我没有部署类似的服务的，因为我基本都是使用 docker 来部署的。

通过 cgroup 信息定位问题

Linux 通过 cgroup 来管理容器资源，每个进程都会记录自己属于哪个 cgroup。我们可以利用这一点来找到它所属的容器。

找到 uwsgi 进程的 PID (Process ID)
```
pidof uwsgi
```
这个命令会返回一个或多个数字，就是 uwsgi 的进程 ID。我们假设返回的是 12345。
查看该 PID 的 cgroup 信息
```
cat /proc/12345/cgroup
```
在输出中，你会看到类似下面这样的行：
```
11:perf_event:/docker/a1b2c3d4e5f6...
10:cpuset:/docker/a1b2c3d4e5f6...
...
1:name=systemd:/docker/a1b2c3d4e5f6...
```
注意 /docker/ 后面那串以 a1b2c3d4e5f6 开头的字符串，这就是容器的完整 ID。
根据容器 ID 找到容器名
```
docker inspect a1b2c3d4e5f6 | grep "Name"
```
或者更简单地，列出所有容器，手动找到这个 ID：
```
docker ps
```
在 CONTAINER ID 列中找到对应的 ID，它旁边的 NAMES 列就是你容器的名字，例如 my-web-app。

小技巧： 你可以组合成一条命令，一步到位： cat /proc/$(pidof uwsgi)/cgroup | grep -o '[0-9a-f]\{64\}' | xargs -I {} docker inspect {} | grep "Name"

#docker #linux