终端应用程序应该猜测用户想要什么吗？

Question

有一个小讨论 关于 git 默认为用户做什么和不做什么。

默认情况下，颜色被禁用（通常使用 git config 设置），但它会将其输出发送到某些命令的寻呼应用程序（例如在 git log 中）。

一方面是不应启用任何标志，因为它使用户可以完全控制应用程序。相反，在发布新应用程序时，应该尝试以尽可能多的花哨功能尽快赢得用户。

这可能是一个非常主观的问题，但是在 2010 年，终端应用程序应该开始默认做出可用性决策还是强制用户进行自定义。

Answer 1

$ rm file.txt </dev/null
Do you want to remove file.txt [y/n]
tty not connected, guessing "no"

所以不；请避免任何假设，因为它们可能与预期完全相反。

git diff 中的颜色默认是禁用的，因为分页器可能不支持它——即使是 less 也是如此，需要使用 -R 选项显式调用以打开转义序列支持。

Answer 2

如果在某些情况下某些东西的行为不同，例如当输出是 tty 与管道时的颜色情况，那么应该清楚这个条件是什么，但是 git log 不会检查这一点，而是检查其他一些 程序在其 --color=auto 模式下确实类似于 ls

在使用 --color 的 git log 情况下， 它使用较少的颜色转义代码，

如果您想覆盖它，请给它们一个像 --color[=WHEH] 选项，如 ls 可以强制颜色无论输出的类型如何，

--color[=WHEN]         control whether color is used to distinguish file
                       types.  WHEN may be `never', `always', or `auto'

自动模式都是我在第一段中描述的，

默认值应该是对程序用户有用的模式，如果在某些情况下默认值不是想要的，那就是选项为了

Answer 3

终端应用程序也不例外。请参阅 oracle import (imp)，它提供了合理的默认值，因此即使它提出问题但给出了默认选择，天真的用户也会选择它，除非他真的确定该选项。或者甚至在 oracle 中创建具有较小版本的数据库，该版本假定所有合理的默认值和扩展版本。

一方面是没有
应该启用标志，因为它给出了
用户完全控制
应用

如果用户真正开始使用它，他将学会使用完全控制。例如，我正在评估开源的工作流引擎，想象一下，对于每个工作流引擎，我都需要在其启动和运行之前设置完整的基础设施，例如数据库表结构。相反，最复杂的工作流引擎之一提供了很好的 HSQLDB 实现，非常适合评估。

一旦某些东西开始工作，我就可以调整它以适合我，而不是花几天时间在一个一开始看起来很死的软件上。