为什么:
选择冒号 ( ) 作为路径分隔符?
请注意,我的意思是“路径分隔符”而不是“目录分隔符”。路径分隔符是放置在PATH
环境变量中条目之间的符号。
PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:..."
^ this symbol
Run Code Online (Sandbox Code Playgroud)
计算机和软件中的一切都曾经是某人在某个地方做出的深思熟虑的决定。例如为什么波浪号代表家庭目录(以及为什么 hjkl 代表 vi 中的方向键)。我想知道这个决定的背景。
一些随机的事实:
将冒号作为路径分隔符意味着不能将名称中带有冒号的目录添加到路径中。
来自 POSIX:
由于
<colon>
是此上下文中的分隔符,因此可能在 PATH 中使用的目录名称不应包含<colon>
字符。
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
似乎不可能逃脱结肠。来自 Stack Overflow 的 @Random832 检查了处理 PATH 的源代码,并没有发现任何转义机制。
小智 6
经过一番挖掘,我没有真正的答案,但至少有一些历史事实支持的新信息可以添加到这次对话中。
这是 Peter Chubb在他的一次关于 shell 的演讲中,在 19:00 左右,你可以听到他提到为什么e
unix shell 中默认编辑器的别名是这个。这是因为较旧的终端不那么舒适或易于使用,并且在它们上打字是一种不愉快的体验。
在这种情况下,他提到了一个精确的模型,即电传打字机 Model 33。
经过一些研究,我发现这台机器只能让你在 64 个字符池中进行选择,甚至不完全支持 US ASCII,2 的 6 个字符的幂,它是一个 6 位组合。
事实上,这台机器与 ASCII 完全没有关系,这意味着它甚至不只支持 ASCII 的前 64 个字符,它只是用于一组完全不相关的输入,并且可能不是标准的(对于我们的现代时代)集的字符。
ASR 33 电传打字机可以打印 64 个字符,仅允许大写字母、数字和符号。来源
这只是证明它绝对不是 US ASCII,因为要支持大写字母,您确实需要超过 6 位,大写字母超出了 64 个字符标记(或者如果您想遵循表格,则为十进制值 63)
0 NUL 16 DLE 32 48 0 64 @ 80 P 96 ` 112 p
1 SOH 17 DC1 33 ! 49 1 65 A 81 Q 97 a 113 q
2 STX 18 DC2 34 " 50 2 66 B 82 R 98 b 114 r
3 ETX 19 DC3 35 # 51 3 67 C 83 S 99 c 115 s
4 EOT 20 DC4 36 $ 52 4 68 D 84 T 100 d 116 t
5 ENQ 21 NAK 37 % 53 5 69 E 85 U 101 e 117 u
6 ACK 22 SYN 38 & 54 6 70 F 86 V 102 f 118 v
7 BEL 23 ETB 39 ' 55 7 71 G 87 W 103 g 119 w
8 BS 24 CAN 40 ( 56 8 72 H 88 X 104 h 120 x
9 HT 25 EM 41 ) 57 9 73 I 89 Y 105 i 121 y
10 LF 26 SUB 42 * 58 : 74 J 90 Z 106 j 122 z
11 VT 27 ESC 43 + 59 ; 75 K 91 [ 107 k 123 {
12 FF 28 FS 44 , 60 < 76 L 92 \ 108 l 124 |
13 CR 29 GS 45 - 61 = 77 M 93 ] 109 m 125 }
14 SO 30 RS 46 . 62 > 78 N 94 ^ 110 n 126 ~
15 SI 31 US 47 / 63 ? 79 O 95 _ 111 o 127 DEL
Run Code Online (Sandbox Code Playgroud)
现在我们知道我们从这个东西中得到了 64 个字符,没有任何真正的标准来支持它们在编码表中,我们也没有小写字母,只有大写加符号和数字。
感谢这个网站,我可以向你展示这种键盘的输入布局
按下 SHIFT 你也会得到
还有更多关于如何对生成字符的物理连接进行编码的信息(该页面还阐明了 ASR33 和 ASCII 字符在位级别上是不同的)。
我认为有趣的是,没有{
或}
只有(
,)
这意味着可能创建子外壳是可以的,但创建新进程可能不是那么容易或终端允许的。
最后我认为没有真正科学的答案,可能是一个等待特殊含义的“自由”字符;不过有一件事是肯定的:shell 和终端比 ASCII 更古老,考虑 ASCII 或我们今天所知的任何编码表可能无法解开这个谜。