Linux 脚本，标准目录位置
我正在尝试编写一个 bash 脚本来完成一项任务，到目前为止我做得很好，并且在一定程度上可以正常工作，但我想对其进行设置，以便可以将其分发给其他人，并将其开放为开源，所以我想开始以“传统”方式做事。不幸的是，我不太确定传统的方法是什么。
理想情况下，我想要一个深入的在线资源的链接，该资源深入讨论这个问题和相关主题，但我很难找到可以在谷歌上找到这个问题的关键字。
在我的脚本开始时，我设置了一堆全局变量来存储它将要访问的目录的名称，这意味着我可以快速修改目录，但这是编程快捷方式，而不是用户快捷方式，我不能告诉用户他们必须摆弄这些东西。另外，我需要个人用户的设置不要在每次升级时被删除。
问题：
设置文件夹的名称：~/.foo/——这很好，但是如何将我的工作副本和我的开发副本分开？ tweek 开发版本源代码中的参考？
如果我的程序需要维护和更新数据库（在本例中为 GPS 轨迹日志数据），该目录应该在哪里？用户将需要访问其中一些数据，但主要供内部使用。我个人在 cygwin 中工作，我喜欢将这些数据保存在单独的驱动器上，所以路径很奇怪，我怀疑很多用户都可以找到这个。对于默认值，但我在想 ~/gpsdata/ ——这是否正常，或者我应该硬编码一个系统，询问用户第一次运行时将其放在哪里，并将其存储在设置文件夹中？无论发生什么，我都必须将目录引用存储在设置文件夹中的文件中。
该程序需要一个数据“收件箱”，这是一个用户可以转储文件的文件夹，然后运行脚本来处理这些文件。我在想〜/ gpsdata / in / ??尽管总是有一个选项可以将文件或文件夹添加到命令行来使用它（它处理列出的所有位置的文件，包括“收件箱”）
脚本本身应该去哪里？它已经足够聪明了，它可以创建所有辅助/设置文件（一旦我找出“正确”目录），如果使用“./foo --setup”运行，我可以将它推入 /usr/bin/ 或 /bin或 ~/.foo/bin （并将其添加到路径中）什么是正常的？
我需要存储它将连接到的 Web 服务的登录详细信息（如果重要，请使用curl -u）计划包括一个设置，每次执行时都要求输入用户名和密码，但它目前将其平面文本存储在文件中在 ~/.foo/ 中——我知道，这不好。 Web 服务 (osm.org) 确实支持 oauth，但我不知道如何让curl 使用它——首先让curl 与服务对话就是一个黑客行为。有没有一种简单的方法可以对这样的文件进行真正基本的加密，以阻止使用记事本武装的白痴？
抱歉列出了问题列表，我相信它们对于单个帖子而言足够密切相关。这些都是刺痛的东西，但希望得到澄清/确认。
I am trying to write a bash script to do a task, I have done pretty well so far, and have it working to an extent, but I want to set it up so it's distributable to other people, and will be opening it up as open source, so I want to start doing things the "conventional" way. Unfortunately I'm not all that sure what the conventional way is.
Ideally I want a link to an in depth online resource that discusses this and surrounding topics in depth, but I'm having difficulty finding keywords that will locate this on google.
At the start of my script I set a bunch of global variables that store the names of the dirs that it will be accessing, this means that I can modify the dir's quickly, but this is programming shortcuts, not user shortcuts, I can't tell the users that they have to fiddle with this stuff. Also, I need for individual users' settings not to get wiped out on every upgrade.
Questions:
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate? tweek the reference in the source of the dev version?
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be? the user will need to access some of this data, but it's mostly for internal use. I personally work in cygwin, and I like to keep this data on separate drive, so the path is wierd, I suspect many users could find this. for a default however I'm thinking ~/gpsdata/ -- would this be normal, or should I hard code a system that ask the user at first run where to put it, and stores this in the settings folder? whatever happens I'm going ot have to store the directory reference in a file in the settings folder.
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?? though there will always be an option to add a file or folder to the command line to use that as well (it processed files all locations listed, including the "inbox")
Where should the script its self go? it's already smart enough that it can create all of it's ancillary/settings files (once I figure out the "correct" directory) if run with "./foo --setup" I could shove it in /usr/bin/ or /bin or ~/.foo/bin (and add that to the path) what's normal?
I need to store login details for a web service that it will connect to (using curl -u if it matters) plan on including a setting whereby it asks for a username and password every execution, but it currently stores it plane text in a file in ~/.foo/ -- I know, this is not good. The webservice (osm.org) does support oauth, but I have no idea how to get curl to use it -- getting curl to speak to the service in the first place was a hack. Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Sorry for the list of questions, I believe they are closely related enough for a single post. This is all stuff that stabbing at, but would like clarification/confirmation over.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
默认值为
~/.foo，以及一个可在开发时用来覆盖默认值的选项（例如--config-directory）。如果您的脚本在普通用户帐户下运行，则该脚本必须位于用户主目录中的某个位置；在其他地方，您将没有写入权限。也许
~/.foo/tracklog之类的？再次添加一个命令行选项，并在配置文件中添加一个选项来覆盖它。我不喜欢你的
~/gpsdata默认值；我不希望我的主目录中堆满了未经我同意的程序创建的各种目录。这种情况在 Windows 上经常发生，这真的很烦人。 （在“我的文档”中保存的游戏？离开这里！）如上所述，我更喜欢
~/.foo/inbox。还可以使用命令行选项和配置文件选项来更改此设置。但您真的需要收件箱吗？如果用户需要对某些文件手动运行脚本，最好在命令行上接受这些文件名。它们可以在任何地方进行处理，而不必将它们移动到“神奇”的位置。
这通常取决于您所运行的特定操作系统的打包系统。从源代码安装时，
/usr/local/bin是一个合理的默认值，不会干扰包管理器。是的，有。但最好不要这样做，因为这会产生一种错误的安全感。如果没有主密码之类的东西，安全存储是不可能的！例如，Pidgin 明确以纯文本形式存储密码，这样用户就不会对其密码“安全”存储做出任何错误的假设。因此，最好以纯文本形式存储它们，抱怨该文件是否是世界可读的，并在手册中添加清晰的注释以警告用户发生了什么事。
底线：不要尝试重新发明轮子。有数以千计的脚本和程序面临着同样的问题；他们中的大多数最终都采用了相同的约定，并且有充分的理由。看看他们做了什么，模仿他们，而不是重新发明轮子。
Have a default of
~/.foo, and an option (for example--config-directory) that you can use to override the default while developing.If your script is running under a normal user account, this will have to be somewhere in the user's home directory; elsewhere, you'll have no write permissions. Perhaps
~/.foo/tracklogor something? Again, add a command line option, and also an option in the configuration file, to override this.I'm not a fan of your
~/gpsdatadefault; I don't want my home directory cluttered with all sorts of directories that programs created without my consent. You see this happen on Windows a lot, and it's really annoying. (Saved games in My Documents? Get out of here!)As stated above, I'd prefer
~/.foo/inbox. Also with command-line option and configuration file option to change this.But do you really need an inbox? If the user needs to run the script manually over some files, it might be better just to accept those file names on the command line. They could just be processed wherever, without having to move them to a "magic" location.
This is usually up to the packaging system of the particular OS you're running on. When installing from source,
/usr/local/binis a sensible default that won't interfere with package managers.Yes, there is. But it's better not to, because it creates a false sense of security. Without a master password or something, secure storage is not possible! Pidgin, for example, explicitly stores passwords in plain text, so that users won't make any false assumptions about their passwords being stored "securely". So it's best just to store them in plain text, complain if the file is world-readable, and add a clear note to the manual to warn the user what's going on.
Bottom line: don't try to reinvent the wheel. There have been thousands of scripts and programs that faced the same issues; most of them ended up adopting the same conventions, and for good reasons. Look at what they do, and mimic them instead of reinventing the wheel.
您可以从文件系统层次结构标准开始。我不确定它的遵循程度如何，但它确实提供了一些指导。一般来说，我尝试使用以下内容：
$HOME/.foo/用于用户特定的设置 - 它是隐藏的$PREFIX/etc/foo/用于系统范围的配置$PREFIX/foo/bin/用于系统范围的二进制文件$PREFIX/foo/bin的符号链接已添加到$PREFIX/bin/以便于使用$PREFIX/foo/var/是变量 数据所在的位置 - 这是输入假脱机和日志文件所在的位置$PREFIX应默认为/opt/foo 尽管几乎每个人似乎默认情况下都会在/usr/local中放入东西（感谢 GNU！）。如果有人想将软件包安装在他们的主目录中，请将$HOME替换为$PREFIX。至少这是我对这一切应该如何运作的看法。You can start with the Filesystem Hierarchy Standard. I'm not sure how well followed it is, but it does provide some guidance. In general, I try to use the following:
$HOME/.foo/is used for user-specific settings - it is hidden$PREFIX/etc/foo/is for system-wide configuration$PREFIX/foo/bin/is for system-wide binaries$PREFIX/foo/binare added to$PREFIX/bin/for ease of use$PREFIX/foo/var/is where variable data would live - this is where your input spools and log files would live$PREFIXshould default to/opt/fooeven though almost everyone seems to plop stuff in/usr/localby default (thanks GNU!). If someone wants to install the package in their home directory, then substitute$HOMEfor$PREFIX. At least that is my take on how this should all work.