标签: conventions

编写命令行应用程序时是否有使用错误的指南？令我惊讶的是，我在谷歌搜索时没有找到任何东西。

特别是，我现在关心的问题是是否使用stdout或stderr用户何时使用非法参数调用程序。但是，非常感谢更全面的答案，因为这肯定不是需要明确规则来编写按照用户期望的方式运行的程序的唯一情况。

由于历史问题是关于主题的，我想我会问一个困扰我很长时间的问题，但我认识的人似乎都不知道答案。有谁知道前缀yy的历史意义是什么？lex 生成的大部分变量和函数都是以它开头的，比如yylval, 和yylex()。我还记得在yyrsa某处看到过一个实用程序，但现在在任何地方都找不到对它的引用。好奇心想知道！

Arch Linux SYNOPSIS部分中tar 的手册页开头为：

tar {A|c|d|r|t|u|x}[GnSkUWOmpsMBiajJzZhPlRvwo] [ARG...]

我完全理解，在这种情况下，这意味着必须给出花括号中的选项之一，因为它在手册页中说得更远。关于在互斥选项列表中使用{}是否存在某种标准或约定？

我所能找到的只是1998 年的用户组教程man，它说：

某些选项的选择列表有限。选择列表将以逗号分隔并放在大括号之间。

{选择1，选择2} {是，否}

似乎每个约定（例如来自 Open Group 的约定）或手册页都只描述方括号 ([) 或竖线 (|)。

我有一个外置硬盘，我想自动挂载。它会在我的笔记本电脑启动时出现。安装它的“正确”位置在哪里？

• /media/my-hd:/media未安装硬盘驱动器时，会出现一个空文件夹。
• /mnt/my-hd：我听说它/mnt本身应该用作临时安装点。例如，在 Arch 安装过程中会发生这种情况。

我注意到当我安装新应用程序时，有几个可能的目录将放置生成的二进制文件。

您可以使用打包管理器进行安装，使用 , 编译make，easy_install用于 Python 等。

我的$PATH样子如下：

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

是否有一些约定或规则来确定应将生成的二进制文件（或库）放置在哪个目录中？

我注意到当你编译源代码时，结果通常是/usr/local/bin/. 这是规则吗？

您能否根据二进制文件编写解释 Unix 哲学（设计和约定决策）的答案，以及为什么会这样（为什么不对所有二进制文件仅使用一个目录）

许多简单的命令 usingxargs可以重写为使用子外壳的命令。例如，这是我今天早些时候使用的东西，用于连接 中的 10 个最大的二进制文件/usr/bin，使用 subshel​​l 与 xargs 编写：

子外壳：

$ cat $(du -sh /usr/bin/* | sort -h | tail | cut -d "      " -f 2 | tr "\n" " ")

xargs：

$ du -sh /usr/bin/* | sort -h | tail | cut -d "      " -f 2 | tr "\n" " " | xargs cat

那么什么时候应该使用子shell，什么时候应该使用xargs？

笔记：

cut 的分隔符是一个硬制表符，显然在 SE 上无法正确显示。

保存可能被多个用户使用的共享脚本的常规目录是什么？

我已经阅读了标准文件系统层次结构的概述，但它似乎没有推荐用于存储共享脚本的位置。创建一个 /opt/scripts 目录似乎是一个合理的选择，但我想知道是否有一个标准的 UNIX 约定。

为了创建一个在 Windows 和 Linux 之间源代码级可移植并能很好地处理国际化的 C++ 程序，恕我直言，需要考虑三种主要编码：

• C++ 源代码的编码。
• 外部数据的编码。
• 字符串和文字的编码。

对于 C++ 源代码，实际上没有任何替代 UTF-8 和 BOM 的方法，至少如果标准输入和宽字符串文字应该在 Windows 平台上工作。没有 BOM 的 UTF-8 导致 Microsoft 的 Visual C++ 编译器为源代码假定 Windows ANSI 编码，这对于通过 UTF-8 输出很好std::cout，在有限的程度上起作用（Windows 控制台窗口在这里有很多错误）。但是，然后通过输入std::cin不起作用。

而对于外部数据UTF-8似乎是在事实上的标准。

但是，内部文字和字符串呢？在这里，我的印象是编码为 UTF-8 的窄字符串是 Linux 中的常见约定。但最近有两个不同的人提出了不同的说法，一个声称 Linux 中国际应用程序中内部字符串的通用约定是 UTF-32，另一个只是声称 Unix 和 Linux 在这方面存在一些未指明的差异。

作为一个在业余爱好基础上稍微摆弄一下旨在抽象出 Windows/Linux 在这方面的差异的微型库的人，我……不得不具体问一下

• 在程序中表示字符串的常见 Linux 约定是什么？

我很确定有一个普遍的约定，这种约定非常普遍，以至于这个问题有一个真正的答案™。

一个示例显示例如如何在 Linux 上传统地反转字符串（直接使用 UTF-8 很复杂，但大概是由 Linux 中的事实上的标准函数完成的？），也很好，即，作为问题，这个 C++ 程序的 Linux 传统版本是什么（给定的代码适用于 Latin-1 作为 C++ 窄文本执行字符集）：

#include …

我仍然无法弄清楚许多缩写词的起源，例如rc, rc.d, share, proc...

我听说有人说rc是“运行命令”，.d是目录，但我不确定这是真的。

是否有表格解释它们的来源？

对 linux 内核进行编号的约定是什么？AFAIK，数字似乎永远不会减少。但是，我想我已经看到了三种方案

• 2.6.32-29
• 2.6.32-29.58
• 2.6.11.10

任何人都可以解释这些数字和格式的解释是什么？