hmgle's blog

tmux 环境变量陷阱

Sun, 06 Jul 2025 11:36:08 +0000

核心摘要：tmux server 启动时会把当时的环境复制到自己的全局环境，并在创建新窗口（pane）时，把这份快照与会话环境合并后交给新进程。即便新 pane 内的 zsh 会重新加载 .zshrc，那些早已被 tmux 快照的变量仍然会存在，因此仅仅删除 .zshrc 里的 export 并不会让旧值消失。

最近在切换 Gemini CLI 认证方式时遇到了一个诡异问题：本来在 .zshrc 中设置了 export GEMINI_API_KEY="xxxxx"，运行 tmux 后，想改用 Google OAuth 认证就把这行注释掉了。结果重新开 tmux pane 时，这个环境变量居然还在！而且确认过 .zshrc 已经重新加载，说明问题出在 tmux 自己的环境上。

问题现象

# 外部 shell（正常）
$ source ~/.zshrc && printenv GEMINI_API_KEY  # 无输出

# tmux 内部（异常）
$ tmux new-window \; send-keys 'printenv GEMINI_API_KEY' Enter  # 输出：sk-xxxxxxxxxx

根本原理

Tmux 使用双层环境模型：

层级	生命周期	更新机制
全局环境	`tmux server` 进程周期	仅启动时从父进程继承
会话环境	单个会话周期	可运行时修改

关键问题：tmux server 启动时会把父进程的环境完整复制到自己的全局环境里；每个会话也会再维护一份会话环境。创建新 pane 时，tmux 会先把“server 全局环境 + 会话环境”合并后作为初始环境传给即将启动的 shell，随后 shell 才去读取 .zshrc。因此即便 .zshrc 里已经删除了某个 export，tmux 仍会把旧变量塞回去，新 shell 看到的就是包含旧值的环境。

解决方案

快速清理

# 步骤一：从 tmux server 的全局环境中移除变量，影响未来所有新窗口
tmux set-environment -gu GEMINI_API_KEY

# 步骤二：清理当前 pane 的 shell 变量，立即生效
unset GEMINI_API_KEY

可选：通过 tmux show-environment -g GEMINI_API_KEY 确认变量已被移除，正常情况下会提示 unknown variable。

彻底重置

tmux kill-server    # 重启 tmux server
tmux new-session    # 启动新会话

类似问题：PATH 重复污染

同样的机制还会导致另一个常见问题 - PATH 变量重复：

# 外部 shell PATH（正常）
/usr/local/bin:/usr/bin:/bin...

# tmux 内部 PATH（重复污染）
/usr/local/bin:/usr/bin:/bin.../usr/local/bin:/usr/bin:/bin...

这是因为每次在 tmux 内启动新 shell 时，会在已污染的 PATH 基础上重新执行 .zshrc 中的追加操作。

解决方法：

# 在当前 pane 去重 PATH，并把干净的值同步回 tmux server
clean_path=$(printenv PATH | tr ':' '\n' | awk '!seen[$0]++' | tr '\n' ':' | sed "s/:$//")
export PATH="$clean_path"
tmux set-environment -g PATH "$PATH"
exec zsh

# 在 ~/.zshrc 中彻底防止重复（zsh）
typeset -U path PATH

预防配置

在 ~/.tmux.conf 中配置环境同步时，记得追加而非覆盖默认列表：

# 例：让 tmux 在新的客户端连接时同步最新的 GEMINI_API_KEY
set-option -ga update-environment "GEMINI_API_KEY"

update-environment 只会在新的客户端或会话附着时刷新列出的变量，因此重新连接前要先在外部 shell 设置好目标值；否则旧值会继续保留在 tmux 的环境里。

总结

tmux server 环境是“一次性快照”：server 启动时的环境会被复制并沿用到所有 pane 的初始环境里。
Shell 配置只能叠加，无法回收旧值：新 pane 会重新加载 .zshrc，但 tmux 会在此之前注入旧的变量，因此仅靠修改配置无法清除它们。
警惕敏感信息残留：残留的 API Key 或 Token 可能在无意中泄露。
PATH 等变量易被污染：重复追加 PATH 会拖慢命令查找，应在配置中做去重处理。

理解 tmux 的”环境冻存”机制，能帮我们避免很多意外的环境变量问题。

参考资料：

解开 tmux 在不同终端下颜色差异之谜

Sun, 12 May 2024 15:23:28 +0000

缘起

最近我升级了一台 macOS 下的 iTerm2 终端模拟器（在不引起歧义的情况下，下文简称为终端），从版本 3.2 升级到版本 3.4。我的主要工作方式是 tmux + Neovim，按往常一样运行 tmux 并打开 nvim，我觉察到 nvim 的颜色变了，背景色比之前的暗了许多。我使用的这套 gruvbox-material 配色主题是支持多种不同的亮度背景色的，把背景模式由原来的 ‘medium’ 改为最亮的 ‘hard’，颜色看起来很好了，于是我把 nvim 颜色配置修改后推送到 git 仓库。

我的主要工作机还是另一台 Linux 主机，终端用的是 GNOME Terminal。在上面拉取完 nvim 的配置后，我又发现新的 ‘hard’ 颜色在 tmux 上观感非常差，和在 iTerm2 上显示的颜色差别也很大。而在 iTerm2 未升级之前，使用同样的 nvim 配色，两个终端显示出来的颜色是一致的。

问题来了：为什么同样的配置，升级 iTerm2 后 tmux 的颜色发生了变化？

断疑

前置知识

首先需要梳理一下，在终端运行 tmux，又在 tmux 打开 Neovim，Neovim 的颜色信息是如何发送到终端的：大致的过程是 Neovim 的输出会经过 tmux 捕获处理，然后 tmux 再把处理后的内容输出给终端。

这些颜色信息在终端是使用 ANSI 转义序列（ANSI escape code）来表示的。

一般的现代 vim 配色主题会有两套颜色方案：256 色的 “cterm” 以及 24 位 RGB 格式的 “gui”，vim 默认是选择其中的 “cterm” 方案，~~除非是开启了 ‘termguicolors’ 属性~~刚看到 Nvim v0.10 新特性：它能自动检测终端模拟器是否支持 24 颜色了。我的 Neovim 配置是开启了 ‘termguicolors’，所以它输出给 tmux 的是 RGB 颜色格式的 ANSI 转义序列。

tmux 对输入的这些 ANSI 转义序列并不会直接发给终端，而是根据推断出来的终端是否具备 24 位颜色渲染特性，再决定是否把这些 RGB 颜色转换为 256 色。如果 tmux 推断出终端只能渲染 256 色，那么它输出给终端的颜色信息就是经过转换后的 256 色。

有了上面的知识储备之后，就可以猜测上面终端在同样的配置下渲染出不同的颜色很可能是因为 tmux 推断终端的渲染能力不准确导致了 RGB 颜色被转换为 256 色输出给终端。

可以这样验证 tmux 识别的终端是否具备 24 位颜色渲染能力：使用 tmux -vvv 生成 tmux server 的启动日志，过滤最后一条 “RGBCOLOURS flag” 日志内容，看结果为 0 还是 1。或者执行 tmux info | grep -i rgb 观察结果，有 RGB 标志位或者有 setrgbb 与 setrgbf 字符串（这两个字符串代表了用 RGB 参数设置背景和前景色的能力）即表明 tmux 在 24 位色模式下运行。

经验证，新版（3.4）的 iTerm2 正确识别出 RGBCOLOURS flag 为 1，而旧版（3.2）iTerm2 及 GNOME Terminal 识别出的 RGBCOLOURS flag 为 0。也就是说，我之前使用的是 256 色模式的 tmux！尽管我的这些终端都支持 24 位 RGB 颜色。

配置的错误

我检查了下我的 tmux 配置：

set -as terminal-features ",gnome*:RGB"

想起了当时是看到了 tmux 官方文档的How do I use RGB colour?，直接拷贝过来的：

-set -g default-terminal "xterm"
-set -ga terminal-overrides ",*256col*:Tc"
+set -g default-terminal "xterm-256color"
+set -as terminal-features ",gnome*:RGB"

现在明白了，这句配置的意思是只有环境变量 $TERM 匹配上了 gnome* 这个正则表达式时 tmux 才会为该添加 RGB 特性，而我的终端的$TERM 环境变量是 “xterm-256color”，当然就匹配不上这条规则了。需要根据具体的 $TERM 来修改这条规则，把上面的 “gnome” 改为 “xterm” 就能匹配上了：

-set -as terminal-features ",gnome*:RGB"
+set -as terminal-features ",xterm*:RGB"

或者重新添加之前删掉的 set -ga terminal-overrides ",xterm-256color:Tc"，修改完配置重新加载后，tmux 在 GNOME Terminal 上也和新版的 iTerm2 一样变成 24 位 RGB 模式了，肉眼可见 tmux 上的色彩和不运行 tmux 的 GNOME Terminal 终端上一样。

为什么新版 iTerm2 可以无视配置规则而被 tmux 加上 RGB 颜色特性呢？

浏览 tmux 代码发现，tmux 会为部分终端添加一些特性：

void
tty_default_features(int *feat, const char *name, u_int version)
{
	static struct {
		const char	*name;
		u_int		 version;
		const char	*features;
	} table[] = {
#define TTY_FEATURES_BASE_MODERN_XTERM \
	"256,RGB,bpaste,clipboard,mouse,strikethrough,title"
                ...
		{ .name = "iTerm2",
		  .features = TTY_FEATURES_BASE_MODERN_XTERM
			      ",cstyle,extkeys,margins,usstyle,sync,osc7"
		},
                ...
	};
        ...
}
...
/* Add terminal features. */
tty_default_features(&c->term_features, "iTerm2", 0);
...

只要识别出是 iTerm2，tmux 就会添加 RGB 颜色特性。问题的关键是 tmux 如何识别出新版 iTerm2 的 APP 名称的？原来 tmux 会向终端发送一个扩展的获取终端信息 ANSI 转移序列 CSI > q，支持这个 CSI > q 查询的终端会返回自己的 APP 名称和版本号，这也是 3.4 版本的 iTerm2 添加的功能：Extended Device Attributes，而我之前用的 3.2 版本并不会响应这个查询，因此也无法在 tmux 自动开启 RGB 颜色特性了。

让运行在终端的程序识别出终端的名称和版本号并不是一件简单的事情，如果终端都能支持这个 CSI > q 查询当然是最好的了，但很多老牌的或者旧版本的终端都是不支持这个扩展的 ANSI 转义序列查询的。可以这样验证：在终端运行 printf "\x1B[>q" 看会不会打印出 APP 名称和版本号。

获取终端特性的另一种手段：terminfo

后来我又尝试了在另一个终端 kitty 上运行 tmux，出现了一个有趣的现象：即使不为 tmux 配置任何的 RGB 特性（即默认的 tmux 配置，不添加 terminal-overrides 或 terminal-features RGB 特性）通过 brew 安装的 tmux，可以自动为 Kitty 开启 RGB 色彩特性，而我自己编译出来的 tmux，却无法自动开启这个特性。

再一次的探索发现了背后的原因：tmux 会通过 setupterm() 和 tigetstr() 等函数查询 terminfo 来获取终端的特性，如果查询出来的 terminfo 数据包含了 “setrgbb” 和 “setrgbf”，则为该终端开启 RGB 特性。关键代码如下：

	/* Update the RGB flag if the terminal has RGB colours. */
	if (tty_term_has(term, TTYC_SETRGBF) &&
	    tty_term_has(term, TTYC_SETRGBB))
		term->flags |= TERM_RGBCOLOURS;
	else
		term->flags &= ~TERM_RGBCOLOURS;
	log_debug("RGBCOLOURS flag is %d", !!(term->flags & TERM_RGBCOLOURS));

kitty 和其他终端不一样的是，它维护了自己的 terminfo 数据，默认配置下的 kitty 启动时会设置环境变量 “$TERM” 为 “xterm-kitty”，”$TERMINFO” 被设置为 kitty terminfo 数据的目录。它自己的 terminfo 包含了一些 kitty 特有的特性，其中就包括了 “setrgbb” 和 “setrgbf”。tmux 正是根据这些信息确定了当前的终端可以开启 RGB 特性。

为啥我自己编译的 tmux 不能把 “setrgbb” 和 “setrgbf” 查询出来呢？

用 otool -L （相当于 Linux 的 ldd 命令）对比我自己编译的 tmux 和 brew 安装的 tmux 差异可以看出，它们链接的库不一样：

$ otool -L /usr/local/Cellar/tmux/3.4_1/bin/tmux
        ...
        /usr/local/opt/ncurses/lib/libncursesw.6.dylib (compatibility version 6.0.0, current version 6.0.0)
        ...
$ otool -L 自己编译的tmux/tmux
        ...
        /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
        ...

tmux 里面查询 terminfo 的setupterm() 和 tigetstr() 函数正是链接到上面的库的，这个版本的 libncurses 会直接忽略 “setrgbb” 和 “setrgbf”。从搜索的结果来看，老版本的 ncurses 的开发者似乎对这两个非传统的变量不太感冒：Support 24-bit terminals、一些用户的评论。通过 brew 安装的 tmux 是依赖 libncursesw 的，它可以返回这两个变量的字符串值。

另外，kitty 这种使用自己的 terminfo 数据的方式的确可以为外部程序提供更多的关于自己特性的信息，但也并非完美。比如：我在 kitty 上 ssh 一台 Linux 主机后，再运行 tmux 时就报错了：”missing or unsuitable terminal: xterm-kitty”，这是因为 ssh 会直接继承之前的 TERM=xterm-kitty 的环境变量，在远程主机运行 tmux 查询 $TERM 的 terminfo 时，远程主机是没有安装 kitty 的，所以会缺失 xterm-kitty 的相关信息。这里有关于 kitty 这部分的相关讨论：

结语

要准确地判断出各色各样的终端模拟器的色彩特性并非是一件简单的事情，需要兼容不同标准，还要兼顾许多历史遗留问题。这也正是 tmux 提供了给用户配置 terminal-features 和 terminal-overrides 的原因。也许，可以像 CSI > q 这样，增加 ANSI 转移序列用来查询终端特性，让终端自己回答。

gopls 魔改笔记

Sun, 08 Sep 2019 16:46:10 +0000

gopls 作为一个符合 LSP 代码语言通信协议的 Go 语言部分实现，正在被越来越多的编辑器集成进来。vim 目前也有多款插件支持 gopls 了，比如常用的 vim-go、YouCompleteMe、vim-lsp 等。

我在使用 gopls 过程中观察到一个现象：上述的每一个插件，在 vim 启动的时候，都会各自启动一个 gopls 进程。如果打开多个 vim，就会启动多个 gopls。如果你同时使用 vim-go 和 YouCompleteMe 插件， gopls 进程启动的数量还会再翻一倍。gopls 本身是个占用资源不少的东西，对我这种机器性能还没达到过剩的电脑来说，能减少浪费还是有必要的。

放狗搜了一下相关 issue，发现还没什么讨论，插件启动各自的的 gopls 再通过 STDIO 通信目前是简单、标准的做法。看了下 gopls 的用法，它是支持 TCP 服务模式的。那在外部启动一个 gopls 服务，每个插件都使用 ch_open() 方式连接到这个服务就可以啦。但是对插件来说变动就大了，还可能引入新问题。因此，暂时不太可能有插件会启用这个节约性能的特性。

不改变插件代码的情况下，目前只能通过魔改 gopls 的方式来做，用 netcat 或 socat 作连接 TCP 服务的客户端，毕竟它们比 gopls 占用资源少太多太多了：

重命名 gopls，为了让插件丧失启动 gopls 的能力：
```
 mv $GOPATH/bin/gopls{,-server}
```
如果使用了 YouCompleteMe，它会启动它自己路径下第三方依赖里面的 gopls，也需要把它重命名：
```
 mv your_YouCompleteMe_DIR/third_party/ycmd/third_party/\
   go/src/golang.org/x/tools/cmd/gopls/gopls{,.bak}
```

创建一个名字为 gopls 的脚本，它仅仅是供这些插件使用的客户端：

 echo '#!/bin/sh
    
 nc localhost 9877 # or socat - tcp:localhost:9877' > $GOPATH/bin/gopls
 chmod a+x $GOPATH/bin/gopls
 cp $GOPATH/bin/gopls your_YouCompleteMe_DIR/third_party/ycmd/third_party/\
   go/src/golang.org/x/tools/cmd/gopls/gopls

启动 TCP 服务模式的 gopls，可以把它加入到开机启动，省的手动启动：

 # gopls-server 就是上面重命名后的 gopls
 gopls-server serve -listen "localhost:9877" -logfile /tmp/gopls_$RANDOM.log

之后无论打开多少个编辑器，无论打开多少 go 文件，都只有一个 gopls-server 在运行了。

上面这个方法不仅仅是对于 vim 的，其他编辑器存在启动多个 gopls 的情况一样可以通过这种方式解决。 不过，如果不在乎多给 gopls 占用一些资源的话，还是不要随便魔改，老老实实按原来方式使用就可以了。

下次升级 gopls 后，魔改版的会被覆盖掉。

在使用过程中发现一个问题，如果使用了 YouCompleteMe，每次退出 vim 后，会发送 exit 通知给 gopls-server 服务，导致 gopls-server 退出。跟踪了一下，发现是 ycmd 导致，直接把发送退出通知的代码注释掉了:

def Exit():
  # return BuildNotification( 'exit', None )
  pass

另一个 YouCompleteMe 的竞争者 vim-lsp 也提供了自动补全的功能，也不会出现发送 exit 通知的问题，但使用中发现它和 gopls-server 交互太频繁了，只要是光标的位置变动，都会和 gopls 进行消息通信。而 YouCompleteMe 只有在插入模式时才会请求服务。希望 vim-lsp 后期可以得到改进。

2020-04-18 更新:

现在 gopls 已经支持多个客户端与一个服务端后台进程进行通讯共享数据了，只要启动 gopls 时增加 “-remote=auto” 即可。现在 vim-go 和 YouCompleteMe 都已经支持添加额外的 gopls 参数了。可以更新最新版的 vim-go 和 YouCompleteMe，在 vimrc 添加下面的配置就可以尝鲜了：

" vim-go conf
let g:go_gopls_options = ['-remote=auto']

" ycmd conf
let g:ycm_gopls_args = ['-remote=auto']

未来也许它们会成为默认的配置，那样的话就不需要再手动添加了。

可以阅读下面的链接了解为了支持这个特性背后的故事：

tmux 分享内网终端

Mon, 30 Apr 2018 11:20:20 +0000

tmux 有个共享会话的功能，利用这个功能可以解决多人协作场景中终端分享问题：比如结对编程、远程协助、直播写代码……

在一台服务器上直接共享服务器上的 tmux 会话的例子已经有很多了，实际操作可以参考使用 tmux 结对编程、 Remote Pair Programming Made Easy with SSH and tmux。

如果要分享 NAT 内部的机器终端给不同 NAT 背后的电脑操作或者观看，可以实现吗？考虑到一位来自远古时期的开发者 Alice，她只在终端上开发，突然一天要转行做网红程序员了，就可能会有直播写代码的需求，而且她希望操作的是自己本地电脑的开发环境终端，直播分享给遍布全世界的拥趸观看。这时上面介绍的分享公网服务器上 tmux 会话的操作就行不通了。

我对这类位于不同 NAT 内部的机器共享终端的问题想了下，发现结合 tmux 和反向 shell 是可以解决的，再对期间可能出现的权限问题进行分析，利用在跳板机新增一个中间用户及 tmux 的只读模式的方法，可以实现分享出去的终端对其余用户只能观看，无法获取写的操作权限，从而保证分享者主机的安全。

首先，简单说下一些常用的反向 shell 的方法，它是分享 NAT 内网终端的前提。

反向 shell

假设跳板机服务器地址为 ServerIP, Alice 的内网机器地址为 AliceIP, 要实现的是在服务器控制 Alice 的终端，思路就是在服务器运行一个终端，并监听一个 TCP 端口，它的标准输入重定向之后建立的 TCP 连接；Alice 的机器也运行一个终端，并连接服务器端口，它的标准输入、标准输出、标准出错都重定向到开始时建立的那个 TCP 连接，这样服务器就能获取到 Alice 的 shell 了。

实现方法就很多了，如：

使用 netcat 和 bash

在服务器监听 3333 端口：
```
nc -nl 3333
```
Alice 机器运行：
```
bash -c "bash -i >/dev/tcp/ServerIP/3333 2>&1 <&1"
```
之后服务器就可以操作 Alice 机器了。这种方法很简单原始，但缺点很明显：不支持颜色高亮及格式化输出，不支持触发信号的按键捕获，不是一个合格的 TTY。如果在上面打开 vim 就会得到 “Vim: Warning: Output is not to a terminal”、”Vim: Warning: Input is not from a terminal” 的警告，根本不能用来写代码。

使用 socat

在服务器监听 3333 端口：

socat file:`tty`,raw,echo=0 tcp-listen:3333 

Alice 机器运行：

socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:ServerIP:3333

SSH 反向 shell

Alice 机器运行：
```
ssh -N -R 3333:localhost:22 alice@ServerIP
```
服务器运行：
```
ssh localhost -p 3333
```
ssh 支持反向隧道，安全可靠，但要求 Alice 机器也开启 ssh 服务 sshd。下文将采用这种反向 shell 方式。

借助反向 shell，就可以将 Alice 机器的终端分享出去了：

分享内网终端

Alice 通过反向 shell 控制自己机器：

Alice 机器运行：
```
ssh -N -R 3333:localhost:22 alice@ServerIP
```
然后通过 ssh 方式登录服务器，在服务器上新建一个名为 alice_live_session 的 tmux 会话，并在该会话连接 Alice 内网机器的终端：
```
tmux -S /tmp/alice_socket new -s alice_live_session
ssh localhost -p 3333
```
之后就能在这个 alice_live_session tmux 会话操作自己机器了。
观众 Bob 获取 Alice 共享的 alice_live_session

先介绍一种对 Alice 来说是不安全的共享方式，后面再谈如何解决。
```
# 1. 在服务器为 Bob 用户加入 alice 所在用户组，
# 以获取 tmux 会话 socket 文件 /tmp/alice_socket 的
# 读写权限(连接 tmux 会话必须要有该 socket 文件的读写权限)：
sudo usermod -aG alice bob
# 2. Bob 以 tmux 的只读方式连接 `alice_live_session`, 
# 从而观看 Alice 的实时直播终端：
tmux -S /tmp/alice_socket attach -t alice_live_session -r
```
这里的安全问题是：Bob 选择只读方式完全靠自觉，要是 Bob 不加上只读选项 “-r”，连接时就获得了和 Alice 一样的 shell, 随时可以干扰 Alice 的终端操作，Alice 不终止该会话的话，Bob 可以对 Alice 机器进行任何操作，这只适合于结对编程等多人协作场景。

解决方式是 Alice 在服务端增加一个中间人用户 Carol，Carol 也开启一个新的 socket 方式的 tmux 会话 share_live_session，该 socket 文件对任何用户都可读可写，在这个 share_live_session 会话中，以只读的方式连接 alice_live_session(嵌套的 tmux)，这样任何其他用户都可以连接 share_live_session 间接地观看到一个只读的 alice_live_session，而这些用户对 /tmp/alice_socket 都没有读写权限，无法获取一个对 alice_live_session 可写的权限，从而 Alice 可以放心地直播了。

具体操作如下：
```
# 1. 在服务器增加 carol 用户，并加入 alice 用户组：
sudo adduser carol
sudo usermod -aG alice carol
# 2. 通过 carol 用户新建 tmux 会话：
tmux -S /tmp/carol_socket attach new -s share_live_session
# 3. 给所有用户分配 /tmp/carol_socket 的读写权限：
chmod a+rw /tmp/carol
# 4. 在 `share_live_session` 里以只读方式连接 `alice_live_session`:
tmux -S /tmp/alice_socket attach -t alice_live_session -r
# 5. Bob 连接 `share_live_session`，获取到只读的 `alice_live_session`:
tmux -S /tmp/carol_socket a -t share_live_session -r
```

目前有许多类似的工具专门实现 NAT 背后的终端共享，比如 tmate, teleconsole, Robo-TiTO，其实现有的通用工具也是可以解决的，有时不过是组合起来麻烦一点罢了。想起 David Frank 说过的一句话：现在造轮子的理由不再是「那个轮子不够好」，而是「那个轮子功能太多了」。

Update: 如果还想把终端共享到网页去的话，还可以使用 GoTTY 或 ttyd

# 分享者执行：
gotty tmux new -A -s gotty
tmux new -A -s gotty
# 浏览器打开：
open http://ServerIP:ServerPort/

参考链接:

佩剑

Tue, 30 May 2017 20:21:29 +0000

王鼎钧在回忆录《怒目少年》开头第一篇，标题就引用了郑愁予的诗句：

出门一步，便是江湖。

简练、惜字。纯净单一的原料是容易二次加工的，稍稍糅进武侠的意象，便催生出更具画面感的流行变体：

剑未佩妥，出门已是江湖。

再添三分鸡汤风味，竟能熬出一副流传甚广的对仗：

剑未佩妥，出门已是江湖。千帆历尽，归来仍是少年。

显然出版界对此类文字的市场消费空间有惊人的一致看法，一时间，书店里扎堆出现出大量相似的面孔，至少三部著作共享相似书名：

愿你走出半生，归来仍是少年
 愿你出走半生，归来仍是少年
 愿你出走半生归来仍是少年

作品虽未拜读，却恰逢(巴德尔-迈因霍夫现象)膜法师续一秒撰文鞭挞此类文案，称其为空洞的排比与廉价的煽情。对此，我深以为然。文贵言有尽而意无穷，当“江湖”与“少年”沦为可以无限复制的商业符号时，其内涵早已被稀释。

那么，抛开这些贩卖情怀的商业变体，我们不妨回到“江湖”的本意，看看它在今天意味着什么。

今时江湖不过指尖方寸。无论是主机启动后的虚拟战场，还是手游里的组队开黑；无论是联盟峡谷的激烈厮杀，还是网络论坛的唇枪舌战——我们随时都能踏入一个数字构成的江湖。如今 VR 技术足以乱真，AI 甚至萌发了微茫的意识，感官几难分辨虚实。然而，我仍笃信：虚拟世界的血雨腥风，终究无法与真实生活的尘土飞扬相提并论。《黑客帝国》也好，《源代码》也罢，终究只是建立在缸中之脑上的科幻寓言。你在游戏里提刀能战，未必能应对现实里的饥肠辘辘；在屏幕前勇挫敌酋，或许在市井遭遇小偷时依旧会噤若寒蝉。毕竟，真实的人生没有续命的选项。

这让人想起朱炫在《年少荒唐》里的佩木剑传奇少侠陆少阳。当他面对着九环大刀的劫道，双手奉上靴子里的钱包，丢尽了武林人士的脸。那一刻，他心中的感慨，想必正是那句：

剑未佩妥，出门已是江湖。

几番失败之后，陆少阳终于佩上了精铁打造的真正的剑。宝剑加持下完成了战五渣的逆袭：以一人之力对抗一拨大内高手、阉人甲士，并毫发无损的全身而退。故事虽有夸张，却点明了“利器”的重要性——你的准备，决定了你在江湖中的安身立命。

当然，此剑非彼剑。《道德经》有云：“兵者，不祥之器，不得已而用之，恬淡为上。”现代法治社会，更是对实体刀兵严加管制。我们在此谈论的“剑”，终究是一个喻体。

它真正需要打磨的，是思想的锋利，是技能的精湛，更是在烟火市井里为生活博弈的底气，面对俗世的洪流坦然。这样，当你出门一步，走进市场，才能用便宜的价格买回来一篮子好菜。

杂感

Mon, 04 Apr 2016 20:21:29 +0000

对于不可说的东西我们必须保持沉默。

– 《逻辑哲学论》维特根斯坦

阮一峰最近一条推特的建议是没事多写作。而我逐步形成的认识，是勉强写不如不写。无事乱写，几近差遣之作。王国维说”人能于诗词中不为美刺、投赠之篇，不使隶事之句，不用粉饰之字，则于此道已过半矣。”

一

然而我终于还是勉强地写下此篇。

自入码农界，文学于我，已经是参商之隔。年青人少读文艺作品，一是可以借口于业界普遍的繁重加班，生活都可被剥夺，惶论有暇闲情雅趣品书。–但我除去少部分日子被迫无奈加班之外，出于对生活的热爱，都是早早走人：）二是浮躁的社会造就功利的心态。读书仅为稻粱谋，而且最好速成：21天系列书经久不衰，仅看本行业内容书籍，从不问津文史杂学，大都可归此类。不过以冯友兰的四重境界来说，能从自然境界到功利境界，至少是一种社会进步。

最无奈的是在追求、渴望的道路中，随着时光的流逝，那份对文学、哲学的探索初心，如细沙般一点一点流失…

二

卢克：您年轻时最想做什么，老师？

斯布雷斯：想做法师，哪怕是最撇脚最愚蠢的法师–只要是法师就行了…

– 《塔斯里亚故事集-天赋》

曾经有一段时间，我特别向往做一名数论学家。是的，那种区别于解决实在问题的应用数学而仅仅满足于自洽的理论。那时我大部分时间的工作环境是工厂里的一栋正在施工的底部混凝土上层钢结构的厂房，而我常常夹带着一本闵嗣鹤写的初等数论进场–该书来源于学生时代几毛钱购得的二手书。我是这个繁忙的工地上最无所事事的人，有时随地坐在待安装的钢梁上，翻开书页，无顾周围穿梭的工人、乒乓作响的敲击声、不至于危及我安全的各种吊机、叉车的干扰，徘徊在定理与公式的文字中。很难想象，一个头戴安全帽的工人，翻看的不是现场图纸。（注：建筑业的一个幸运是：一个不具破坏性的懒惰工人，基本不会对建筑的质量有所影响。而你要是遇到一个糊涂的抓药师，就得小心了）

平庸的数学才能很快遭受到数学皇冠上明珠的打击。大约到了原根一章，我明显感到对理论的理解犹如隔了一层膜，这大概是我从未遭遇过的学习障碍无力感。另一方面我意识到此时的年龄已与职业纯数学家无缘了，我还是决定退而求其次，试试报考某院校的密码学，虽是应用，至少还是数论应用的一个分支。后面的故事也说过，最后以弃考为终…

多年以后，当我读到《一句顶一万句》里一心想学唱丧、喜虚不喜实的杨百顺、后来的杨摩西、吴摩西、罗长礼，先后杀猪、挑水、破竹、卖馒头，终无一日正经唱丧，心里想，对于数论，至少在看到一道类似求1000阶乘最右边有多少个连续的0的题目时，区别于大多数试图编程计算的程序员，我一眼就看出这不过是勒让德定理一个简单应用，总算是获得些许欣慰了:)

三

Everything should be made as simple as possible, but not simpler.

事情要尽可能简单，但不要简单过头了。

– 阿尔伯特·爱因斯坦

几天前订了一节箫，全素，不署姓名与诗句。这符合一个极简主义者的作风。不止是箫，就是别的事物，我也养成能省就省的习惯。最近不惜冒着与人生隙之风险运用奥卡姆剃刀将他人两千多行代码删得只剩四五百行:-) (记得令人汗颜的是之前的老师傅只看一眼我写的垃圾代码后，说能把它缩为80%，结果还不到50%呢，令人收益良多)

记得吴清源有次被人问道：“围棋的本质是什么？” 吴沉默许久，答道，围棋的本质是技术，就不再说下去，令人眼镜大跌。今天看来，吴清源其实是一语道破了本质。万物都可往里套的玄学，当然也少不了凑凑围棋的热闹，比如这篇通篇不离周易的文章。而最近的 AlphaGo 机器战胜李世石后，此类解释与说法大打折扣，估计周易的生存之地也将进一步流失，然而我们永远不必为之是否会灭绝而感到担忧，只要还有未知的领域，就少不了玄学为之撩云拨雾。

毕竟，谁能做到，“对于不可说的东西我们必须保持沉默”。

Go 1.5 交叉编译 TCFS-GO

Mon, 21 Sep 2015 20:21:29 +0000

目前 Go 最新版本 1.5 本身就已经支持各个操作系统平台及 CPU 体系的交叉编译，并且支持 cgo 的跨平台编译。搜索出来的关于 Go 交叉编译的博文大部分还是针对老版本的，目前已过时，Go 1.5 无需修改任何东西，只需指定相关的 go env 环境变量即可，具体可以参见这篇博客(墙外)，这里不再赘述。

前段时间用 Go 实现了 TCFS 这个简单的网络文件系统的服务端，于是我想把它移植到我的 Android 手机上，这样就可以借助网络在电脑挂载手机上的文件系统进行读写操作了。

一开始我想到的是使用 go mobile 来作为 Android 界面来运行 TCFS 服务，顺利编译出 APK 后安装到手机上，运行时谁知道因为权限的原因无法监听 TCP 端口，而目前仅仅使用 Go 应该配置不了 APK 的操作权限的。解决办法还得依靠 Android Studio：使用 gomobile bind 编译出 aar 包，里面包含了 so 库文件，界面用 Java 来写，Java 这边可以通过 import aar 包来使用 Go 的函数，权限可以在 manifest 文件配置。

Update: 依照这篇博文 Writing Android apps with Go bindings 的介绍，我也用 Android Studio 编译出了 TCFS 的 Android 版本：

界面还未完善，毕竟是我开发的第一个 Android 应用~ 源码托管在 tcfs-android@GitHub 。需要的同学可以自己编译出来，欢迎 PR 。

我的 TCFS 并不一定需要界面，我就直接编译个没有界面的命令行在 Android 上用了，进入 tcfs-go 路径后，使用下面的命令编译出 Arm 平台的程序：

GOOS=linux GOARCH=arm go build

再把编译出来的 tcfsd 复制到 Android 里面，通过终端模拟器来启动 tcfsd 服务:

在 Linux 这边挂载 Android 的文件系统:

这样就可以像访问本地文件一样访问 Android 里面的文件了。对比 MTP 的挂载方式，TCFS 的主要优点是不需要数据线连接，仅依赖网络连接；支持多台电脑同时挂载；缺点是受限于网络，传输速度比较慢。

这里顺便鄙视一下魅族的手机:-) 这是我使用过的问题最多的手机了，而且我碰到的不是个别问题，通过搜索发现许多人都和我一样碰到过：经常死机就不说了，关键是一死机之后就会无限重启；它的指南针从来就没有准过；以前吹嘘的最窄边框经常在边框发生误触控。。。

搭建微信平台上的 Scheme 解释器服务

Mon, 14 Sep 2015 21:14:47 +0000

我在 Scheme 微信公众号运行了一个 Scheme 解释器服务，可以对用户发送的 Scheme 表达式求值并返回结果:

后台的 Scheme 解释器服务会对每一条微信消息都启动一个全新的初始环境，因此不同用户及不同消息互不干扰。如果要在一个环境里执行多条语句，就要把它们放在同一条微信消息，不能分开发送。比如像上面的：

(define x 3)
(+ x 7)

这个服务非常简单，运行模型如下:

+--------+  req: S-exp   +----------+ msgId + S-exp  +---------+  S-exp   +--------+
| wechat | ------------> | wechat   | -------------> |  Sina   | -------> | Scheme |
| client | <------------ | Platform | <------------- | App Eng | <------- | server |
+--------+ resp: result  +----------+ msgId + result +---------+  result  +--------+

为什么不直接在 SAE 里面运行 scheme server 呢？原因是：

这个 Scheme 是 native 的，SAE 不允许运行；
在我看来，这样的服务方式耦合度很低，扩展性好。假如要加入另一个 Lua 解释器 server，除修改一下服务路由之外，原有代码基本不需改动。

所有代码都已开源：https://github.com/hmgle/wechat-scheme-server

怎么部署呢？

SAE 部分：申请、创建应用等步骤不在话下，如有困难请用搜索引擎搜索关键字SAE 申请创建应用。然后克隆 https://github.com/hmgle/wechat-scheme-server/tree/master/sae 里面的代码到 SAE 代码仓库，修改 weixin.py 里面的 Scheme server 地址为自己运行 Scheme 服务的地址，修改 weixin.py 里面的 token 为自己对应的微信 token，运行后，按照微信平台说明完成与微信的握手认证。
Scheme server 部分：进入 scheme-svr/yascm 目录，按照里面的 README.md 编译。然后执行下面语句:

cd ..
nohup ./bootstrap.sh > /dev/null 2>&1 &

值得说明的两点是：

Scheme server 并没有使用 Nginx 之类的通用服务器，而是用了 netcat 这个工具作为网络服务接口，因此完全不需要配置。为什么会用如此简陋的工具呢？因为这个场景没有大并发的需求，Scheme server 仅有 SAE 这一个客户端连接，使用 netcat 足矣。我倾向于用最简单的方法解决问题:)
并没有使用现有的 Scheme 解释器，而是用我之前实现的一个不满足 r4rs 规范简单的 Scheme 解释器轮子 yascm。这最主要的原因是用一般的 scheme 解释器的话，相当于对用户开放了整个服务器系统，当然这可以通过 chroot 或者 Docker 容器来解决，然而我在 yascm 直接就不实现这类修改服务器系统的功能就简单得多了:) 还有一个原因是一般的解释器计算出结果使用 printf(3) 打印到标准输出后，需将标准输出的内容重定向到一个命名管道供 netcat 读取，由于默认缓存机制，如不使用 fflush(3) 的话，客户端是不能从 netcat 这里马上获得结果的。这可以通过把 yascm 替换为 Racket 或 scheme48 等解释器来试验，我尝试过的只有 scm 这个解释器是调用了 fflush(3) 来强行刷新 IO 的(其实前段时间这个解释器服务就是用的 scm)。

并不想记录用户的历史消息，因此不使用数据库。

要是没有服务器也想在局域网内的电脑运行 Scheme server，可以使用 ngrok, 它通过分配一个公网地址中转请求到局域网可以使任何地方的网络都可以访问局域网内的服务。

闭包的概念

Sun, 12 Jul 2015 20:50:30 +0000

要理解 Scheme 的闭包, 需要先理解求值的环境模型(幸好不是”要理解递归, 你需要先理解递归:D”).

我看到过的对求值环境模型最好的阐述, 还是 SICP 的第 3.2 章, 该书通篇未提 Closure 一词, 然而道理已阐明其中.

现在就用求值环境模型来印证一下闭包的例子:

(define my-counter
   (let ((count 0))
        (lambda ()
           (set! count (+ count 1))
           count)))

(my-counter) ; 返回 1
(my-counter) ; 返回 2
(my-counter) ; 返回 3

my-counter 就是闭包. (my-counter) 是如何求值的呢?

首先是把 my-counter 绑定到一个过程体:

(define my-counter
   (let ((count 0))
        (lambda ()
           (set! count (+ count 1))
           count)))

Scheme 解释器执行上面的代码时, 会求值 (let ...) 那部分, 而求值的后果就是建立一个框架, 对应于下图的 E1, E1 的外围环境为执行时的全局环境 Global E, 环境变成这样:

          +-----------------------+
          |                       |
Global E->|   my-counter          |
          |       |               |
          +-------|---------------+
                  |        ^
                  |        |
                  |    +----------+
                  |    | count: 0 |<--E1
                  |    |__________/
                  |        ^
                  v        |
               (.)-(.)-----+
                |
                v
             P: nil
          body: (set! count (+ counter 1))
                 count

从上图可以看出, my-counter 绑定到一个参数为空的过程体, 这个过程体指向的环境 E1 又绑定了一个 count = 0 的变量.

当第一次执行 (my-counter) 这个闭包时, 从 my-counter 这个过程体第一个框架往上搜索 count 这个变量, 并把它修改为原值加一. 执行完毕后框架图变为:

          +-----------------------+
          |                       |
Global E->|   my-counter          |
          |       |               |
          +-------|---------------+
                  |        ^
                  |        |
                  |    +----------+
                  |    | count: 1 |<--E1
                  |    |__________/
                  |        ^
                  v        |
               (.)-(.)-----+
                |
                v
             P: nil
          body: (set! count (+ counter 1))
                 count

并返回 1, 第二次执行时会再次修改 E1 框架里的 count, 使它为原值加一.

现在能明白这段闭包定义的含义了吧:

“闭包 = 函数 + 引用环境”.

斑马谜题的 Erlang 求解

Tue, 09 Dec 2014 17:03:31 +0000

斑马谜题是个典型的约束满足问题(CSPs). 数独, 幻方也属于 CSPs 问题. Erlang 的列表解析等语言特性让它能够以一种非常贴近自然语言的描述方式来解决这类问题: 不需要考虑过程式的求解步骤, 描述好约束条件, Erlang 解释器通过域搜索匹配出了答案. 有人还用 Erlang 写了一个对于有限域约束(Finite Domain Constraints) 的一个扩展.

用 Erlang 的列表解析生成所有三阶幻方是如此简单:

%% magicsquare.erl

-module(magicsquare).
-export([magicsquare/0]).

magicsquare() ->
    [ {A00, A01, A02, A10, A11, A12, A20, A21, A22} ||
      A00 <- lists:seq(1, 9),
      A01 <- lists:seq(1, 9) -- [A00],
      A02 <- lists:seq(1, 9) -- [A00, A01],
      A10 <- lists:seq(1, 9) -- [A00, A01, A02],
      A11 <- lists:seq(1, 9) -- [A00, A01, A02, A10],
      A12 <- lists:seq(1, 9) -- [A00, A01, A02, A10, A11],
      A20 <- lists:seq(1, 9) -- [A00, A01, A02, A10, A11, A12],
      A21 <- lists:seq(1, 9) -- [A00, A01, A02, A10, A11, A12, A20],
      A22 <- lists:seq(1, 9) -- [A00, A01, A02, A10, A11, A12, A20, A21],

      %% 每一行的和都为 15
      A00 + A01 + A02 =:= 15,
      A10 + A11 + A12 =:= 15,
      A20 + A21 + A22 =:= 15,

      %% 每一列的和都为 15
      A00 + A10 + A20 =:= 15,
      A01 + A11 + A21 =:= 15,
      A02 + A12 + A22 =:= 15,

      %% 对角线的和为 15
      A00 + A11 + A22 =:= 15,
      A02 + A11 + A20 =:= 15
    ].

既然著名的斑马谜题和幻方是同样类型的问题, 按理说用 Erlang 写个求解程序也不是个难事. 先把斑马问题贴出来:

Five men of different nationality (England, Spain, Japan, Italy, Norway) live in the first five houses on a street. They all each have a profession (painter, diplomat, violinist, doctor, sculptor), one animal (dog, zebra, fox, snail, horse), and one favorite drink (juice, water, tea, coffee, milk), all different from the others. Each of the houses is painted in a color different from all the others (green, red, yellow, blue, white).

Furthermore:

The Englishman lives in the red house.

The Spaniard owns the dog.

The Japanese is the painter.

The Italian likes tea.

The Norwegian lives in the leftmost house.

The owner of the green house likes coffee.

The green house is to the right of the white one.

The sculptor breeds snails.

The diplomat lives in the yellow house.

Milk is drunk in the third house.

The Norwegian’s house is next to the blue one.

The violinist likes juice.

The fox is in the house next to the doctor’s house.

The horse is in the house next to the diplomat’s.

The problem is thus to infer who owns the zebra and who drinks water.

为方便程序描述问题, 先为国籍, 职业, 颜色, 宠物, 饮料这五项的内容映射到 1~5 这几个数字去:

House: L to R	1	2	3	4	5
Nation	England	Spain	Japan	Italy	Norway
Profession	painter	diplomat	violinist	doctor	sculptor
Color	green	red	yellow	blue	white
Animal	dog	zebra	fox	snail	horse
Drink	juice	water	tea	coffee	milk

然后就可以用 Erlang 描述问题了:

%% zebra.erl version 1
-module(zebra).
-compile(export_all).

perms([]) -> [[]];
perms(L)  -> [[H|T] || H <- L, T <- perms(L--[H])].

full_perms(N) ->
    perms(lists:seq(1, N)).

zebra() ->
    [ {N, C, P, A, D} ||
            N <- full_perms(5),
            C <- full_perms(5),
            P <- full_perms(5),
            A <- full_perms(5),
            D <- full_perms(5),
            lists:nth(1, N) =:= lists:nth(2, C), % 条件1
            lists:nth(2, N) =:= lists:nth(1, A), % 条件2
            lists:nth(3, N) =:= lists:nth(1, P), % 条件3
            lists:nth(4, N) =:= lists:nth(3, D), % 条件4
            lists:nth(5, N) =:= 1, % 条件5
            lists:nth(1, C) =:= lists:nth(4, D), % 条件6
            lists:nth(5, C) + 1 =:= lists:nth(1, C), % 条件7
            lists:nth(5, P) =:= lists:nth(4, A), % 条件8
            lists:nth(2, P) =:= lists:nth(3, C), % 条件9
            lists:nth(5, D) =:= 3, % 条件10
            (((lists:nth(5, N) + 1) =:= lists:nth(4, C)) orelse ((lists:nth(4, C) + 1) =:= lists:nth(5, N))), % 条件11
            lists:nth(3, P) =:= lists:nth(1, D), % 条件12
            (((lists:nth(3, A) + 1) =:= lists:nth(4, P)) orelse ((lists:nth(4, P) + 1) =:= lists:nth(3, A))), % 条件13
            (((lists:nth(5, A) + 1) =:= lists:nth(2, P)) orelse ((lists:nth(2, P) + 1) =:= lists:nth(5, A))) % 条件14
    ].

编译运行:

$ erl
1> c(zebra).
{ok, zebra}
2> zebra:zebra().
[{[3,4,5,2,1],
  [5,3,1,2,4],
  [5,1,4,2,3],
  [4,5,1,3,2],
  [4,1,2,5,3]}]

不错, 寥寥二三十行代码(大部分是在阐述约束条件)可以求解出正确答案了. 可是它运行得非常慢, 在我的机器上大概花了一两个小时! 而且得出的答案还需要人工将数字映射到对应的属性去.

先来解决运行慢的问题: 还记得计算机程序的构造和解释 SICP练习4.39这个问题吗? 约束条件的顺序不会影响答案, 但会影响程序执行时搜索范围的大小, 导致不同的约束条件的顺序运行的时间相差巨大. 把约束性强的条件放在前面, 将显著减少搜索范围, 降低运行时间. 调整下上面的zebra求解代码, 就瞬间解出了答案:

%% zebra.erl version2
-module(zebra).
-compile(export_all).

perms([]) -> [[]];
perms(L)  -> [[H|T] || H <- L, T <- perms(L--[H])].

full_perms(N) ->
    perms(lists:seq(1, N)).

zebra() ->
    [ {N, C, P, A, D} ||
            N <- full_perms(5),
            lists:nth(5, N) =:= 1, % 条件5
            C <- full_perms(5),
            (((lists:nth(5, N) + 1) =:= lists:nth(4, C)) orelse ((lists:nth(4, C) + 1) =:= lists:nth(5, N))), % 条件11
            lists:nth(1, N) =:= lists:nth(2, C), % 条件1
            lists:nth(5, C) + 1 =:= lists:nth(1, C), % 条件7
            P <- full_perms(5),
            lists:nth(3, N) =:= lists:nth(1, P), % 条件3
            lists:nth(2, P) =:= lists:nth(3, C), % 条件9
            A <- full_perms(5),
            lists:nth(2, N) =:= lists:nth(1, A), % 条件2
            lists:nth(5, P) =:= lists:nth(4, A), % 条件8
            (((lists:nth(3, A) + 1) =:= lists:nth(4, P)) orelse ((lists:nth(4, P) + 1) =:= lists:nth(3, A))), % 条件13
            (((lists:nth(5, A) + 1) =:= lists:nth(2, P)) orelse ((lists:nth(2, P) + 1) =:= lists:nth(5, A))), % 条件14
            D <- full_perms(5),
            lists:nth(5, D) =:= 3, % 条件10
            lists:nth(4, N) =:= lists:nth(3, D), % 条件4
            lists:nth(1, C) =:= lists:nth(4, D), % 条件6
            lists:nth(3, P) =:= lists:nth(1, D) % 条件12
    ].

解决了性能问题, 再来完善一下程序, 在程序里面映射好各种属性, 这样就能更好地描述约束条件了. 完整的 Erlang 代码如下:

%% zebra.erl final version
-module(zebra).
-export([zebra/0, zebra_print/0, who_own_zebra/0]).

%% @spec (List::list(), Ele) -> integer()
%% @doc Returns the position of `Ele' in the `List'. 0 is returned
%%      when `Ele' is not found.
%% @end
pos(List, Ele) ->
     pos(List, Ele, 1).
pos([Ele | _Tail], Ele, Pos) ->
     Pos;
pos([_ | Tail], Ele, Pos) ->
     pos(Tail, Ele, Pos+1);
pos([], _Ele, _) ->
     0.

nation() -> ['England', 'Spain', 'Japan', 'Italy', 'Norway'].
profession() -> [painter, diplomat, violinist, doctor, sculptor].
color() -> [green, red, yellow, blue, white].
animal() -> [dog, zebra, fox, snail, horse].
drink() -> [juice, water, tea, coffee, milk].

data_inx(N, Data) ->
    lists:nth(N, Data()).

data_pos(Name, Data) ->
    pos(Data(), Name).

perms([]) -> [[]];
perms(L)  -> [[H|T] || H <- L, T <- perms(L--[H])].

full_perms(N) ->
    perms(lists:seq(1, N)).

zebra_print() ->
    [io:format("Nation:\t\t~-12s~-12s~-12s~-12s~-12s~n"
                "Color:\t\t~-12s~-12s~-12s~-12s~-12s~n"
                "Profession:\t~-12s~-12s~-12s~-12s~-12s~n"
                "Animal:\t\t~-12s~-12s~-12s~-12s~-12s~n"
                "Drink:\t\t~-12s~-12s~-12s~-12s~-12s~n~n",
               [data_inx(pos(N, 1), fun nation/0),
                data_inx(pos(N, 2), fun nation/0),
                data_inx(pos(N, 3), fun nation/0),
                data_inx(pos(N, 4), fun nation/0),
                data_inx(pos(N, 5), fun nation/0),

                data_inx(pos(C, 1), fun color/0),
                data_inx(pos(C, 2), fun color/0),
                data_inx(pos(C, 3), fun color/0),
                data_inx(pos(C, 4), fun color/0),
                data_inx(pos(C, 5), fun color/0),

                data_inx(pos(P, 1), fun profession/0),
                data_inx(pos(P, 2), fun profession/0),
                data_inx(pos(P, 3), fun profession/0),
                data_inx(pos(P, 4), fun profession/0),
                data_inx(pos(P, 5), fun profession/0),

                data_inx(pos(A, 1), fun animal/0),
                data_inx(pos(A, 2), fun animal/0),
                data_inx(pos(A, 3), fun animal/0),
                data_inx(pos(A, 4), fun animal/0),
                data_inx(pos(A, 5), fun animal/0),

                data_inx(pos(D, 1), fun drink/0),
                data_inx(pos(D, 2), fun drink/0),
                data_inx(pos(D, 3), fun drink/0),
                data_inx(pos(D, 4), fun drink/0),
                data_inx(pos(D, 5), fun drink/0)]) ||
                                    {N, C, P, A, D} <- zebra()
    ].

who_own_zebra() ->
    [data_inx(pos(N, pos(A, data_pos(zebra, fun animal/0))), fun nation/0) ||
        {N, _C, _P, A, _D} <- zebra()
    ].

zebra() ->
    [{N, C, P, A, D} ||
            N <- full_perms(5),

            %% The Norwegian lives in the leftmost house
            lists:nth(data_pos('Norway', fun nation/0), N) =:= 1,

            C <- full_perms(5),

            %% The Norwegian's house is next to the blue one
            (((lists:nth(data_pos('Norway', fun nation/0), N) + 1) =:=
	      lists:nth(data_pos(blue, fun color/0), C)) orelse
	     	((lists:nth(4, C) + 1) =:= lists:nth(5, N))),

            %% The Englishman lives in the red house
            lists:nth(data_pos('England', fun nation/0), N) =:=
	    	lists:nth(data_pos(red, fun color/0), C),

            %% The green house is to the right of the white one
            lists:nth(data_pos(white, fun color/0), C) + 1 =:=
	    	lists:nth(data_pos(green, fun color/0), C),

            P <- full_perms(5),

            %% The Japanese is the painter
            lists:nth(data_pos('Japan', fun nation/0), N) =:=
	    	lists:nth(data_pos(painter, fun profession/0), P),

            A <- full_perms(5),

            %% The Spaniard owns the dog
            lists:nth(data_pos('Spain', fun nation/0), N) =:=
	    	lists:nth(data_pos(dog, fun animal/0), A),

            %% The sculptor breeds snails
            lists:nth(data_pos(sculptor, fun profession/0), P) =:=
	    	lists:nth(data_pos(snail, fun animal/0), A),

            D <- full_perms(5),

            %% The diplomat lives in the yellow house
            lists:nth(data_pos(diplomat, fun profession/0), P) =:=
	    	lists:nth(data_pos(yellow, fun color/0), C),

            %% The fox is in the house next to the doctor's house
            (((lists:nth(data_pos(fox, fun animal/0), A) + 1) =:=
	      lists:nth(data_pos(doctor, fun profession/0), P)) orelse
	     	((lists:nth(data_pos(doctor, fun profession/0), P) + 1) =:=
		 lists:nth(data_pos(fox, fun animal/0), A))),

            %% The horse is in the house next to the diplomat's
            (((lists:nth(data_pos(horse, fun animal/0), A) + 1) =:=
	      lists:nth(data_pos(diplomat, fun profession/0), P)) orelse
	     	((lists:nth(data_pos(diplomat, fun profession/0), P) + 1) =:=
		 lists:nth(data_pos(horse, fun animal/0), A))),

            %% Milk is drunk in the third house
            lists:nth(data_pos(milk, fun drink/0), D) =:= 3,

            %% The Italian likes tea
            lists:nth(data_pos('Italy', fun nation/0), N) =:=
	    	lists:nth(data_pos(tea, fun drink/0), D),

            %% The owner of the green house likes coffee
            lists:nth(data_pos(green, fun color/0), C) =:=
	    	lists:nth(data_pos(coffee, fun drink/0), D),

            %% The violinist likes juice
            lists:nth(data_pos(violinist, fun profession/0), P) =:=
		lists:nth(data_pos(juice, fun drink/0), D)
    ].