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