Harold Fischer's questions

给定一个文件，我想以八进制格式列出它包含的所有字节，每个字节在自己的行中。

为什么会这样：

#!/bin/sh --

newline='
'

od -v -A n -t o1 -- /tmp/file | \
sed -e "s/ /\\${newline}/g" | \
sed -e '/^$/d'

而不是这个：

#!/bin/sh --

newline='
'

od -v -A n -t o1 -- /tmp/file | \
sed -e "s/ /\\${newline}/g" -e '/^$/d'

为什么我必须两次分别调用 sed 才能完成工作？

作为参考， 的输出od，未经进一步处理，可能类似于以下内容：

         047 124 167 141 163 040 142 162 151 154 154 151 147 054 040 141
         156 144 040 164 150 145 040 163 154 151 164 150 171 040 164 157
         166 145 163 012 011 104 151 144 040 147 171 162 145 040 141 156
         144 040 147 151 155 142 154 145 040 151 156 040 164 150 145 040
         167 141 142 145 072 012 101 154 154 040 155 151 155 163 171 040
         167 145 162 145 040 164 150 145 040 142 157 162 157 147 157 166
         145 163 054 012 011 101 156 144 040 164 150 145 040 155 157 155
         145 040 162 141 164 150 163 040 157 165 164 147 162 141 142 145
         056 012

我想将两个数字与bc. 根据StackOverflow 上这个高度评价的答案，我可以这样做：

printf '%s\n' '1.2 > 0.4' | bc

bc发送1到 STDOUT，指示该语句为真（如果该语句为假，它将返回 0）。

根据 POSIX 页面bc：

与所有其他运算符不同，关系运算符（'<'、'>'、"<="、">="、"=="、"!=" ) 仅作为 if、while、或在 for 语句中。

也许我误解了，但这种语言似乎不允许上面示例中使用的语法。

独立使用关系运算符是否bc违反 POSIX？如果是这样，我应该如何重写我的示例？

在处理嵌套参数扩展时，以下哪一种是正确的引用方式？

这个：

var="${var#"${var%%[![:space:]]*}"}"

或者这个：

var="${var#${var%%[![:space:]]*}}"

我已经看到它是双向的。第一个变体是来自Stack Overflow 答案的片段。这是对该问题最受好评的答案之一（问题是关于如何从变量中修剪空白）。

我也很难找到一个有信誉的来源来解决如何在使用作为变量而不是文字文本的“单词”或“模式”时引用事物。下面两个，哪个是正确的？

这个：

strip_ext="${filename%."$filename_ext"}"

或者这个：

strip_ext="${filename%.$filename_ext}"

#!/bin/bash --

echo "$$"

LC_ALL=C sed 's/[!-~]/b/g' /tmp/bigfile > /tmp/outfile

echo end of script

如果我QUIT使用发送信号，则会Ctrl + \得到以下输出：

# ./script.sh
6739
^\./script.sh: line 5:  6740 Quit                    LC_ALL=C sed 's/[!-~]/b/g' /tmp/bigfile > /tmp/outfile
end of script

这会按预期杀死sed并导致核心转储，但脚本会继续。这是预期的行为吗？这发生在我身上bashandash但不是dashor ksh93。

这就是我现在用来完成工作的方法：

#!/bin/sh --

string='Aa1!z'

if ! printf '%s\n' "$string" | LC_ALL=C grep -q '[[:upper:]]' || \
   ! printf '%s\n' "$string" | LC_ALL=C grep -q '[[:lower:]]' || \
   ! printf '%s\n' "$string" | LC_ALL=C grep -q '[[:digit:]]' || \
   ! printf '%s\n' "$string" | LC_ALL=C grep -q '[[:punct:]]'; then
  printf '%s\n' 'String does not meet your requirements'
else
  printf '%s\n' 'String meets your requirements'
fi

这是非常低效和冗长的。有一个更好的方法吗？

当我跑

user@hostname:~$ su -- root -z

我明白了

bash: -z: invalid option
Usage:  bash [GNU long option] [option] ...
...

以上是我期望的行为。

当我跑

user@hostname:~$ su -l -- root -z

我明白了

-su: -z: invalid option
Usage:  -su [GNU long option] [option] ...
...

我仅使用无效选项-z来演示哪个命令正在解析该选项。

这种行为让我很恼火。su在我宣布选项结束后继续搜索选项。我错过了什么，这是一个错误还是只是可怕的设计？

#!/bin/sh --

for set_trap_sig in HUP INT QUIT ALRM TERM; do
    trap -- '
        trap -- - '"${set_trap_sig:?}"' EXIT || exit "$?"
        kill -s '"${set_trap_sig:?}"' -- "$$" || exit "$?"' "$set_trap_sig"
done

sleep 15 || exit "$?"

这是我向脚本发送 SIGINT 时发生的情况

user@hostname:/tmp$ ./script.sh
^C./script.sh: 3: ./script.sh: Syntax error: EOF in backquote substitution

这个问题似乎是 dash 特有的。在 ash、bash 和 ksh93 上，我没有收到此错误。这特别奇怪，因为我的脚本甚至不包含反引号字符。

如果我删除第 5 行尾随的双引号，$?错误就会消失。

我是在做一些愚蠢的事情还是冲刺被削弱了？是的，我知道我写的剧本就像一个偏执的精神分裂症患者。

编辑：我们已经确定这是一个非常严重的错误，它甚至会影响现代版本的 Ubuntu 和 Debian。有谁知道解决方法？

我想澄清一下，我不是在谈论如何在 shell 解释级别上转义字符。

据我所知，只需要转义两个字符：%和\

要打印文字%，您必须使用前面的 转义它%：

printf '%%'

要打印文字\，您必须使用前面的 : 对其进行转义\：

printf '\\'

是否有任何其他情况我需要转义一个字符才能按字面意思解释它？

根据POSIX Shell 命令语言页面：

\

仅当被认为是特殊<backslash>的以下字符之一时，才应保留其作为转义字符的特殊含义（请参阅转义字符（反斜杠））：

$ ` " \ <newline>

我将此解释为意味着\如果这五个特殊字符中的一个在其给定上下文中是特殊的，则它应该只转义它。

The man pages for ash, dash, bash and ksh do not contain the clause "when considered special". I take this to mean (and have confirmed through basic experimentation) that \ has the effect of escaping these five characters unconditionally, even when one of these five characters is not special in its given context.

Consider the output of $ printf '%s\n' "\abcde", which is \abcde. This is expected because a is not special in this context (or any context for that matter); therefore the \ is not special and is treated literally.

现在考虑 的输出$ printf '%s\n' "\\abcde"，即\abcde。这不是我所期望的行为。在我看来，字符串中的第一个反斜杠\\abcde也应该按字面意思对待，因为在不特殊\的上下文中紧随其后。\我期望的输出是\\abcde.

我看到意外行为的另一种情况是在 的输出中$ printf '%s\n' "ab\$"，即ab$. 在我看来，$在这种情况下确实具有特殊含义，因为它确实用于引入参数扩展、命令替换或算术扩展。因此，在我看来，\应该按字面意思对待，因为它在不特殊$的上下文中紧随其后。$我期望的输出是ab\$.

为了记录，我希望我完全不在这儿。这让我的生活变得更加困难，不得不担心只有在某些情况下才能逃脱这五个角色。\我努力尽可能地正确，如果主流 POSIX 兼容 shell 中的这种（个人希望的）行为不符合 POSIX ，我不想依赖于无条件转义这五个特殊字符。

从POSIX 规范的Shell 命令语言页面：

如果 shell 命令文件的第一行以字符“#!”开头，则结果未指定。

为什么#!POSIX 未指定行为？我感到莫名其妙的是，如此便携和广泛使用的东西会有一个未指定的行为。

file.txt 的内容（不奇怪，POSIX 定义的文本文件）

iguana
gecko
anole

示例脚本：

#!/bin/sh

string="$(cat file.txt)"

printf '%s' "$string"

样本输出：

[coolguy@somemachine ~]$ ./script.sh
iguana
gecko
anole[coolguy@somemachine ~]$

最后一个换行符发生了什么？为什么除了最后一个保留的换行符都是换行符？如果应该已经有一个换行符，我们似乎不应该使用 echo 添加一个换行符。

POSIX 将文本文件定义为：

包含组织成零行或多行的字符的文件。这些行不包含 NUL 字符，长度不能超过 {LINE_MAX} 个字节，包括 <newline> 字符。尽管 POSIX.1-2017 不区分文本文件和二进制文件（参见 ISO C 标准），但许多实用程序仅在对文本文件进行操作时产生可预测或有意义的输出。具有此类限制的标准实用程序始终在其 STDIN 或 INPUT FILES 部分中指定“文本文件”。

来源： http: //pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403

但是，我发现有几件事不清楚：

1. 文本文件必须是常规文件吗？在上面的摘录中，它没有明确说明文件必须是常规文件

2. 如果一个文件仅包含一个字符和一个字符（即，一个不以换行符终止的单个字符），是否可以将文件视为文本文件？我知道这个问题可能听起来很挑剔，但他们使用“字符”一词而不是“一个或多个字符”。其他人可能不同意，但如果他们的意思是“一个或多个字符”，我认为他们应该明确地说出来

3. 在上面的摘录中，它提到了“行”。我找到了四个名称中带有 line 的定义：“Empty Line”、“Display Line”、“Incomplete Line”和“Line”。我是否应该推断它们的意思是“线”，因为它们省略了“空”、“显示”和“不完整”——或者所有这四个定义都包含在上面的摘录中被视为一条线？

此文本块之后出现的所有问题都取决于推断“字符”表示“一个或多个字符”：

4. 我可以安全地推断，如果文件为空，则它不是文本文件，因为它不包含一个或多个字符？

此文本块之后出现的所有问题都取决于推断在上述摘录中，一行被定义为“行”，并且应排除名称中包含“行”的其他三个定义：

5. “零或多行”中的“零”是否意味着如果文件包含一个或多个不以换行符终止的字符，它仍然可以被视为文本文件？

6. “零行或多行”是否意味着一旦单个“行”（0个或多个字符加上终止换行符）起作用，最后一行成为“不完整行”（一个或多个非文件末尾的换行符）？

7. “none [no line] 的长度是否可以超过 {LINE_MAX} 个字节，包括换行符”是否意味着文本文件中任何给定“行”中允许的字符数有限制（顺便说一句，值Ubuntu 18.04 和 FreeBSD 11.1 上的 LINE_MAX 是“2048”）？

直到现在才意识到你可以这样做：

: >> file

它似乎在功能上类似于：

touch file

为什么大多数资源似乎更喜欢触摸这个内置的 shell 有什么原因吗？