为什么*不*解析`ls`（以及怎么做）？

LS_COLORS='lc=
$ ls -l
total 8
-rw-r-----  1 lhunath  lhunath  19 Mar 27 10:47 a
-rw-r-----  1 lhunath  lhunath   0 Mar 27 10:47 a?newline
-rw-r-----  1 lhunath  lhunath   0 Mar 27 10:47 a space
:rc=:ec=
for f in *; do
    [[ -e $f ]] || continue
    ...
done
printf 'touch ./"%b"\n' "file\nname" "f i l e n a m e" |
    . /dev/stdin
ls -1q

f i l e n a m e  
file?name

IFS="
" ; printf "'%s'\n" $(ls -1q)

'f i l e n a m e'
'file
name'
{ printf %b $(printf \%04o `seq 0 127`) |
sed "/[^[-b]*/s///g
        s/\(.\)\(.\)/touch '?\v' '\t' '\n'\n/g" |
. /dev/stdin

echo '`ls` ?QUOTED `-m` COMMA,SEP'
ls -qm
echo ; echo 'NOW LITERAL - COMMA,SEP'
ls -m | cat
( set -- * ; printf "\nFILE COUNT: %s\n" $# )
}
:fi=:di=:' ls -l --color=always | cat -A
total 4$
drwxr-xr-x 1 mikeserv mikeserv 0 Jul 10 01:05 ^@^@^@^@dir^@^@^@/$
-rw-r--r-- 1 mikeserv mikeserv 4 Jul 10 02:18 ^@file1^@^@^@$
-rw-r--r-- 1 mikeserv mikeserv 0 Jul 10 01:08 ^@file2^@^@^@$
-rw-r--r-- 1 mikeserv mikeserv 0 Jul 10 02:27 ^@new$
line$
file^@^@^@$
^@

`ls` ?QUOTED `-m` COMMA,SEP
??\, ??^, ??`, ??b, [?\, [?\, ]?^, ]?^, _?`, _?`, a?b, a?b

NOW LITERAL - COMMA,SEP
?
 \, ?
     ^, ?
         `, ?
             b, [       \, [
\, ]    ^, ]
^, _    `, _
`, a    b, a
b

FILE COUNT: 12

for f in $(
        ls -1q |
        sed 's|[^-:/[:alnum:]]|[!-\:[:alnum:]]|g' |
        sort -u | {
                echo 'PRE-GLOB:' >&2
                tee /dev/fd/2
                printf '\nPOST-GLOB:\n' >&2
        }
) ; do
        printf "FILE #$((i=i+1)): '%s'\n" "$f"
done

PRE-GLOB:
[!-\:[:alnum:]][!-\:[:alnum:]][!-\:[:alnum:]]
[!-\:[:alnum:]][!-\:[:alnum:]]b
a[!-\:[:alnum:]]b

POST-GLOB:
FILE #1: '?
           \'
FILE #2: '?
           ^'
FILE #3: '?
           `'
FILE #4: '[     \'
FILE #5: '[
\'
FILE #6: ']     ^'
FILE #7: ']
^'
FILE #8: '_     `'
FILE #9: '_
`'
FILE #10: '?
            b'
FILE #11: 'a    b'
FILE #12: 'a
b'

#v#note: to do this fully portably substitute an actual newline \#v#
#v#for 'n' for the first sed invocation#v#
cd ..
find ././ -exec ls -1ldin {} + |
sed -e '\| *\./\./|{s||\n.///|;i///' -e \} |
sed 'N;s|\(\n\)///|///|;$s|$|///|;P;D'

###OUTPUT

152398 drwxr-xr-x 1 1000 1000        72 Jun 24 14:49
.///testls///

152399 -rw-r--r-- 1 1000 1000         0 Jun 24 14:49
.///testls/?
            \///

152402 -rw-r--r-- 1 1000 1000         0 Jun 24 14:49
.///testls/?
            ^///

152405 -rw-r--r-- 1 1000 1000         0 Jun 24 14:49
.///testls/?
        `///
...

ls -1iq | 
sed '/ .*/s///;s/^/-inum /;$!s/$/ -o /' | 
tr -d '\n' | 
xargs find

ls --quoting-style=WORD

ls -1iq | grep -o '^ *[0-9]*'

#1 楼

我一点都不相信这一点，但是为了争辩，让我们假设，如果您准备好进行充分的努力，即使面对“对手”，也可以可靠地解析ls的输出。谁知道您编写的代码，并故意选择旨在破坏该文件名的文件名。

即使您可以做到，但这仍然不是一个好主意。

Bourne shell是不是一门好语言。除非极端的可移植性比任何其他因素（例如autoconf）都重要，否则它不应该用于任何复杂的事情。

我声称，如果您遇到解析ls的输出似乎存在的问题就像shell脚本的阻力最小的路径一样，这有力地表明您所做的一切对于shell来说都太复杂了，您应该用Perl或Python重写整个过程。这是您使用Python编写的最后一个程序：

 import os, sys
for subdir, dirs, files in os.walk("."):
    for f in dirs + files:
      ino = os.lstat(os.path.join(subdir, f)).st_ino
      sys.stdout.write("%d %s %s\n" % (ino, subdir, f))
 

此文件名中的不寻常字符没有任何问题-输出的模棱两可与ls的输出模棱两可的方式相同，但是在“真实”程序（与此类演示相对）中无关紧要同样重要，与您所写的内容形成鲜明对比的是，从现在起六个月后，它仍然有意义，并且在需要时可以轻松进行修改，以完全使用os.path.join(subdir, f)的结果。做一些稍微不同的事情。举例说明，假设您发现需要排除点文件和编辑器备份，并按字母顺序按基名称处理所有内容：

 import os, sys
filelist = []
for subdir, dirs, files in os.walk("."):
    for f in dirs + files:
        if f[0] == '.' or f[-1] == '~': continue
        lstat = os.lstat(os.path.join(subdir, f))
        filelist.append((f, subdir, lstat.st_ino))

filelist.sort(key = lambda x: x[0])
for f, subdir, ino in filelist: 
   sys.stdout.write("%d %s %s\n" % (ino, subdir, f))
 

#2 楼

对该链接的引用很多，因为信息完全准确，而且已经存在很长时间了。


ls用glob字符替换了不可打印的字符是，但是这些字符不在实际的文件名中。为什么这么重要？ 2个原因：


如果将该文件名传递给程序，则该文件名实际上不存在。它必须扩展glob才能获取真实的文件名。
文件glob可能匹配多个文件。

例如：

$ touch a$'\t'b
$ touch a$'\n'b
$ ls -1
a?b
a?b

请注意，我们有2个看起来完全一样的文件。如果将它们都表示为a?b，您将如何区分它们？



当ls返回包含shell glob的文件名列表时，作者称其为garbling文件名。使用Shell Glob检索文件列表！


这里有区别。如图所示，当您恢复一个glob时，该glob可能会匹配多个文件。但是，当遍历与glob匹配的结果时，您将获得确切的文件，而不是glob。例如，

$ for file in *; do printf '%s' "$file" | xxd; done
0000000: 6109 62                                  a.b
0000000: 610a 62                                  a.b

请注意，xxd输出如何显示$file包含原始字符\t和\n，而不是?。

如果使用ls，则会得到以下内容：

for file in $(ls -1q); do printf '%s' "$file" | xxd; done
0000000: 613f 62                                  a?b
0000000: 613f 62                                  a?b

“无论如何我都要进行迭代，为什么不使用ls？”

您给出的示例实际上没有用。看起来好像可以，但是不起作用。

我指的是：

 for f in $(ls -1q | tr " " "?") ; do [ -f "$f" ] && echo "./$f" ; done

我创建了目录带有一堆文件名：

$ for file in *; do printf '%s' "$file" | xxd; done
0000000: 6120 62                                  a b
0000000: 6120 2062                                a  b
0000000: 61e2 8082 62                             a...b
0000000: 61e2 8083 62                             a...b
0000000: 6109 62                                  a.b
0000000: 610a 62                                  a.b

运行我的代码时，我得到的是：

$ for f in $(ls -1q | tr " " "?") ; do [ -f "$f" ] && echo "./$f" ; done
./a b
./a b

其余文件放在哪里？

让我们试试看吧：

$ for f in $(ls -1q | tr " " "?") ; do stat --format='%n' "./$f"; done
stat: cannot stat ‘./a?b’: No such file or directory
stat: cannot stat ‘./a??b’: No such file or directory
./a b
./a b
stat: cannot stat ‘./a?b’: No such file or directory
stat: cannot stat ‘./a?b’: No such file or directory

现在让我们使用实际的glob：

$ for f in *; do stat --format='%n' "./$f"; done
./a b
./a  b
./a b
./a b
./a b
./a
b

用bash

上面的示例是我的普通shell zsh。当我用bash重复该过程时，您的示例得到另一组完全不同的结果：

同一组文件：

$ for file in *; do printf '%s' "$file" | xxd; done
0000000: 6120 62                                  a b
0000000: 6120 2062                                a  b
0000000: 61e2 8082 62                             a...b
0000000: 61e2 8083 62                             a...b
0000000: 6109 62                                  a.b
0000000: 610a 62                                  a.b

与您的代码截然不同的结果：

for f in $(ls -1q | tr " " "?") ; do stat --format='%n' "./$f"; done
./a b
./a b
./a b
./a b
./a
b
./a  b
./a b
./a b
./a b
./a b
./a b
./a b
./a
b
./a b
./a b
./a b
./a b
./a
b

使用Shell Glob，它可以很好地工作：

$ for f in *; do stat --format='%n' "./$f"; done
./a b
./a  b
./a b
./a b
./a b
./a
b

bash如此行为的原因可以追溯到我在回答开始时提出的观点之一：“文件glob可能匹配多个文件”。

ls返回的是同一个glob（ a?b）用于几个文件，因此每次扩展此glob时，我们都会获得与之匹配的每个文件。


如何重新创建我使用的文件列表：

touch 'a b' 'a  b' a$'\xe2\x80\x82'b a$'\xe2\x80\x83'b a$'\t'b a$'\n'b

十六进制代码是UTF-8 NBSP字符。

#3 楼

ls -q的输出根本不是glob。它使用?表示“此处存在无法直接显示的字符”。 glob使用?表示“此处允许任何字符”。

glob具有其他特殊字符（至少*和[]，并且在[]对内还有更多特殊字符）。 ls -q不能逃脱这些错误。

$ touch x '[x]'
$ ls -1q
[x]
x

如果处理ls -1q输出，则会有一组glob并对其进行扩展，不仅会得到两次x，而且会完全错过[x]的。作为全局变量，它不匹配字符串。

ls -q的目的是使您的眼睛和/或终端免于疯狂的字符，而不是产生可反馈给外壳的内容。

#4 楼

让我们尝试简化一下：

$ touch a$'\n'b a$'\t'b 'a b'
$ ls
a b  a?b  a?b
$ IFS="
"
$ set -- $(ls -1q | uniq)
$ echo "Total files in shell array: $#"
Total files in shell array: 4

看到了吗？那里已经错了。有3个文件，但bash报告了4个文件。这是因为给set提供了ls生成的glob，这些glob在传递给set之前由外壳程序进行了扩展。这就是为什么您得到以下内容的原因：

$ for x ; do
>     printf 'File #%d: %s\n' $((i=$i+1)) "$x"
> done
File #1: a b
File #2: a b
File #3: a    b
File #4: a
b

或者，如果您愿意：

$ printf ./%s\0 "$@" |
> od -A n -c -w1 |
> sed -n '/ \{1,3\}/s///;H
> /\0/{g;s///;s/\n//gp;s/.*//;h}'
./a b
./a b
./a\tb
./a\nb

以上已运行在bash 4.2.45上。

#5 楼

答案很简单：ls的特殊情况必须要胜过任何可能的好处。如果不解析ls输出，则可以避免这些特殊情况。

这里的口头禅是从不信任用户文件系统（相当于从不信任用户输入）。如果有一种方法始终可以100％确定性地起作用，那么即使ls所做的相同但不确定性较低，它也应该是您首选的方法。我将不涉及技术细节，因为这些细节已被terdon和Patrick广泛涵盖。我知道，由于在重要的（可能是昂贵的）交易中使用ls的风险，而我的工作/声望很高，因此，如果可以避免的话，我会优先选择那些没有不确定性的解决方案。

我知道有些人比确定性更喜欢冒险，但是我已经提交了错误报告。

#6 楼

人们说从不做某事的原因不一定是因为绝对不能正确地做某事。我们也许可以这样做，但是它在空间或时间上都可能更复杂，效率更低。例如，最好说“永远不要在x86组装中构建大型的电子商务后端”。

现在解决当前的问题：正如您所展示的，您可以创建一个解决方案，解析ls并给出正确的结果-因此正确性不是问题。

更复杂吗？是的，但是我们可以将其隐藏在辅助函数的后面。

所以现在要提高效率：

空间效率：您的解决方案依靠uniq来过滤出重复项，因此我们不能懒惰地生成结果。因此，O(1)与O(n)或两者都具有O(n)。时间效率：最好的情况uniq使用哈希图方法，因此在采购的元素数量上仍然有O(n)算法，尽管它是O(n log n)。

现在是真正的问题：虽然您的算法看起来还不错，但我还是非常谨慎地使用采购的元素而不是n的元素。因为那确实有很大的不同。假设您有一个文件\n\n，它将导致??出现问题，因此请匹配清单中的每2个字符文件。有趣的是，如果您还有另一个文件\n\r，该文件也将导致??，并且还返回所有2个字符文件。指数而不是线性行为肯定会被视为“更糟糕的运行时行为”。这是一种实用算法与您在理论CS期刊上撰写论文的算法之间的区别。

每个人都喜欢示例吗？开始了。创建一个名为“ test”的文件夹，并在该文件夹所在的目录中使用此python脚本。

#!/usr/bin/env python3
import itertools
dir = "test/"
filename_length = 3
options = "\a\b\t\n\v\f\r"

for filename in itertools.product(options, repeat=filename_length):
        open(dir + ''.join(filename), "a").close()

唯一要做的就是为7个字符生成所有长度为3的乘积。高中数学告诉我们，应该是343个文件。那么应该很快就能打印出来，所以让我们来看一下：

time for f in *; do stat --format='%n' "./$f" >/dev/null; done
real    0m0.508s
user    0m0.051s
sys 0m0.480s

现在让我们尝试您的第一个解决方案，因为我真的不能得到这个

eval set -- $(ls -1qrR ././ | tr ' ' '?' |
sed -e '\|^\(\.\{,1\}\)/\.\(/.*\):|{' -e \
        's///;\|/$|!s|.*|&/|;h;s/.*//;b}' -e \
        '/..*/!d;G;s/\(.*\)\n\(.*\)//' -e \
        "s/'/'\\''/g;s/.*/'&'/;s/?/'[\"?$IFS\"]'/g" |
uniq)

这里的东西可以在Linux Mint 16上工作（我认为这种方法的实用性足以说明问题）。

无论如何，因为上述内容非常多对结果进行过滤后，较早的解决方案至少应与较晚的解决方案一样快（该解决方案中没有inode技巧，但这些技巧不可靠，因此您会放弃正确性）。

现在

time for f in $(ls -1q | tr " " "?") ; do stat --format='%n' "./$f" >/dev/null; done

需要多长时间？好吧，我真的不知道，检查343 ^ 343文件名需要一些时间-在宇宙热死之后，我会告诉您。

#7 楼

OP的陈述的意图已解决

序言和原始答案的依据†于2015-05-18

mikeserv（OP）在对他的问题的最新更新中表示：“我确实认为遗憾的是，我首先问了这个问题，指出了错误信息的根源，但不幸的是，这里最受推崇的答案在很大程度上是误导。”

我感到很遗憾，因为我花了很多时间试图弄清楚如何解释我的意思，而在重新阅读问题时才发现这一点。这个问题最终导致“ [引起讨论，而不是回答””‡，最终导致大约18K的文本（仅就问题而言，就是要清楚），即使是博客帖子也是如此。

但是StackExchange不是您的肥皂盒，也不是您的博客。但是，实际上，您至少已将其用作两者。人们最终花费大量时间回答您的“ To-Point-Out”，而不是回答人们的实际问题。在这一点上，我将标记该问题不适合我们的格式，因为OP明确表示它根本不打算成为一个问题。

此时，我不确定我的答案是否正确。可能不是，但这是针对您的一些问题，也许对其他人可能是一个有用的答案；初学者会振作起来，一旦经验丰富，其中一些“不做”就会变成“有时做”。 :)

作为一般规则...

请原谅剩余的粗糙边缘；我已经在此上花费了太多时间...而不是直接引用OP（如最初的意图），我将尝试进行总结和解释。

[考虑到我的原始回答后，大部分都在重做]经考虑后，我认为我误解了OP对我回答的问题的重视；但是，提出的要点已经提出，并且我留下的答案基本上是完整的，因为我相信这些答案是对的，并且可以解决我在其他情况下以及针对初学者的建议中提出的问题。 br />
原始帖子以几种方式询问为什么各种文章都提供了建议，例如“不要解析ls输出”或“您绝对不要解析ls输出”，等等。

我对这个问题的建议解决方法是，这种陈述的实例只是一个成语的例子，用稍微不同的方式表达，其中绝对量词与命令式（例如，«don 't [ever] X»，«[您应该]永远是Y»，«[一个人应该永远不要Z»]来形成旨在用作一般规则或准则的陈述，特别是当给那些刚接触主题的陈述或准则时，这些陈述的表述形式显然不是绝对的真理。

当您开始学习新的主题时，除非您对为什么可能需要做其他事情有很好的了解，否则，明智的做法是，毫无例外地简单地遵循公认的一般规则，除非在经验丰富的人的指导下进行。随着技能和经验的提高，您将能够进一步确定规则何时以及是否适用于任何特定情况。一旦您掌握了相当多的经验，就可能首先了解通用规则背后的原因，然后，您可以开始使用自己的判断来决定该规则背后的原因是否适用以及适用于何种水平这种情况，以及是否存在最重要的问题。

那时候专家也许会选择违反“规则”来做事。但这并不会使它们成为“规则”。

因此，对于当前的话题：在我看来，仅仅是因为专家可能会完全违反此规则ack贬不一，我看不出有什么办法可以证明对初学者来说“有时”可以解析ls输出，因为：事实并非如此。或者，至少对于初学者而言，这样做当然是不合适的。

您总是将棋子放在中间；开场一招，一招；尽早进行城堡建造；主教前的骑士；边缘的骑士是冷酷的；并始终确保您可以完整了解计算结果！ （哇，对不起，累了，这是为了国际象棋StackExchange。）

规则，是要打破的吗？

在阅读有关主题的文章时，或可能被初学者阅读，通常您会看到以下内容：


“您永远不要做X。”
“永远不要做Q！”
“别做Z。”
“一个人应该总是做Y！”
“ C，无论如何。”

这些语句似乎在说明绝对和永恒的规则，不是。相反，这是一种陈述一般规则的方式[a.k.a. “指南”，“经验法则”，“基础知识”等]至少可以说是为可能正在阅读这些文章的初学者陈述它们的一种合适方法。但是，仅因为这些规则被说成是绝对的，所以这些规则当然不会约束专业人士和专家[他们很可能首先总结了这些规则，以此作为记录和传递在处理重复出现时所获得的知识的方式特定工艺中的问题。]

这些规则当然不会揭示专家如何处理一个复杂或细微的问题，例如，这些规则相互冲突。或首先导致该规则的担忧根本不适用。专家不害怕（或不应该害怕！）只是打破他们碰巧知道在特定情况下没有道理的规则。专家们一直在努力平衡其工作中的各种风险和担忧，并且必须经常使用自己的判断力来选择打破那些规则，必须权衡各种因素，而不能仅仅依靠规则表来遵循。以Goto为例：关于它们是否有害，已经有很长一段时间反复发生的争论。 （是的，永远不要使用gotos。; D）

模态命题

一个奇怪的特征，至少在英语中，我想在许多其他语言中，一般规则是，它们以与情态命题相同的形式陈述，但是领域内的专家愿意为情况给出一般规则，同时知道他们会在适当的时候违反规则。因此，显然，这些语句并不等同于模态逻辑中的相同语句。

这就是为什么我说它们必须只是惯用语。这些规则不是真正地成为“从不”或“永远”的情况，而通常是用来编纂一般指导方针，这些指导方针往往适用于各种情况，并且当初学者盲目地遵循它们时，很可能会导致比初学者无缘无故地选择与他们对抗效果更好。有时，他们将规则编纂成规则，只是导致不合格的结果，而不是违反规则时伴随错误选择而导致的彻底失败。

因此，一般规则并不是表面上出现的绝对模态命题，而是在隐含标准样板的情况下给出规则的一种简便方法，如下所示：

除非您有能够在特定情况下判断该准则是错误的，并向自己证明自己是对的，然后使用$ {RULE}

当然可以在其中替换“从不解析ls输出” $ {RULE}的位置。 :)

哦，是的！那么解析ls输出呢？那么，鉴于所有这些……我认为，很明显，这条规则是一个好规则。首先，如上所述，真正的规则必须理解为习惯用法...

但是，不仅如此，您不仅必须非常擅长使用shell脚本来了解它是否可以在某些特定情况下会损坏。同样，当您试图在测试中打破它时，要告诉您它弄错了，也需要同样多的技巧！而且，我有信心地说，此类文章的绝大多数潜在读者（提供诸如“不要解析ls的输出！”之类的建议）不能做那些事情，而那些具备这种技巧的人可能会意识到他们自己搞定了，仍然无视规则。

但是……只是看这个问题，甚至那些可能确实有这种技能的人怎么也认为这样做是一个错误的选择；以及问题的作者花了多少精力才了解当前最好的例子！我向您保证这个问题很难解决，那里有99％的人会弄错它，而且结果可能非常糟糕！即使确定的方法被证明是一个好方法，直到它（或另一个）解析想法被IT /开发人员整体采纳，经受了很多测试（尤其是时间的考验），最后设法升级为“通用技术”状态时，很可能很多人可能会尝试它，并把它弄错……带来灾难性的后果。

所以，我最后一次重申……。尤其是在这种情况下，这就是为什么“永不解析ls输出！”

[更新2014-05-18：阐明了回答OP意见的答案的理由（以上）；以下是响应OP对昨天问题的补充]。

[UPDATE 2014-11-10：添加了标题和重组/重构的内容；并且：重新格式化，改写，澄清和确定...“简明扼要” ...我本来只是为了进行清理，尽管这样做确实有点重做。我把它放在一个遗憾的状态，所以我主要是试图给它一些命令。我确实觉得重要的是要保持第一部分的完整。因此，这里只有两个较小的更改，多余的“但是”被删除了，并强调了“那个”。]

†我原本打算仅以此作为对原始内容的澄清；但在反思后决定了其他补充内容

‡有关帖子的指南，请参见https://unix.stackexchange.com/tour

#8 楼

在某些情况下是否可以解析ls的输出？当然。从目录中提取索引节点编号列表的想法是一个很好的例子-如果您知道实现的ls支持-q，因此每个文件将只产生一行输出，而您所需的就是索引节点编号，并将其解析ls -Rai1q输出中肯定不是一个可行的解决方案。当然，如果作者以前从未听过诸如“从不解析ls的输出”之类的建议，他可能不会考虑其中包含换行符的文件名，因此可能会忽略“ q”，因此在这种情况下，代码可能会被巧妙地破坏-因此，即使在解析ls的输出是合理的情况下，此建议仍然有用。

广义来说，当新手使用shell脚本时试图让脚本找出（例如）目录中最大的文件是什么，或者目录中最近修改的文件是什么，他的第一个直觉是解析ls的输出-可以理解，因为ls是第一个文件之一命令新手学习。

不幸的是，这种本能是错误的，并且这种方法被打破了。更不幸的是，它被巧妙地破坏了-在大多数情况下都可以使用，但是在某些情况下可能会失败，而这种情况可能会被那些了解代码的人利用。

新手可能会认为ls -s | sort -n | tail -n 1 | awk '{print }'是一个获取目录中最大文件的方法。它可以正常工作，直到您的文件名中带有空格为止。

确定，那么ls -s | sort -n | tail -n 1 | sed 's/[^ ]* *[0-9]* *//'怎么样？正常工作，直到您的文件名中包含换行符为止。

当文件名中有换行符时，将-q添加到ls的参数是否有帮助？看起来似乎确实如此，直到您在文件名的同一位置有2个不同的文件中都包含不可打印的字符，然后ls的输出无法让您区分出哪一个最大。更糟糕的是，为了扩展“？”，他可能会求助于外壳程序的eval-如果他命中了一个名为例如

foo`/tmp/malicious_script`bar

的文件，则会引起问题。 --quoting-style=shell有帮助吗（如果您的ls甚至支持）？不，仍然显示？对于不可打印的字符，因此仍然不清楚多场比赛中哪一场最大。 --quoting-style=literal？不，一样。如果只需要清楚地打印最大文件的名称，则--quoting-style=locale或--quoting-style=c可能会有所帮助，但是如果以后需要对文件进行某些操作，则可能不会帮忙-撤销引用并返回到实际目录将是一堆代码文件名，这样您就可以将其传递给gzip。

在所有工作结束时，即使他拥有的文件名对所有可能的文件名都是安全且正确的，也不可读且无法维护，并且可以用python或perl或ruby更加轻松，安全且可读地完成。

甚至使用其他shell工具-浮现在脑海，我认为这应该可以解决问题：

find . -type f -printf "%s %fq4312078q" | sort -nz | awk 'BEGIN{RS="q4312078q"} END{sub(/[0-9]* /, "", q4312078q); print}'

并且至少应与--quoting-style一样轻便。

#9 楼

我“不解析ls”是因为：


文件名可以包含除/和NUL（0x00）以外的任何ASCII字符。 ls输出奇怪字符的多字符表示形式。在将文件名传递到另一个程序之前，必须将其反转（撤消）。


ls输出SPACE（“ ”），NewLine（^J）和其他“表单控件”字符从字面上的文件名。在后续处理中必须格外小心。所有变量必须加引号。


在一定的时间长度后，ls的日期表示形式从3个字段（“ mmm dd HH:MM”）更改为1个字段（“ yyyy”），并且所有随后的字段将重新编号。


＃1原因不是通过“解析ls”获取有关文件的信息：还有一种更好的方法！
find命令可以是用于选择文件，并带有-print0选项，生成一个文件名列表（完整的奇怪和表单控制字符），由NUL 0x00字节分隔。
带有“ xargs”选项的-0命令将消耗NUL的列表文件名，并将它们（再次完整无缺）传递给在command命令行上指定的xargs。 command甚至可以是bash脚本。
给定文件名列表的stat命令可以以您可以指定的格式输出任何文件信息。
请阅读man find xargs stat。
对于傻笑，阅读man ls并尝试查看如何保证可解析性