如何设计与 Windows 相关的 Linux 软件？

发布于 2024-11-18 01:21:48 字数 242 浏览 0 评论 0原文

我有一个为 Windows 编写的应用程序，我正在将其移植到 Linux（具体来说是 Ubuntu）。问题是我一直只使用Linux，从未真正为其开发过。更具体地说，我不了解系统的基本布局。例如，我应该在哪里安装我的软件？我希望所有用户都可以访问它，但我需要该区域的写入权限才能编辑我的数据文件。此外，我如何以编程方式确定软件的安装位置（而不仅仅是从何处调用它）？在 Windows 中，我使用注册表来查找包含所有相关信息的配置文件，但在 Linux 中没有注册表。谢谢！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

记忆消瘦 2024-11-25 01:21:48

文件系统层次结构标准（命名错误——它不是标准）将对你很有帮助；它清楚地描述了管理员对数据存放位置的偏好。

由于您是第一次打包软件，因此我建议您做的事情很少。 Debian、Ubuntu、Red Hat、SuSE、Mandriva、Arch、Annvix、Openwall、PLD 等对于如何最好地打包软件都有自己的小特点。

构建

您最好的选择是提供一个构建的源代码压缩包，并希望这些发行版的用户或打包者能够选择它并为您打包。用户可能会喜欢下载 tarball、解压、编译和安装。

要构建您的软件，make(1) 是通常的标准。还存在其他工具，但这个工具随处可用，而且相当合理。（即使语法古怪。）用户将期望能够运行： make ; make install 或 ./configure ；制作 ; make install 构建软件并将其默认安装到 /usr/local 中。（./configure 是 autotools 工具链的一部分；特别适合提供 ./configure --prefix=/opt/foo 允许用户使用一个命令行参数更改软件的安装位置，我会尽力避免使用自动工具，但是。在某些时候，它会更容易使用它们编写可移植软件比不使用它们更好。）

打包

如果您确实想提供一站式打包，那么Debian 政策手册将提供有关如何打包软件的规范规则。 Debian 新维护者指南将提供更友善、更温和的工具演练为 Debian 和 Debian 衍生系统构建软件包所独有的。

Ubuntu 的打包指南可能包含特定于 Ubuntu 的详细信息。（我还没读过。）

配置

当涉及到应用程序的配置文件时，通常文件存储在 /etc/ 中，其中代表程序/包。有关名称解析的详细信息，请参阅 /etc/resolv.conf，请参阅 /etc/fstab 以了解包含文件系统的设备列表以及安装它们的位置，/etc /sudoers 用于 sudo(8) 配置，/etc/apt/ 用于 apt(8) 包管理系统，有时

应用程序还提供每用户配置；这些配置文件通常存储在 ~/.foorc 或 ~/.foo/ 中，以防整个目录比文件更有用。（参见 ~/.vim/、~/.mozilla/、~/.profile 等）

如果您还想提供-c 命令行选项告诉您的程序使用非标准配置文件，有时这会非常方便。（特别是如果您的用户可以运行foo -c /dev/null 以完全默认的配置启动。）

数据文件

用户将把数据存储在他们的主目录中。您不需要为此做任何事情；只需确保使用 getenv("HOME") 启动目录导航框或通过 sprintf(config_dir, "%s/%s/config", getenv("HOME) 加载配置文件")、".application"); 或类似的内容。（他们没有权限在大多数站点上除了主目录和 /tmp/ 之外的任何地方进行写入。）

有时，所有数据都可以存储在隐藏文件或目录中；例如，ssh(1) 将其所有数据保存在 ~/.ssh/ 中。通常，用户希望使用 ssh-keygen(1) 中的默认 kry 名称，以便 ssh-agent(1) 可以轻松找到密钥。（默认情况下，它使用 ~/.ssh/id_rsa。）shotwell(1) 照片管理器提供托管体验，类似于 >iPhoto.app 来自 Apple。它允许用户选择起始目录，但也可以根据需要组织文件和目录。

如果您的应用程序是通用程序，您可能会让用户选择他们自己的文件名。如果他们想将数据直接存储到安装在 /dev 或 /media 中的记忆棒或安装在 /automount/blah 中的远程文件系统，他们的主目录，机器上提供的内容的 /srv/ 目录，或 /tmp/，让他们。用户可以为他们的数据选择合理的文件名和目录。用户必须拥有适当的权限。已经。（不要尝试为用户提供在他们没有权限的位置进行写入的机制。）

应用程序文件安装和所有权

在 Linux 系统上安装应用程序有两种常见方法：

管理员为每个人安装一次。这很平常。这些程序由 root 或 bin 或 adm 或某些类似帐户拥有。程序运行与执行它们的用户一样，因此它们获得用户创建和读取文件的权限。如果它们与分发包文件一起打包，则可执行文件通常位于 /usr/bin/ 中，库位于 /usr/lib/ 中，非对象文件（图像、模式等）将位于 /usr/share/ 中。（/bin/ 和 /lib/ 用于早期启动或救援环境所需的应用程序。/usr 可能对所有机器都是通用的。网络，在启动过程后期以只读方式安装。）（有关完整详细信息，请参阅 FHS。）
如果程序未打包，则 /usr/local/ 将作为起点：/usr/local/bin/、/usr/local /lib/、/usr/local/share/ 等。有些管理员更喜欢 /opt/。
用户将应用程序安装到其主目录中。这种情况不太常见，但许多用户都会有一个 ~/bin/ 目录，用于存储他们编写的 shell 脚本或程序，或者从 ~/Local/链接到程序。 / 目录。（这个名字没有什么神奇之处。这只是我几年前想到的第一件事。其他人选择其他名称。）这就是 ./configure --prefix=~/Local/blah 的价值所在）

The Filesystem Hierarchy Standard (misnamed -- it is not a standard) will be very helpful to you; it clearly describes administrator preferences for where data should live.

Since you're first packaging your software, I'd like to recommend doing very little. Debian, Ubuntu, Red Hat, SuSE, Mandriva, Arch, Annvix, Openwall, PLD, etc., all have their own little idiosyncrasies about how software should be best packaged.

Building

Your best bet is to provide a source tarball that builds and hope users or packagers for those distributions pick it up and package it for you. Users will probably be fine with downloading a tarball, unpacking, compiling, and installing.

For building your software, make(1) is the usual standard. Other tools exists, but this one is available everywhere, and pretty reasonable. (Even if the syntax is cranky.) Users will expect to be able to run: make ; make install or ./configure ; make ; make install to build and install your software into /usr/local by default. (./configure is part of the autotools toolchain; especially nice for providing ./configure --prefix=/opt/foo to allow users to change where the software gets installed with one command line parameter. I'd try to avoid the autotools as far as you can, but at some point, it is easier to write portable software with them than without them.)

Packaging

If you really do want to provide one-stop-packaging, then the Debian Policy Manual will provide the canonical rules for how to package your software. The Debian New Maintainers Guide will provide a kinder, gentler, walkthrough of the tools unique to building packages for Debian and Debian-derived systems.

Ubuntu's Packaging Guide may have details specific to Ubuntu. (I haven't read it yet.)

Configuration

When it comes to your application's configuration file, typically a file is stored in /etc/<foo> where <foo> represents the program / package. See /etc/resolv.conf for details on name resolution, /etc/fstab for a list of devices that contain filesystems and where to mount them, /etc/sudoers for the sudo(8) configuration, /etc/apt/ for the apt(8) package management system, etc.

Sometimes applications also provide per-user configuration; those config files are often stored in ~/.foorc or ~/.foo/, in case an entire directory is more useful than a file. (See ~/.vim/, ~/.mozilla/, ~/.profile, etc.)

If you also wanted to provide a -c <filename> command line option to tell your program to use a non-standard configuration file, that sometimes comes in real handy. (Especially if your users can run foo -c /dev/null to start up with completely default configuration.)

Data files

Users will store their data in their home directory. You don't need to do anything about this; just be sure to start your directory navigation boxes with getenv("HOME") or load your configuration files via sprintf(config_dir, "%s/%s/config", getenv("HOME"), ".application"); or something similar. (They won't have permissions to write anywhere but their home directory and /tmp/ at most sites.)

Sometimes all the data can be stored in a hidden file or directory; ssh(1) for example, keeps all its data in ~/.ssh/. Typically, users want the default kry name from ssh-keygen(1) so ssh-agent(1) can find the key with the minimum of fuss. (It uses ~/.ssh/id_rsa by default.) The shotwell(1) photo manager provides a managed experience, similar to iPhoto.app from Apple. It lets users choose a starting directory, but otherwise organizes files and directories within as it sees fit.

If your application is a general purpose program, you'll probably let your users select their own filenames. If they want to store data directly to a memory stick mounted in /dev or /media or a remote filesystem mounted into /automount/blah, their home directories, a /srv/ directory for content served on the machine, or /tmp/, let them. It's up to users to pick reasonable filenames and directories for their data. It is up to users to have proper permissions already. (Don't try to provide mechanisms for users to write in locations they don't have privileges.)

Application file installation and ownership

There are two common ways to install an application on a Linux system:

The administrator installs it once, for everyone. This is usual. The programs are owned by root or bin or adm or some similar account. The programs run as whichever user executes them, so they get the user's privileges for creating and reading files. If they are packaged with distribution packaging files, executables will typically live in /usr/bin/, libraries in /usr/lib/, and non-object-files (images, schemas, etc.) will live in /usr/share/. (/bin/ and /lib/ are for applications needed at early boot or for rescue environments. /usr might be common to all machines in a network, mounted read-only late in the boot up process.) (See the FHS for full details.)
If the programs are unpackaged, then /usr/local/ will be the starting point: /usr/local/bin/, /usr/local/lib/, /usr/local/share/, etc. Some administrators prefer /opt/.
Users install applications into their home directory. This is less common, but many users will have a ~/bin/ directory where they store shell scripts or programs they write, or link in programs from a ~/Local/<foo>/ directory. (There is nothing magic about that name. It was just the first thing I thought of years ago. Others choose other names.) This is where ./configure --prefix=~/Local/blah pays for itself.)