标签: fhs

在哪里放置Unix域(AF_UNIX)套接字的端点(文件)?

是否存在将表示端点的"文件"放置到Unix域套接字的约定?

我倾向于把它们放进去/tmp/some-application-specific-subdir-name/,但我想知道是否有一个更常见的地方.

背景是,POSIX不清楚访问这些"文件" 的最大路径长度:

sun_path的大小故意未定义.这是因为不同的实现使用不同的大小.例如,4.3 BSD使用108的大小,4.4 BSD使用104的大小.由于大多数实现源自BSD版本,因此大小通常在92到108的范围内.

应用程序不应假定sun_path的特定长度或假设它可以保存{_POSIX_PATH_MAX}个字节(256).

因此,路径长度上的"限制"应该保留在应用程序的文件/路径名配置之外.

unix sockets posix unix-socket fhs

35
推荐指数
2
解决办法
2万
查看次数

适用于Windows的XDG Basedir目录

为了方便访问XDG Basedir目录,我创建了一个Racket .因为我希望该库在Windows上也可用(对于跨平台程序),所以当XDG环境变量未设置时,我使用标准Windows目录作为默认值.

我目前正在使用以下内容:

  • $XDG_DATA_HOME = %LOCALAPPDATA%
  • $XDG_DATA_DIRS = %APPDATA%
  • $XDG_CONFIG_HOME = %LOCALAPPDATA%
  • $XDG_CONFIG_DIRS = %APPDATA%
  • $XDG_CACHE_HOME = %TEMP%
  • $XDG_RUNTIME_DIR = %TEMP%

我的问题是,是否有更好的默认值.我知道,%TEMP%因为$XDG_RUNTIME_DIR是错误的,因为它确实应该是像RAMFS /tmp,但我不知道在Windows上的任何目录就是这样的.在Windows中,似乎没有好的选择将数据和配置目录分开,所以我使用相同的目录.我的直觉是,%LOCALAPPDATA%对于可写$XDG_*_HOME变量而言是更好的选择,并且在$XDG_*_DIRS列表中具有"漫游"配置以进行读取并且通常不会被覆盖.但是,具有漫游配置的企业Windows用户是否会发现这种奇怪且不同意的?

linux windows filepath fhs

11
推荐指数
1
解决办法
1267
查看次数

如何使用distutils处理配置文件以尊重unixen的FHS?

假设我们有一个名为的程序foo.

如果使用绝对路径:

setup(...,
      data_files=[...,
              ('/etc', ['foo.cfg'])]
)
Run Code Online (Sandbox Code Playgroud)

然后foo$ python setup.py --prefix=/usr/local,我们将有/etc/foo.cfg.但/usr/local/etc/foo.cfg根据FHS,我们应该有.

如果我们使用相对路径怎么办?

setup(...,
      data_files=[...,
              ('etc', ['foo.cfg'])]
)
Run Code Online (Sandbox Code Playgroud)

然后,如果我们使用默认安装路径,即安装到/ usr,我们将拥有/usr/etc/foo.cfg.再次运气不好.

那怎么做对了?

PS为避免使问题更复杂,我们假设此程序 foo无法在非unix环境下运行.

python distutils fhs

10
推荐指数
2
解决办法
2984
查看次数

根据Linux文件系统层次结构标准放置Python虚拟环境的适当位置在哪里?

正如标题所示,根据Linux FHS,在Linux操作系统上存储Python虚拟环境的技术上适当的位置是什么?

说明另一种方法,可以得出一个明确的答案:将Python虚拟环境的位置与您服务的数据文件分开是"技术上正确的"吗?

注意:这个问题与我能找到的最接近的,已经问过的问题不同,因为虚拟环境包含库,二进制文件,头文件和脚本.

作为一个额外的复杂性,我倾向于编写支持互联网可访问服务的代码.但是,我并不认为这可以将我的需求与服务的使用者是同一服务器上的其他进程的情况大不相同.我提到这个细节,以防我对评论的回复包括"web dev" - 内容.

作为参考,我使用以下文档作为我对Linux FHS的定义:http://www.pathname.com/fhs/pub/fhs-2.3.html

我不相信流行的virtualenv-wrapper脚本建议正确的操作,因为它默认将虚拟环境存储在用户的主目录中.这违反了目录用于特定于用户的文件的隐含概念,以及"没有程序应该依赖于此位置"的语句.

从文件系统的根级别,我倾向于/usr(可共享的只读数据)或/srv(该系统提供的服务的数据),但这是我很难进一步决定的地方.

如果我要与我的反向代理的决定一起去,那意味着/usr.Nginx通常打包进入/ usr/share/nginx或/ usr/local/nginx,但是,/ usr /应根据FHS以只读方式挂载.我发现这很奇怪,因为我从来没有在一个项目中工作,在这个项目中,开发发生得如此缓慢以至于"以只读方式卸载为只读/卸载,以只读方式卸载/重新安装"被认为是值得的.

/srv是另一个可能的位置,但被称为"特定服务的数据文件的位置",而Python虚拟环境更侧重于提供服务的库和二进制文件(没有这种区别,.so文件也将在srv中) .此外,具有相同要求的多个服务可以共享虚拟环境,这违反了描述的"特定"细节.

我认为选择正确位置的部分困难是因为虚拟环境是一个"环境",它由二进制文件和库组成(几乎就像它自己的小层次结构一样),这使我的印象/usr更加传统:

virtual-env/
??? bin          ~= /usr/local : "for use by the system administrator when installing software locally" 
??? include      ~= /usr/include : "Header files included by C programs"
??? lib          ~= /usr/lib : "Libraries for programming and packages"
??? share        ~= …
Run Code Online (Sandbox Code Playgroud)

python linux virtualenv fhs

8
推荐指数
1
解决办法
2179
查看次数

标签 统计

fhs ×4

linux ×2

python ×2

distutils ×1

filepath ×1

posix ×1

sockets ×1

unix ×1

unix-socket ×1

virtualenv ×1

windows ×1