@XiLingHost deprecated 是暂时保留没有移除，但这个统读好久了。

@idealhs PowerShell 只是山寨了少部分 POSIX 命令（比如 ls ）的设计，不符合 POSIX ，原则上不提供任何兼容性。

mv 和 cp 之类的命令虽然被 POSIX 标准化，通常仍然是所谓的外部命令，用单独的程序而不是在 shell 内部实现。
一般 Linux 用 GNU coreutils ，BSD 的实现随系统自带，资源限制严格点的设备可以用 busybox 。
因为常用到几乎所有 POSIXy 系统都预装，所以一般用户可能不会发现这里的区别（除了 BSD 工具的兼容性）。
Windows 下一般用 MSYS 提供的 GNU coreutils 的移植，现在一般建议用 MSYS2 （连 shell 一起装好就有），或者包含 MSYS 的环境（比如 MsysGit ）。如果你只是找了个 bash 那么个 shell （ Windows 上能用的基本全是 MSYS/Cygwin 附带的，单独版本其实的还不好找），或者 xshell 这么一个终端模拟器（这个名字比较有误导性），那么自然是没有。

@libook UNIX 这种思路（包括管这种用户自行可以覆盖的 DAC 机制叫“权限”）很烂。多用户本来只是为了在系统中分配任务资源；就算是持久资源，owner 决定的也仅仅只是资源的生死（创建 /删除），rw 与其说是权限还不如说就只是个访问属性，而 x 根本就是个给 shell 偷懒用的标记。这些东西根本就算不上什么安全特性。
要考虑安全就不能依赖这种防君子不防小人的做法（你一个用户根本没法审计程序运行时会干什么）。这种情况就应该让专业的上，比如基于 MAC 的 SELinux 之类的玩意儿，然后限制程序可以访问的上下文。这类解决方案的 UI 的渣体验就是另一回事了。

@FrankHB 淦，合并回复的修改好像被吃了……
C++ 自带的数组和“字典”(std::unordered_map) 都能用 {} 初始化，而都用 [] 操作符访问元素。

@raptor 可能你学得语言还是不够多；你的说法显然不对：C++ 自带的数组和“字典”(std::unordered_map) 都用 [] 操作符访问元素。

严格来讲，理解偏差完全就不该是 PHP 的锅；问题来自数组(array) 这个概念本身。

array 这玩意儿作为数据结构在早年（ 1950 年代）就极其模糊，但硬要说一般的外延，就是所谓的关联数组(associative array) ：一个 key 对应到作为数组元素的 value 的映射。
用类 ALGOL 语言的习惯来讲，就是能用 [] 的里面塞 key 的东西，所谓 subscritable 。
至于这个 key 是个整数，来使 [] 里面放 key 取得元素能有明确 O(1) 时间复杂度的随机访问，那是实现细节。用连续存储的线性表实现叫向量(vector) 。
特别地，向量一般具有确定的静态空间上界。不具有上界限制的线性表叫串(string) 。（虽然严格来讲，数学上的串不一定在乎复杂度要求，不过不少算法实际上隐含了要求。）
其它实现可以有不同的计算复杂度性质。
例如二叉搜索树(BST) 可以实现平均 O(log n) 的元素访问，同时在插入和删除元素上比向量更优化。这种索引结构在 C++ 中叫 map ，会跟数学上的映射(map) 产生歧义；之后的一些其它语言改叫字典(dictionary) 。
而散列表(hash table) 能实现平摊(amortized) O(1) 的访问和增删操作。
另外还有 Illffe vector 等特定于实现而不常被应用直接使用的数据结构。

向量因为早年机器实现的开销较小的关系曾经流行过，例如 B 语言自带支持。然而自从抄了 B 的 C 把向量硬叫做数组以后，到处都乱了。
C 的流行影响了很多语言，导致这些语言设计中的词汇表混乱——该叫向量的不叫向量而叫数组，别的就顺带乾坤大挪移了。典型的像 C++ ，vector 被用于原本叫做 string 的数据结构上，而 string 则用作特指混了 char_traits 这种二道贩子实现细节私货的特定实现。
以 C 为中心在另一方面也是无耻的；考虑 1957 年就开工的 APL ，（虽然代码模样不咋地）人家混饭吃的核心、不知比你 vector 屌多少倍的 array 就这样被偷换概念了，好意思不？

所以 PHP 这种设计反而是文艺复兴，恢复了 array 历史上应有的本来面目。

题外话：
1.其实向量的 O(1)也就是形式上的。所以广泛使用向量实现数组的语言嘛……
像 C 都没保证下标访问的复杂度，所以实际上也没禁止实现使用树或者散列表实现内建数组。
C++倒是隐含了随机访问迭代器 O(1)访问要求，考虑到和内建指针以及数组的关系，实现基本别无选择。但这也不是正经的限制。
更要命的是一旦放在主存上，主流环境根本无法严格实现。
典型的宿主(hosted) 实现，不保证实时性，自然不直接提供这种物理上保证 O(1)的例程——比如程序跑一半可能切出去调度了。
即便不考虑那么流氓的情况，现代 CPU 上的缺页中断里可以允许用户编码明显不 O(1)的非平凡程序，现实也很可能一个程序跑一半换页了结果一个访问突然卡上几百万倍；或者可能有更倒霉的，比如正好放 swap 的机械硬盘有坏道但宿主系统装作系统完整可用的情况——实际上也根本没保证可终止，更别说 O(1)了。
2.如果忽略修改之类的副作用而只允许构造和访问元素，一元函数（更确切地，映射）和 subscritable 形式的数组同构，都可以用 → 类型构造器表达的类型为其定型(typing) 。所以纯函数式语言不强调数组，是根本不需要。

@yulon 所以你所谓的右边是个啥？“右边表达式”？
得了吧。
你到现在还不承认你混淆表达式和声明符的入门级错误。

我反对左边右边的笼统分法（而不只是左边具体是什么右边又是什么），首先是因为这东西也就是一种文法的实例（都算不上特例）——文法上极少有递归到自己的分类，可以说到处都构成文法的元素是“××”在“××”的左边或者右边（或者还有递归的），比如表达式中某个操作符和操作数之间的顺序关系。（考虑到操作符数量不少还有更多子类，划分优先级结合性之类辅助记忆倒是情有可原，起码没直球“左”“右”上来就那么白开水废话。）
声明的文法何德何能体现需要死记硬背的独特性？鼓吹这种死记硬背只会挖更多坑。
如果你非要说左边和右边，左边是声明指示符，而右边是可能带有初值符的声明符列表。声明符列表进一步 parse 才 reduce 掉逗号。
这种东西在标准里声明的形式文法里非常清楚，被你这么一描述反而引起混乱。
你所谓的左边也有问题。声明指示符就不只是表示类型，也可以是其它的。像 inline 这样的函数指示符，也是左边的一部分。
所以 [左边结果类型，右边表达式] 明显就没一个是对的。

关于声明的文法规则，我懒得抄，但是回答一些基本的问题，至少比你自己造个漏洞百出的来说，毫不费劲。
“为什么符号是声明符的一部分？”（我姑且理解所谓的符号是指 * ）——文法规定。
“不是类型的一部分”（我理解为类型指示符）——文法规定。
“为什么类型只用在左边写一次”（我理解为“左边”的声明指示符）——文法规定。

“因为标准所有人讲都一样，那么自己去看就好了”——不同版本的形式文法其实可能有修改，所以这里我都没对形式文法原文引用（讲清楚你的问题也还用不到那么具体）。
当然，跨语言的差异很可能更大。构成声明符的 * 在 C 的文法里叫 pointer ；这部分在 C++ 对应的叫 ptr-operator ，这个叫法引起歧义和违反 PL 传统，就比较山寨。正好，理解了 ptr-operator 里可以有 * 也可以有 &，OP 的直接问题就算是基本解决了。而你在这里和稀泥公然对着干，就很莫名其妙。

另一方面，硬说声明文法的独特性，那会涉及具体是什么的问题——这种划分声明指示符和声明符的设计的反人类味儿太冲了。而且确实也就 C 和 C++ 这样的过气古董设计里使用。
跟 B 语言引入 ++ -- 主要就是为了省代码长度（一开始我猜的，因为想不出技术好处；后来看 K. Thompson 的理由确实如此）一样，中缀声明符语法设计也算是一种复用左侧元素的“压缩”技术，实践上没什么别的技术优势。
这种设计非常不便于非形式地简单描述规则，反而逼得二道贩子出世。你这种错漏描述也是拜其所赐。

@yulon C 的初期设计可未必有 C++现在这么混乱，然而规定了也没卵用。
“奇怪语法删了很多”你这是在打 C 的脸么，K&R C 的无原型函数声明一开始就被标记过时结果 C23 才被提议移除： http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2841.htm 。

“不尝试去理解其中逻辑，只想着死记硬背”亏你说得出来。你所谓的左边右边根本就不是死记硬背，而是生造原本不在语言设计中的逻辑。
这反而才是你所谓的“精炼过的规则”。因为这种逻辑撑死只是覆盖了语言规则子集的二道贩子理解，并没能力涵盖原本的规则。
然而正经的实现又不可能迁就这种半吊子理解。按你“固然是没有问题的”说法，结果就是得两套共存。
（也不是说这算是你的独创。类似的二道贩子到处都是，还有各种二次创作的演绎，比这个更过分的公然颠倒黑白篡改原始设计都有，比如“C 没有对象”。）
这种状况市场上是验证过的，典型例子是谭浩强——这类二次创作讲啥啥不清楚，就是非常擅长和你类似的自以为是的发明，然而自己又 fork 不了语言规范自己开发实现当作一个新的方言，所以注定就是不入流。
有用户看到这种“个人选择”就往里跳，结果就是浪费时间凭空制造碎片。为了纠正二道贩子理解还得回炉，给正常教学和用户社区添乱。
所以吃饱了撑着推销这种错误理解？
选择半吊子发明的规则代替健全的规则，且不说理解多少内容——会支持这种思路的，本来就不算“学会”；这自然应当回炉，毫无疑问。

注意 DMR 和 BS 所谓的标准约束厂商说的是标准化过程中的问题，不表示其他用户就应该有更优先的来源覆盖标准作为语言规范的效力。
以为只有厂商才参考标准，正是这种学习思路下明确的误解。事实是不管什么用户想要报关于语言而不是方言的 bug ，首先参考的就是语言规范这种对任何想要符合规范的实现而言的规格说明书。
忽略规范的后果就是用方言偷换主题。你说 C 人家会有兴趣跟你讨论，你说我就要谭浩强 C ，除了有兴趣研究历史和挂婊数落的，几个人鸟你？
挂羊头卖狗肉还理直气壮，这就是道德问题了。

@yulon 指出你的问题就没花什么时间过脑子。显示的是自以为是的理解荼毒的状况。
(*signal(int sig, void (*func)(int)))(int) 是个声明符，压根就不是什么表达式。
我建议你把教会你这样混淆表达式和声明符语法的理解的文献都列出来，方便给人排雷。

int *a, b; 里的 *a 和 b 都是声明符，*当然是属于(appertain)a 的。但挨在声明符边上的语法元素是否同时影响整个声明又是另一回事，要推断出对声明了什么的影响还早得很，更别说从属还得消歧义的了（比如属性）。

排开混淆问题，这例子正好你是继续在给自己挖坑。
void (*f1(int sig, void (*func)(int)))(int), *(*f2(int sig, void (*func)(int)))(int);
——什么叫左边什么叫右边？右边是个什么？

@iseki 我先前可没评论谁具体应该说什么。我关心的是公众场合行为被容许的边界。
你回复的 @Chaoseslb 原话里说的是“可以”，隐含具体应该怎么做各人自担后果。
相对地，你直接使用了没有后退余地的祈使句，仿佛你表达的意见已经是天经地义的共识，这就串味得厉害了。
我之前都还没对项目的作者进行评论。现在我仍然认为这个案例至此还不值得我去 issue 针对（至少我不是直接受害者），但我倒是可以拿来举例说明为什么我同样会有意见：和你类似，这个项目的作者僭越了道德评价的有效范围，把私货传播到了公共领域。
区别是你也许只是无意间这么做罢了。不过这也不使你显得相对更高尚；相反，该项目作者起码（看上去）知道自己是在做什么，并且在 issue 里明确指出了下游可以消除影响的变通（尽管没事找事让用户凭空受到无妄之灾仍然很欠骂），这点理应比你的直线条惯性思维更应该受到褒扬。
“如果你认为跑到对应 issue 区域开骂是合理的，请自便”实质上回避你被指出的问题，这种跑题行径直觉上容易引起另外的不满。不过更直接的问题是你的“如果”就是妄自揣测，事实上等于没说。
我敦请停止无意义的道德评价。确定不应该在 issue 里做什么事情，ToS 应该够完善了。

@yulon 建议回炉重修 C 的声明语法。
C++的&、C++/CLI 的^，都是 C 的*声明符设计的直接扩展，区别无非是可以声明指针的指针而不能声明引用的引用。
而 C 事实上就从来就没什么左边结果类型右边表达式的语法要求。
一个权威实例：<signal.h>的 signal 函数的原型声明在 ISO C 原文中的写法：
void (*signal(int sig, void (*func)(int)))(int);
请自行脑补什么叫左边什么叫右边。
（顺便，所谓“右左法则”也是错的，实际的 parser 不照这个方式工作。）

@dongfang 不用解释这么多，言多必失。
对年轻人讲清楚最简单重要的一点即可：指针是对象类型的一类，引用是和对象类型的并列的一大类类型。
（我终于想起来这种经问题我怎么会没总结过……）
https://stackoverflow.com/a/54731129
你的说法的一些技术问题：
1.&作为声明符会和操作符混淆，首先是因为上下文到底是声明还是表达式就有可能混淆——你不能把不存在混淆的假设作前提。这种问题没法用括号消除（括号自己同时能构成声明符和操作符而具有歧义），像 C 的*（ C 的语法光是声明和表达式部分就不是 CFG ）。而 C++因为标点在各种上下文的滥用，远远严重得多。语言明确了消歧义规则也不表示没问题，例如很多时候不经过实例化根本就不能区分到底是不是 well-formed ，导致语法分析依赖语义的判断（实际的实现套路是把各种路径都试一遍看看是否恰好有一种是通的）。这个意义上来讲，C++基本上就没有传统意义上的语法(syntax)。当然，这个问题和 OP 的抱怨没有关系。
2.别名是过于笼统的说法，正经的“别名”（按提案和标准里的规则）是专属于 structural binding 的（虽然我有提过这个设计很烂）。而引用声明之后引入的是正儿八斤的变量，并不只是别名。
3.指针和引用首先是类型而不是类型的居留（如表达式的值）。
4.指针的值不保证是所谓“内存”中的“地址”。（先无视 memory 是不是该翻译成内存的问题。）函数指针就不保证值对应所谓内存中的地址；事实上标准中虽然提了函数地址，却根本就没扯清楚含义（跟对象指针有 memory model 和 object model 罩着不一样），至今云里雾里（但是因为先前 CWG 的低效我暂且没有心情去找茬）。
5.基本上所有的 C++编译器都不会用指针去实现引用，因为基本上在前端就已经把类型信息都消化完了。两者可能翻译成同样的 IR 并且可能二进制兼容，但翻译的路径是并行的，并非一个代替另一个。生成的代码里有 ISA 汇编意义上的指针，但和前端的指针完全两码事。
6.重写为#define a b 违反了比几乎所有语义规则原则性上都重要得多的 translation phase 的要求，基本上除非你把预处理器实现成一个完整的解释器都无法使用这种方式实现。

另外几个认为引用是指针的对号入座重修吧，不回了。

@vcfghtyjc 算了正经回一下 OP 吧。
引用虽然没什么大不了的，但是左值右值这种 1960 年代的经典基础常识理解不了，建议回炉，否则以后基本只能混所谓 GC 语言的饭了。
cf. https://en.wikipedia.org/wiki/Fundamental_Concepts_in_Programming_Languages
很少有单独语言特性的重要性超过这种基本设计。一个少数例外是 1930 年代的 lambda 。

一开始叫左右是因为 CPL 里的原始设计就是按文法性质分的。之后 BCPL 和 B 里就把意图解释明白了：
https://www.bell-labs.com/usr/dmr/www/bcpl.pdf
https://www.thinkage.ca/gcos/expl/b/manu/manu.html#Section6_2
C 也一样，C++只是多加了几种。
当然这个设计就结果上其实也不咋地，当年还有合并引用和左值的： http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1992/N0130.pdf ；很大原因是因为 C 的左值没算到类型系统里。

@siteshen 精神上最接近 GNU ……不说 Hurd （那个不算 Linux ），你把 Guix 之类的搁哪了？

@PureWhiteWu UOS 和 Deepin 功能不完全重合，Deepin 会有的一些新特性 UOS 就没有。当然你要用 x64 以外的架构那里面就只有 UOS 专业版支持了。
另外你记错了，UOS 开发者模式给 root 。忘记 root 密码进 grub 恢复权限还是 UOS 认证考试中的一题。

对大多数 Linux 用户适用：真要在有网的情况下挂个现成的恢复映像 chroot 修系统都不会的话，还是别 root 了。

@newmlp https://github.com/cplusplus/draft/issues/2601
你管这种叫“语法”？
https://github.com/cplusplus/draft/pull/790
还是我锄奸不够彻底？

@statumer 你这算啥，好歹算是理论上扯得通的。
看着 ISO/IEC 14882 扯什么 polymorphic class 就管 inclusion polymorphism 而对 parametric polymorphism (template) 和 ad-hoc polymorphism (coercion, overloading) 睁眼瞎就来气。
今天还刚婊过 structural bindings 不算 variables （放置 IEC 2382 的定义）就是设计者菜（搞得一开始都没法 capture ），除了能偷懒不改 decltype 的规则以外一点“好处”都没有。
当然这些比起 golang spec 这种指 object 叫 variable 的玩意儿来讲，血压上升效果还不那么明显。

@iseki 要么 fork 要么忍是什么义务？开源协议可没本事阻止用户婊 adware （物理），更何况那个项目用的协议根本就没提。