标签: shell-builtin

我一直想知道为什么cd不是程序，但从未设法找到答案。

有谁知道为什么会这样？

eval并且exec都内置在执行命令的 bash(1) 命令中。

我也看到exec有几个选项，但这是唯一的区别吗？他们的上下文会发生什么？

内置命令和另一个名义上可以做同样事情的命令之间有什么内在的区别吗？

例如。内置函数是否得到“特殊”处理？...运行它们的开销是否更少？.. 或者它们只是简单地“内置”；像你汽车的仪表盘？

...是否有这些内置函数的明确（当前）列表？

据我所知，[[是 的增强版本[，但是当我将其[[视为关键字并[显示为内置时，我感到困惑。

[root@server ~]# type [
[ is a shell builtin
[root@server ~]# type [[
[[ is a shell keyword

TLDP说

内置命令可能是同名系统命令的同义词，但 Bash 在内部重新实现了它。例如，Bash echo 命令与 /bin/echo 不同，尽管它们的行为几乎相同。

和

关键字是保留字、标记或运算符。关键字对 shell 有特殊的意义，实际上是 shell 语法的构建块。例如，for、while、do 和 ! 是关键字。与内置函数类似，关键字被硬编码到 Bash 中，但与内置函数不同的是，关键字本身不是命令，而是命令结构的子单元。[2]

难道不应该使双方[和[[关键字？有什么我在这里想念的吗？此外，此链接再次确认两者[和[[应该属于同一类。

有什么地方可以下载每个内置命令的联机帮助页吗？

我知道你可以使用helporman bash和 search 来查找有关它的信息，但我希望它们分开，所以我可以这样做man read并获取阅读手册页。

来自help compgen：

$ help compgen
compgen: compgen [-abcdefgjksuv] [-o option]  [-A action] [-G globpat] [-W wordlist]  [-F function] [-C command] [-X filterpat] [-P prefix] [-S suffix] [word]
    Display possible completions depending on the options.
    
    Intended to be used from within a shell function generating possible
    completions.  If the optional WORD argument is supplied, matches against
    WORD are generated.
    
    Exit Status:
    Returns success unless an invalid option is supplied or an error occurs.

选项[-abcdefgjksuv]代表什么？

换句话说，我想知道如何使用所有选项。

我已经破解了很多 shell 脚本，有时最简单的事情让我感到困惑。今天我遇到了一个广泛使用:（冒号）bash 内置的脚本。

该文档似乎很简单：

: (a colon)  
     : [arguments]  

Run Code Online (Sandbox Code Playgroud)

除了扩展参数和执行重定向之外，什么都不做。返回状态为零。

但是，我以前只在 shell 扩展的演示中看到过这个。我遇到的脚本中的用例广泛使用了这种结构：

if [ -f ${file} ]; then
    grep some_string ${file} >> otherfile || :
    grep other_string ${file} >> otherfile || :
fi

实际上有数百个 grep，但它们只是更多相同。除了上面的简单结构之外，不存在输入/输出重定向。稍后在脚本中不会检查返回值。

我正在阅读这是一个无用的结构，上面写着“或什么都不做”。用“或什么都不做”来结束这些 grep 的目的是什么？在什么情况下，这个构造会导致与简单地|| :从所有实例中删除不同的结果？

这个问题的目的是回答好奇心，而不是解决特定的计算问题。问题是：为什么 POSIX 强制实用程序通常不内置到 shell 实现中？

例如，我有一个脚本，它基本上读取一些小文本文件并检查它们的格式是否正确，但由于大量的字符串操作，在我的机器上运行需要 27 秒。这种字符串操作通过调用各种实用程序来创建数千个新进程，因此速度很慢。我非常有信心，如果内置了一些实用程序，即grep, sed, cut,tr和expr，那么脚本将在一秒或更短的时间内运行（根据我在 C 中的经验）。

似乎在很多情况下，构建这些实用程序会影响 shell 脚本中的解决方案是否具有可接受的性能。

显然，选择不内置这些实用程序是有原因的。也许在系统级别拥有一个实用程序版本可以避免该实用程序的多个不同版本被各种 shell 使用。我真的想不出还有很多其他原因来保持创建这么多新进程的开销，而且 POSIX 对实用程序的定义足够多，以至于有不同的实现似乎不是什么大问题，只要它们都是 POSIX合规。至少没有像拥有这么多流程的低效率那样大的问题。

$ which echo
echo: shell built-in command.
$ which ls
/bin/ls
$ which cat
/bin/cat

为什么回声不喜欢一个独立的工具ls，ps，cat等？为什么它是特定于外壳的？有什么好的理由吗？

当我使用该type命令来确定cat是 shell 内置程序还是外部程序时，我得到以下输出：

-$ type cat
cat is hashed (/bin/cat)
-$

这是否意味着这cat是一个外部程序/bin/cat？

我很困惑，因为当我检查下面的输出时，echo我看到它既是built-in一个程序，又是一个程序/bin/echo

-$ type echo
echo is a shell builtin
-$ which echo
/bin/echo
-$ 

所以我不能使用/bin/cat必然意味着外部程序的逻辑，因为 echo/bin/echo仍然是内置的。

那我怎么知道是什么cat？内置还是外置？