有很多问题/答案解释了 Linux 文件名等中不应该使用哪些字符。
我正在寻找一个非字母/数字字符,我可以将其放在文件名的前面,将其撞到 ls 的顶部,而不需要转义字符在命令行上处理它。
在 macOS 中,我在 GUI 中使用 <Filename> 进行排序,但是 < 在命令行中不太好用,当然,需要酌情对其进行转义。同样,-Filename- 在命令行上也不能很好地工作。
是否有一个特殊字符位于所有字母数字字符之前,对于(大多数)shell 没有特殊含义?
还是所有早期排序的字符都被占用了? :-( :-)
谢谢,阿什利。
PS 我见过 111- 使用过,但这不适合我......
答案1
在不知不觉中,你问了两个非常复杂的问题……引用和排序。
排序顺序由区域设置决定。首先是……不固定。
例如
$ touch Hello hello There there
$ LANG=C ls -1
Hello
There
hello
there
$ LANG=en_US ls -1
hello
Hello
there
There
接下来是引用问题。这非常依赖于 shell。所以在我的标准 shell (ksh99) 中,这!
是一个很好的字符。但这失败了bash
。
$ ls
!README 0 1 2 a b c
$ cat !README
hello
$ bash
bash-4.2$ cat !README
bash: !README: event not found
如果我们按照 ASCII 序列工作,第一个“有用”字符可能是+
。这在 ksh/bash/zsh/csh 中似乎不是特殊字符。
但由于引用是特定于 shell 的和某些命令可能会将 a+
作为参数(历史上head
是这样做的),我们永远无法确定。
当然,LANG 设置可以覆盖(所以+
不是第一个!)。
% LANG=en_US ls -1
0
1
2
a
b
c
+hello
所以,一般来说……没有特定的角色一定会排在第一位。
答案2
的排序顺序ls
取决于命令行选项和语言设置。如果你的 LANG 变量设置为自然语言,那么像 %、_、-、+ 或 : 这样的特殊字符(Bash 都不需要转义)很可能会被忽略。无论如何,LANG=en_US.UTF-8 就是这种情况。
然而,如果 LANG 设置为 C,文件名似乎是根据其字符的 ASCII 值进行排序的,并且上述特殊字符确实可以用于“提高”文件在输出中的位置ls
。例子:
$ LANG=C ls
%myfile
+myfile
-myfile
:myfile
_myfile
clr-debug-pipe-440205-1575025808-in
clr-debug-pipe-440205-1575025808-out
...
$ LANG=en_US.UTF-8 ls
clr-debug-pipe-440205-1575025808-in
clr-debug-pipe-440205-1575025808-out
dotnet-diagnostic-440205-1575025808-socket
f.py
%myfile
+myfile
-myfile
:myfile
_myfile
...
不要忘记有一些命令行选项根据时间戳、所有权等进行排序。