我有一个格式的字符串[0-9]+\.[0-9]+\.[0-9]。我需要分别提取第一个、第二个和第三个数字。据我了解，捕获组应该能够做到这一点。我应该能够用来sed "s/\([0-9]*\)/\1/g获得第一个数字，sed "s/\([0-9]*\)/\2/g获得第二个数字，并sed "s/\([0-9]*\)/\3/g获得第三个数字。不过，在每种情况下，我都得到了整个字符串。为什么会这样？
可执行文件存储在/usr/libexec类 Unix 系统中。FHS 说（部分4.7. /usr/libexec : Binaries run by other programs (optional)"：
/usr/libexec包括不打算由用户或 shell 脚本直接执行的内部二进制文件。应用程序可以使用/usr/libexec.
在 Mac OS X 上，启动后立即rootless-init调用的程序launchd存储在/usr/libexec. /usr/libexec当它是可以存储在/usr/bin或 中的独立可执行文件时，为什么要存储在其中/usr/sbin？init和其他不被 shell 脚本直接调用的程序也存储在[/usr]/{bin,sbin}.
在strace输出中，可执行文件调用的库的路径在调用中open()。这是动态链接的可执行文件使用的系统调用吗？怎么样dlopen()？open()不是我猜想的调用会在程序执行中发挥作用。
这不是重复的，因为这是处理我在使用/etc/ld.so.conf.
要获取动态链接器搜索库的路径，我运行命令ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g". 什么时候/etc/ld.so.conf没有列出路径。上一条命令的输出是
/lib
/usr/lib
我认为它/lib首先搜索，然后搜索/usr/lib. 当我添加一个新路径时，例如/usr/local/lib, to/etc/ld.so.conf然后 remake /etc/ld.so.cache，输出ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"变为
/usr/local/lib
/lib
/usr/lib
我觉得这很奇怪，因为如果我认为列出目录的搜索顺序是从上到下是正确的，那么在/lib和之前搜索其他目录/usr/lib。在受信任的目录之前搜索附加目录本身并不奇怪，但是在/libbefore 搜索时/usr/lib，这很奇怪，因为/bin&/sbin在/usr/bin& /usr/sbinin之后搜索PATH。
即使列出的路径ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"是从下到上搜索的，它仍然是一个倾斜的排序，因为会在受信任的目录之后搜索其他目录，而/lib会在/usr/lib …
假设我必须使用引号来封装 subshell 输出，例如：
DATA="$(cat file.hex | xxd -r)"
但我需要嵌套这样的东西：
DATA="$(cat file.hex | xxd -r | tr -d \"$(cat trim.txt)\")"
我不能使用单引号，因为它们不会扩展其中的变量。转义引号不起作用，因为它们只是被视为被动文本。
我该如何处理？
很多人一直说 Linux 不保存有关绑定挂载的信息，因此无法获得它们及其来源的列表。这里有些例子：
来自这里的评论之一：
IIRC 此信息不会保存在任何地方：之后mount --bind，两个副本是等价的，没有一个比另一个更“原始”。毕竟，如果您已经卸载/mnt.
来自本网站的回答：
因此，记住哪些挂载是绑定挂载的唯一方法是将挂载命令的日志保留在/etc/mtab. 绑定安装操作由绑定安装选项指示（这会导致文件系统类型被忽略）。但是 mount 没有选项只列出使用一组特定选项安装的文件系统。
来自Debian 错误报告：
这是故意的。两个挂载点在所有方面都完全相同，因此内核不会保留任何标志来区分它们。
不过以上都是废话。该工具findmnt能够列出绑定安装的源路径（以 的形式device[source-path]；我也试图让它仅列出源路径而不是设备）。如果 Linux 内核要维护一个绑定挂载，那么该信息必须存储在某个地方，否则它无法知道/home绑定到/users. 那么这些数据在哪里呢？它是否存储在 RAM 中的某个模糊区域？是否findmnt在/proc某处查看？
Btrfs wiki 的系统管理员指南（此处）说道：
Btrfs 子卷可以被视为 POSIX 文件命名空间。
我记得一开始它说子卷是一个“POSIX 文件命名空间”，而不是被认为是“POSIX 文件命名空间”。Google 搜索"POSIX file namespace"仅显示有关 Btrfs 的内容，因此该短语没有帮助。
Btrfs 中的子卷到底是什么？如果子卷可以作为文件系统根目录中的目录进行访问，那么挂载子卷与将任何其他文件系统上的目录绑定挂载到另一个位置（无需中间挂载所述文件系统的根）有何不同？这就是我的意思：
# standard bind mount
mkdir /mnt/data
mkdir /mnt/docs
mount /dev/sda2 /mnt/data
mount --bind /mnt/data/docs /mnt/docs
umount /mnt/data
rmdir /mnt/data
# hypothetical method of directly mounting
# a file/directory on a filesystem
# to some path that achieves the same
# as the above
mkdir /mnt/docs
mount -o path_on_fs=/docs /dev/sda2 /mnt/docs
# if /docs on sda2 …Debian 的 SELinux 文档说这user_xattr与扩展属性不同。那是什么？
我在命令行环境和 shell 脚本中使用了许多 shell 函数。我希望其中两个upper和lower, 根据数据是否通过管道传输到它们而表现不同。这两个函数目前都是这样编写的，它们通过传递给它们的参数接收输入。
这是 的定义upper：
upper () {
my_echo "${1}" | tr "[:lower:]" "[:upper:]"
return 0
}
这是 的定义lower：
lower () {
my_echo "${1}" | tr "[:upper:]" "[:lower:]"
return 0
}
(my_echo是我写的一个 Python 脚本来替代echo。它应该输出传递给它的任何内容作为参数，同时将转义序列转换为它们的文字。我可以打印任何字符串而不会将其解释为选项，例如-e对于echo. Unix 控制台的工作方式阻碍了这个目标，所以我搁置了它，所以你可以忽略它。）
这些功能有几个过去的化身。这些是在标准输入上运行的版本的定义：
upper () {
tr "[:lower:]" "[:upper:]"
}
lower () {
tr "[:upper:]" "[:lower:]"
}
如果函数被管道传输到，那么它应该像上面那样操作。如果不是，它应该读取第一个参数。
我读过，用于创建硬链接的命令（也许还有系统调用）不允许为目录创建硬链接。我还了解硬链接可能会给基于路径的安全性（例如 DAC、Linux 安全模块和 IMA/EVM）带来问题。如果无法创建到目录的硬链接，则可以解决此类目录可能带来的安全问题。但是，是否可以通过在存储级别编辑文件系统来创建两个或多个到目录 inode 的硬链接？