我注意到TERM环境变量设置为xterm或者xterm-256colorMac OS X 的 Terminal.app 实用程序尊重大多数 ANSI 转义码，至少当这些转义码与更改文本颜色有关时。
例如：
echo -e "\033[0;31mERROR:\033[0m It worked"
产生：
但是，我对 ANSI 转义码提供的光标位置操作功能更感兴趣。不幸的是，从我收集到的信息来看，这种类型的代码在 Terminal.app 中似乎不太好用。例如，我想做的是这样的：
echo -e "\033[sHello world\033[uG'day"
ESC[s保存当前光标位置，同时ESC[u恢复上次保存的位置。由于运行上面的脚本，我希望“G'day”中的五个字符在光标重新定位后覆盖“Hello”的五个字符，产生以下结果：
G'day world
事实上，这正是我使用 iTerm2.app、ConEmu for Windows（运行 MinGW 或 MSYS Git 的 bash.exe 副本）等所得到的。然而，我在 Terminal.app 中看到的是：
Hello worldG'day
除了 Terminal.app 只是缺乏对这些代码的支持之外，这是否有原因？有没有办法启用这个功能？有没有可能我配置错误？我的学期设置？还有什么？
我一直在到处搜索，但没有找到任何与 Terminal.app 相关的东西，特别是。我觉得奇怪的是它会通过 ANSI 转义码支持彩色文本，但不支持通过完全相同的技术重新定位光标。这似乎是一个相当明确的标准的一个相当任意的子集。这就是让我觉得我配置错误的原因，而不是 Terminal.app 是罪魁祸首……但是，我想它可能根本无法完成。（可能iTerm2首先存在的原因之一？）
如果有人能对这种情况有所了解，将不胜感激！
更新
所以，我做了更多的阅读和实验，发现了以下奇怪之处：
在查看了下面 nm 的答案后，我决定将返回的字节写出tput到文件中，看看它们与常规 ANSI 指令有何不同。
$ echo "$(tput sc)Hello world$(tput rc)G'day" > out.bin
$ cat -e out.bin
^[7Hello world^[8G'day$
ESC 7如果我将序列和发送给它，似乎一切都按预期工作ESC 8，但如果我发送它ESC [s，则ESC [u一切正常）。由于不可能将 ASCII 十进制字符7或8转义的八进制字节表示放在旁边（\0337!= ESC），因此可以使用环境变量来避免依赖tput：
$ esc=$'\033'
$ csi="${esc}["
$ echo "${csi}0;31mERROR:${csi}0m It worked."
ERROR: It worked. # Color works, as before
$ echo "${csi}sHello world${csi}uG'day"
Hello worldG'day # No dice
$ echo "${esc}7Hello world${esc}8G'day"
G'day world # Success
我不确定这是为什么。如果ESC 7并且ESC 8是 ANSI SCP 和 RCP 的某种专有或自定义代码，它有可能因终端实现而异，它会向我解释为什么tput首先创建它。
不幸的是，我无法使用tput我目前正在做的事情，因为我并不是专门在 bash 环境中工作。我更好奇原始字节是如何从终端解释到终端的，更具体地说，是否有办法让 Terminal.app 尊重我尝试过的所有其他终端模拟器相同的 ANSI 转义码似乎没有问题。那可能吗？在这一点上，我开始认为它可能根本不是，这很好，但很高兴知道肯定，也可能了解原因。