Questions tagged «posix»

POSIX是可移植操作系统接口(Portable Operating System Interface)的缩写,可移植操作系统接口是IEEE为维护操作系统之间的兼容性而指定的一系列标准。



3
系统文件应该小写吗,这是任何标准的一部分(例如POSIX)吗?
我公司转售了一个品牌名称为大小写混合的应用程序,例如“ ApplicationName”。 应用程序的安装程序会在此标准中创建所有路径和文件名。例如,主目录是/opt/ApplicationName,调用了init文件,ApplicationName因此我必须运行service ApplicationName status,依此类推。 对我来说,这违反了所有明智的约定,我认为文件和目录应该全部使用小写(在其他应用程序中(例如MySQL)有先例,MySQL的文件和目录都被称为mysql,甚至像Apache和Tomcat这样的应用程序都取消了前面的内容大写字母)。 如果我将其作为错误报告提出,我想提出一个更有力的论据,而不仅仅是“我认为这是错误的”。那么,是否在类似POSIX标准的文件中规定类似的系统文件应为小写?

11
为什么Shell无法自动修复“猫的无用使用”?[关闭]
很多人使用单行代码和包含代码的脚本 cat "$MYFILE" | command1 | command2 > "$OUTPUT" 第cat一种通常称为“猫的无用使用”,因为从技术上讲,它需要启动一个新进程(通常是/usr/bin/cat),如果已经执行了该命令,则可以避免这种情况 < "$MYFILE" command1 | command2 > "$OUTPUT" 因为shell只需启动command1,只需将其stdin指向给定文件即可。 Shell为什么不自动执行此转换?我觉得“猫的无用使用”语法更容易阅读,shell应该有足够的信息来自动摆脱无用的cat。的cat是在POSIX标准定义,因此壳应该允许执行它在内部,而不是在路径使用二进制的。Shell甚至可以只包含一个参数版本的实现,并在路径中回退到二进制。

4
是否允许外壳优化出无用的终止命令?
如果要求外壳程序执行已知终止的可能无用的(或部分无用的)命令(例如)cat hugeregularfile.txt > /dev/null,它可以跳过该命令的执行(或执行便宜的等效 命令touch -a hugeregularfile.txt)吗? 更笼统地说,shell是否类似于C编译器,只要可以在外部观察到的行为就如同抽象机对其进行了评估一样,就可以对源代码执行任何转换? 编辑 Nota Bene:我最初提出的问题有一个标题,询问是否允许 shell 进行这些优化,而不是是否应该甚至可以执行这些优化的实现。我对理论比对实践更感兴趣,尽管都欢迎。

2
什么是实现流程替代的可移植(POSIX)方法?
一些shell(例如bash)支持Process Substitution,这是一种将过程输出显示为文件的方式,如下所示: $ diff <(sort file1) <(sort file2) 但是,此构造不是POSIX,因此不可移植。如何处理替代的实现POSIX -友好的方式(即其中一个在工作/bin/sh)? 注意:问题不是问如何区分两个排序的文件-这只是一个演示流程替换的人为例子!

3
shellcheck建议不要使用basename:为什么?
我正在尝试shellcheck。 我有这样的东西 basename "${OPENSSL}" 我得到以下建议 Use parameter expansion instead, such as ${var##*/}. 从实际的角度来看,我认为没有区别 $ export OPENSSL=/opt/local/bin/openssl $ basename ${OPENSSL} openssl $ echo ${OPENSSL##*/} openssl 由于basename是POSIX规范中的内容,因此我不认为这是最佳实践。有什么提示吗?

4
sed在OSX插入的特定行
所以我在Linux上使用'sed'已有一段时间了,但是由于'POSIX sed'和'GNU sed'的差别很小,因此尝试在OSX上使用它有点困难。目前,我正在努力在特定行号后插入一行文本。(在这种情况下,第4行) 在linux上,我会这样做: sed --in-place "4 a\ mode '0755'" file.txt 因此,在OSX上,我尝试了以下操作: sed -i "" "4 a\ mode '0755'" file.txt 但是,这总是给我“命令末尾\后面的多余字符”错误。有什么主意吗?我有错字吗?还是我不了解sed版本之间的另一个区别?
24 sed  osx  posix  gnu 

1
从什么时候起POSIX和GNU rm不删除/?
几年来,除非使用选项调用GNU rm实用程序,/否则它不会删除--no-preserve-root。但是,该命令rm -rf /在很长一段时间内一直被隐瞒在集体潜意识中,人们仍然经常将其称为“可怕”命令。 我想知道何时rm无法删除此规则/。我检查了POSIX规范,可以看到虽然POSIX:2008包含此安全功能,但POSIX:2001没有。由于POSIX规范的在线版本会不时更新,因此每个新的子发行版中,我还检查了回溯机器,找到了2010年以来POSIX:2008的相关页面,并能够确认rm无法删除的规则/当时已经列出。 因此,我的问题是: 何时将rm无法删除的规则/添加到POSIX规范中?它是在Single UNIX Specification版本4的原始2008版本中还是在修订版中添加的? 该限制何时添加到GNU rm?我很确定这是在将它添加到POSIX之前,但是什么时候发生的呢?
23 rm  posix  history  gnu 

4
POSIX兼容的方法来获取与用户ID关联的用户名
我经常想获取与用户ID相关联的登录名,并且由于事实证明这是一种常见用例,因此我决定编写一个Shell函数来完成此操作。当我主要使用GNU / Linux发行版时,我尝试编写脚本以使其尽可能具有可移植性,并检查我在做什么与POSIX兼容。 解析 /etc/passwd 我尝试的第一种方法是解析/etc/passwd(使用awk)。 awk -v uid="$uid" -F: '$3 == uid {print $1}' /etc/passwd 但是,这种方法的问题在于登录名可能不是本地的,例如,用户身份验证可以通过NIS或LDAP进行。 使用getent命令 使用getent passwd比解析更具可移植性,/etc/passwd因为它还会查询非本地NIS或LDAP数据库。 getent-维基百科 getent(1)-Linux手册页 getent passwd "$uid" | cut -d: -f1 不幸的是,该getent实用程序似乎未由POSIX指定。 使用id命令 id 是POSIX标准化的实用程序,用于获取有关用户身份的数据。 BSD和GNU实现接受用户ID作为操作数: id(1)-OpenBSD手册页 id(1)– FreeBSD手册页 GNU Coreutils:id调用 这意味着它可用于打印与用户ID关联的登录名: id -nu "$uid" 但是,未在POSIX中指定提供用户ID作为操作数。它仅描述使用登录名作为操作数。 结合以上所有 我考虑过将以上三种方法合并为以下内容: get_username(){ uid="$1" # First …
23 users  posix 

2
POSIX是否保证任何标准实用程序的路径?
从C语言开始,运行标准实用程序(例如ps)而没有其他方法的最简单方法是什么? POSIX是否保证例如已存在标准ps,/bin/ps还是应该将PATH环境变量重置为所获得的内容confstr(_CS_PATH, pathbuf, n);,然后通过PATH搜索运行该实用程序?
22 path  c  posix  exec 

2
要使文件成为POSIX定义的文本文件,必须满足什么条件?
POSIX将文本文件定义为: 包含以零行或更多行组织的字符的文件。这些行不包含NUL字符,并且长度都不能超过{LINE_MAX}个字节,包括<newline>字符。尽管POSIX.1-2017不能区分文本文件和二进制文件(请参阅ISO C标准),但是许多实用程序在对文本文件进行操作时只能产生可预测或有意义的输出。具有此类限制的标准实用程序始终在其STDIN或INPUT FILES部分中指定“文本文件”。 来源:http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403 但是,有几件事我不清楚: 文本文件必须是常规文件吗?在上面的摘录中,它没有明确指出文件必须是常规文件 如果文件仅包含一个字符和一个字符(即,一个不以换行符终止的字符),可以将其视为文本文件吗?我知道这个问题听起来很挑剔,但是他们使用“字符”一词代替了“一个或多个字符”。其他人可能会不同意,但是如果他们的意思是“一个或多个字符”,我认为他们应该明确地说出来 在上面的摘录中,它引用了“线条”。我在名称中找到了四个带有行的定义:“空行”,“显示行”,“不完整行”和“行”。我是否应该推断出它们是由于省略了“空”,“显示”和“不完整”而表示“行”的?还是上述所有四个定义都包括在内? 此文本段之后出现的所有问题均取决于推断“字符”是指“一个或多个字符”: 我可以安全地推断出,如果一个文件为空,则它不是文本文件,因为它不包含一个或多个字符? 此文本段之后出现的所有问题均取决于推断,在上述摘录中,一行定义为“行”,并且应排除名称中包含“行”的其他三个定义: “零个或多个行”中的“零”是否意味着如果文件包含一个或多个未以换行符终止的字符,仍可以将其视为文本文件? “零行或更多行”是否表示一旦出现一个“行”(0个或多个字符加上一个换行符),则最后一行成为“不完整行”(一个或多个非文件末尾的换行符)? “没有[没有行]的长度不能超过{LINE_MAX}个字节,包括换行符”是否表示文本文件中任何给定“行”中允许的字符数有限制(顺便说一句,在Ubuntu 18.04和FreeBSD 11.1上的LINE_MAX是“ 2048”)吗?
22 files  posix  text 

2
是否有设置目标应用程序第零个参数的POSIX方法?
在中,bash您还可以使用exec -a和中的zsh选项来设置ARGV0执行带有特定第零个参数的程序,但是还有POSIX方法吗? 如该注释中所建议,您可以创建一个(临时)符号链接来实现此目的,但是通过这种方式,我无法将新的第零个参数值设置为真正的任意值,例如具有某个绝对路径的命令。那么还有其他解决方案吗?

1
POSIX在命令替换内对此处引用的文档有何要求?
在此问题中,有人报告了一个使用here文档的问题,该文档在$(...)命令替换中使用带引号的定界符单词,其中\文档内部行末尾的反斜杠触发换行-换行,而在命令替换之外的相同here文档可以按预期工作。 这是一个简化的示例文档: cat <<'EOT' abc ` def ghi \ jkl EOT 这包括在行尾包含一个反引号和一个反斜杠。用引号引起来,因此主体内部不会发生扩展。在所有与伯恩相似的地方,我都能找到逐字逐句输出的内容。如果我将相同文档放在命令替换中,如下所示: x=$(cat <<'EOT' abc ` def ghi \ jkl EOT ) echo "$x" 然后它们不再表现相同: dash,ash,zsh,ksh93,BusyBox的ash,mksh,和SunOS 5.10 POSIX sh都给予该文件的逐字内容,如前。 Bash 3.2针对不匹配的反引号给出了语法错误。使用匹配的反引号,它尝试将内容作为命令运行。 Bash 4.3将“ ghi”和“ jkl”折叠到一行上,但是没有错误。该--posix选项不影响此。Kusalananda 告诉我(谢谢!)的pdksh行为也是如此。 在最初的问题中,我说这是Bash解析器中的错误。是吗?[更新:是 ]我可以从POSIX(全部来自Shell命令语言定义)中找到相关文本: §2.6.3命令替换: 使用$(command)格式,在右括号后到匹配的右括号后的所有字符构成命令。可以将任何有效的Shell脚本用于命令,但仅由重定向组成的脚本会产生未指定的结果。 §2.7.4此处文档: 如果对单词的任何部分加引号,则应通过对单词执行引号删除来形成定界符,并且此处文档行不得扩展。 第2.2.1节转义符(反斜杠): 如果<newline>跟在<backslash>之后,则外壳程序应将其解释为行继续。在将输入拆分为令牌之前,应删除<backslash>和<newline>。 §2.3令牌识别: 当io_here标记已被语法识别时(请参见Shell Grammar),紧接在下一个NEWLINE标记之后的一个或多个后续行构成一个或多个here-document的主体,并应根据Here-rule的规则进行解析-文件。 当不处理io_here时,外壳程序应通过将下面的第一个适用规则应用于其输入中的下一个字符,将其输入分解为令牌。... ... 如果当前字符是<反斜杠>,单引号或双引号,并且未加引号,则它将影响到后续字符的引号,直到引号文本的末尾。对引用的规则中所描述的引用。在令牌识别期间,不得实际执行任何替换,并且结果令牌应完全包含输入中出现的字符(<newline>联接除外),且未修改,包括在末尾之间的任何嵌入式或封闭引号或替换运算符。引用文字的内容。 …

1
如果多线程Linux进程收到信号,该怎么办?
如果Unix(Posix)进程接收到信号,则将运行信号处理程序。 在多线程进程中会发生什么?哪个线程接收信号? 我认为,应该扩展信号API来处理该问题(即应该能够确定信号处理程序的线程),但是在网上寻找信息时,我只在Linux内核邮件列表中发现了长达一年之久的信息。不同的论坛。据我了解,Linus的概念不同于Posix标准,并且首先构建了一个兼容层,但现在Linux遵循posix模型。 目前的状态是什么?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.