从历史上看，Bourne shell并没有内置的true和false命令。True被改成了:，false被改成了let 0。

:在可移植性方面比真实的稍微好一些。作为一个简单的例子，考虑没有!管道操作符或||列表操作符(就像一些古老的Bourne shell的情况一样)。这使得if语句的else子句成为基于退出状态进行分支的唯一方法:

if command; then :; else ...; fi

因为if要求一个非空的then子句和注释不算作非空，:作为一个no-op。

现在(在现代语境中)你通常可以用:或者true。两者都是由POSIX指定的，其中一些发现true更容易阅读。然而，有一个有趣的区别::是所谓的POSIX特殊内置，而true是常规内置。

Special built-ins are required to be built into the shell; Regular built-ins are only "typically" built in, but it isn't strictly guaranteed. There usually shouldn't be a regular program named : with the function of true in PATH of most systems. Probably the most crucial difference is that with special built-ins, any variable set by the built-in - even in the environment during simple command evaluation - persists after the command completes, as demonstrated here using ksh93: $ unset x; ( x=hi :; echo "$x" ) hi $ ( x=hi true; echo "$x" ) $ Note that Zsh ignores this requirement, as does GNU Bash except when operating in POSIX compatibility mode, but all other major "POSIX sh derived" shells observe this including dash, ksh93, and mksh. Another difference is that regular built-ins must be compatible with exec - demonstrated here using Bash: $ ( exec : ) -bash: exec: :: not found $ ( exec true ) $ POSIX also explicitly notes that : may be faster than true, though this is of course an implementation-specific detail.

从历史上看，Bourne shell并没有内置的true和false命令。True被改成了:，false被改成了let 0。

:在可移植性方面比真实的稍微好一些。作为一个简单的例子，考虑没有!管道操作符或||列表操作符(就像一些古老的Bourne shell的情况一样)。这使得if语句的else子句成为基于退出状态进行分支的唯一方法:

if command; then :; else ...; fi

因为if要求一个非空的then子句和注释不算作非空，:作为一个no-op。

现在(在现代语境中)你通常可以用:或者true。两者都是由POSIX指定的，其中一些发现true更容易阅读。然而，有一个有趣的区别::是所谓的POSIX特殊内置，而true是常规内置。

Special built-ins are required to be built into the shell; Regular built-ins are only "typically" built in, but it isn't strictly guaranteed. There usually shouldn't be a regular program named : with the function of true in PATH of most systems. Probably the most crucial difference is that with special built-ins, any variable set by the built-in - even in the environment during simple command evaluation - persists after the command completes, as demonstrated here using ksh93: $ unset x; ( x=hi :; echo "$x" ) hi $ ( x=hi true; echo "$x" ) $ Note that Zsh ignores this requirement, as does GNU Bash except when operating in POSIX compatibility mode, but all other major "POSIX sh derived" shells observe this including dash, ksh93, and mksh. Another difference is that regular built-ins must be compatible with exec - demonstrated here using Bash: $ ( exec : ) -bash: exec: :: not found $ ( exec true ) $ POSIX also explicitly notes that : may be faster than true, though this is of course an implementation-specific detail.

你可以将它与反撇号(' ')结合使用来执行命令而不显示输出，如下所示:

: `some_command`

当然，你可以只执行some_command > /dev/null，但是:-version稍微短一些。

话虽如此，我不建议这样做，因为这会让人们感到困惑。它只是作为一个可能的用例出现在脑海中。

另一种方法，这里还没有提到的是在无限while循环中初始化参数。下面不是最清晰的示例，但它达到了它的目的。

#!/usr/bin/env bash
[ "$1" ] && foo=0 && bar="baz"
while : "${foo=2}" "${bar:=qux}"; do
    echo "$foo"
    (( foo == 3 )) && echo "$bar" && break
    (( foo=foo+1 ))
done

如果你想把一个文件截断为零字节，这对清除日志很有用，试试这个:

:> file.log

它对多语言程序也很有用:

#!/usr/bin/env sh
':' //; exec "$(command -v node)" "$0" "$@"
~function(){ ... }

现在这既是一个可执行的shell脚本，也是一个JavaScript程序:这意味着。/filename.js、sh filename.js和node filename.js都可以工作。

(这种用法确实有点奇怪，但还是很有效。)

请作一些说明:

Shell-scripts are evaluated line-by-line; and the exec command, when run, terminates the shell and replaces it's process with the resultant command. This means that to the shell, the program looks like this: #!/usr/bin/env sh ':' //; exec "$(command -v node)" "$0" "$@" As long as no parameter expansion or aliasing is occurring in the word, any word in a shell-script can be wrapped in quotes without changing its' meaning; this means that ':' is equivalent to : (we've only wrapped it in quotes here to achieve the JavaScript semantics described below) ... and as described above, the first command on the first line is a no-op (it translates to : //, or if you prefer to quote the words, ':' '//'. Notice that the // carries no special meaning here, as it does in JavaScript; it's just a meaningless word that's being thrown away.) Finally, the second command on the first line (after the semicolon), is the real meat of the program: it's the exec call which replaces the shell-script being invoked, with a Node.js process invoked to evaluate the rest of the script. Meanwhile, the first line, in JavaScript, parses as a string-literal (':'), and then a comment, which is deleted; thus, to JavaScript, the program looks like this: ':' ~function(){ ... } Since the string-literal is on a line by itself, it is a no-op statement, and is thus stripped from the program; that means that the entire line is removed, leaving only your program-code (in this example, the function(){ ... } body.)