Questions tagged «directory-structure»

目录层次结构的布局-诸如“此文件在哪里？”之类的问题 或“此目录用于什么？”。

2
本地可执行文件应放在哪里？
我有一个针对perforce版本控制客户端（p4）的可执行文件。我无法放置它，/opt/local因为我没有root特权。是否需要将其放在下面的标准位置$HOME？ 文件系统层次结构是否有约定要求放置本地可执行文件/二进制文件$HOME/bin？ 我找不到Wikipedia文章中提到的有关FHS的约定。 另外，如果确实有约定，我是否必须明确包含$HOME/bin目录的路径或目录的位置bin？
3
我的systemd单位文件放在哪里？
我读到有两个单位文件文件夹（不在用户模式下）。 /usr/lib/systemd/system/: units provided by installed packages /etc/systemd/system/: units installed by the system administrator 与此答案相矛盾的是以下答案：https : //unix.stackexchange.com/a/47715/33386。有人可以填写缺少的信息，以便我了解发生了什么吗？（更新：答案已更新，我的理解不再与之冲突。） 另外，脚本似乎组织在该/etc/systemd/system/文件夹中的子文件夹中： getty.target.wants multi-user.target.wants 在另一个位置，我读到还有其他位置。看来这些是针对特定于用户的服务的。 /usr/lib/systemd/user/ where services provided by installed packages go. /etc/systemd/user/ where system-wide user services are placed by the system administrator. ~/.config/systemd/user/ where the user puts its own services. 更新2015-08-31： 为了其他人，这是我最近问过的一个相关问题的链接： …
4
我怎么知道在Linux的什么地方放东西？
在Windows中安装某些东西只需单击一个按钮。但是每次我尝试在Linux中安装某些在APT中找不到的东西时，我都会感到困惑。 您下载了一个压缩文件夹，然后呢？如果您很幸运，可以找到自述文件，请参考一些文档，如果您很幸运，这可能会对您有所帮助。 当“安装” APT中没有的扩展程序和应用程序时，魔术是什么？ 我爱linux，但是这个问题每天困扰着我。
6
在Linux中应将程序安装到哪个目录？
我想在Linux中安装程序并将其作为守护程序运行。（在这种情况下，团队讲3，但问题本质上是一般性的）。没有提供程序包，只有解压缩的二进制文件。我应该按惯例将这样的程序放在目录结构中的什么位置？ 在网络上，我发现/ opt用于“可选附加应用程序”，而/ usr用于“用户程序”。我发现一个教程建议/ opt，而另一个建议/ usr。 那么哪个是“更正确的”呢？
1
lib，lib32，lib64，libx32和libexec之间的区别
我的64位Ubuntu 13.04系统在以下位置具有以下目录/： lib lib32 lib64 libx32 libexec 在/usr目录中有： lib lib32 libx32 libexec 似乎可以通过搜索轻松地找到答案，但是我没有在网上发现任何东西，除了这些目录存储共享库（libexec除外）。但是哪些共享库位于哪个文件夹中（lib32中的32位和lib64中的64位除外）？有人可以解释所有这些目录之间的区别吗？
5
FHS的替代品有哪些？
我是Linux的长期用户，已经有15年以上的时间，但是我讨厌的一件事是强制性的目录结构。我不喜欢那/usr/bin是二进制文件或库的倾销地/usr/lib，/usr/lib32，/usr/libx32，/lib，/lib32等...随机的东西在/usr/share等，这是愚蠢和混乱。但是有些人喜欢它，口味也有所不同。 我想要一个目录结构，其中每个包都被隔离。试想一下，如果媒体播放器Dragon拥有自己的结构： /software/dragon /software/dragon/bin/x86/dragon /software/dragon/doc/README /software/dragon/doc/copyright /software/dragon/lib/x86/libdragon.so 要么： /software/zlib/include/zlib.h /software/zlib/lib/1.2.8/x86/libz.so /software/zlib/lib/1.2.8/x64/libz.so /software/zlib/doc/examples/... /software/zlib/man/... 你明白了。我有什么选择？是否有使用我的方案的Linux发行版？是否可以将某些发行版修改为可以正常运行（Gentoo ??）或需要LFS？这个领域有任何现有技术吗？像有关该计划是否可行的出版物一样？ 不是在寻找OSX。:)但是以OS X为灵感是完全可以的。 编辑：我不知道如何PATH，LD_LIBRARY_PATH和取决于一小部分路径的其他环境变量应该计算出来。我在想，如果我安装了KDE编辑器Kate，/software/kate/bin/x86/bin/kate则可以键入二进制文件的完整路径来启动它。dlopen我不知道它应该如何用于动态库和调用，但这不是一个无法解决的工程问题。
1
/ home目录什么时候出现？
最初在Unix中，/usr用于用户（主）目录。因此，如果我有一个名为的用户alex，我的主目录将为/usr/alex。（有趣的是，Unix的后继计划9仍在中包含用户目录/usr。） 当然，如今，我们将主目录存储在中/home。（至少在GNU / Linux上。我不了解其他Unices，但是OS X不算在内。）这在什么时候成为标准做法？它出现在什么Unix风格中？其他Unices的收养需要多长时间？先后/home已通过大家？ 我在这里做了一些搜索，但是什么也没发现。
3
Unix / Linux操作系统上的标准和/或通用目录
来自Windows世界，我发现大多数文件夹目录名称都非常直观： \Program Files 包含程序使用的文件（惊奇！） \Program Files (x86) 包含由64位OS上的32位程序使用的文件 \Users（以前为Documents and Settings）包含用户的文件，即文档和设置 \Users\USER\Application Data 包含特定于应用程序的数据 \Users\USER\Documents 包含属于用户的文档 \Windows 包含属于Windows本身操作的文件 \Windows\Fonts 存储字体文件（惊奇！） \Windows\Temp 是全局临时目录 等等。即使我不知道这些文件夹的作用，也可以从它们的名称中准确地猜测出来。 现在，我对Linux有了一个很好的了解，并对如何找到围绕文件系统的方式感到非常困惑。 例如： /bin包含二进制文件。但这样做/sbin，/usr/bin，/usr/sbin，，也许更多的，我不知道。哪个？它们之间有什么区别？如果我想制作一个二进制文件并将其放在系统范围内的某个地方，该放在哪里？ /media包含外部媒体文件系统。但是也是/mnt。目前，它们都没有在我的系统上包含任何内容。一切似乎都在/dev。有什么不同？硬盘上的其他分区（例如Windows中的C:和D:）在哪里？ /home包含用户文件和设置。这么直观是什么，但是接下来应该做什么/usr呢？/root即使是拥有文件和设置的用户，又怎么会分开呢？ /lib包含共享库，例如DLL。但是也是/usr/lib。有什么不同？ 什么是 /etc？它真的代表“等等”吗？哪些文件应该放在那里-全局文件还是本地文件？它是所有人都不知道放在哪里的东西的统筹，还是有特定的用例？ 什么是/opt，/proc和/var？它们代表什么？它们代表什么？我在Windows *中还没有看到类似它们的东西，而且我只是想不出它们的用途。 如果有人可以想到其他可能会有所了解的标准地点，请随时将其添加到问题中；希望对于像我这样开始熟悉* nix系统的人们来说，这可以是一个很好的参考。 *好，那是谎言。我在WinObj中看到过类似的事情，但显然不是定期的。我仍然不知道这些在Linux上做什么。
5
名称以点开头的目录有何特别之处？
此问题是从软件工程堆栈交换迁移的，因为可以在Unix和Linux堆栈交换上回答。 迁移 8年前。 我想知道两者之间的区别是什么： ~/somedirectory/file.txt 和 ~/.somedirectory/file.txt 在Google上问这个问题真的很困难，因为我.什至不知道如何称呼它，我也不知道该怎么解释。但是有人可以描述包含点和排除点之间的区别吗？
4
从/ bin添加到路径与链接
我们的系统管理员在服务器上安装了一个软件应用程序（Maven），并告诉所有人将/usr/local/maven/bin/文件夹添加到其路径中。 我认为，从/bin文件夹（或每个人都在其路径中的其他文件夹）中链接该文件夹中的几个程序可能会更方便： ln -s /usr/local/maven/bin/* /bin 它是否正确？我的建议有一些隐藏的副作用吗？
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.