我最近了解到〜指的是HOME变量。所以，如果我设置HOME = / foo，然后尝试使用想要cd~ / Documents的bash脚本，最后会说：
foo / Documents：没有这样的文件或目录
在这种情况下，最佳做法是什么？崩溃并向用户抱怨他们覆盖了HOME？或者有什么方法可以恢复HOME的默认值吗？
答案 0 :(得分：1)
用户主目录的真实来源是/etc/passwd，其中包含系统中每个用户的一行，列出用户的姓名，主目录和其他一些信息。如果您的问题是＆＃34;什么是某某主目录？＆＃34;，那么您应该在/etc/passwd中查找。*
但是，虽然/etc/passwd是正确的，但如果用户使用其他路径破坏了$HOME，他们可能会要求您使用该值而不是＆＃34;真实＆＃34;主目录。除非允许用户欺骗主目录存在安全问题，否则最好盲目地使用用户给出的值。
就个人而言，我会检查$HOME是否是目录（例如if [[ -d "$HOME" ]]），如果是，请按原样使用。如果没有，请使用grep和cut将其解析出/etc/passwd，也许会向stderr打印一条警告，提醒用户他们的$HOME是坏的。您可以grep查看由id -u打印的UID，这些UID不会被非root用户破坏。
但是，如果您真的要担心$HOME被破坏，您还应该担心$PATH，$LC_*变量以及其他一些环境变量打破各种事物。最终，除非存在安全问题，否则更容易假设这些变量是正确的并按原样使用它们。这意味着只是盲目地使用$HOME并且不要过于担心它是错误的。
*在使用LDAP或类似网络系统管理帐户的系统上，可能不会在此处列出用户的帐户。在某些情况下，有一个/etc/passwd.cache或类似的东西，可能包含用户，但不能保证在每个系统上都能正常工作。在strace(1)上运行whoami(1)有助于指明此信息的来源。
答案 1 :(得分：1)
我认为您应该像对待访问文件的任何其他问题一样对待它。如果您尝试访问的文件不存在，或者您尝试在目录中创建文件，则无法打印错误消息。如果它对应用程序的操作至关重要，则在报告错误后退出。
据我所知，大多数需要使用用户主目录的应用程序只使用HOME环境变量，他们不会尝试再次猜测它。
不应该有任何安全隐患。用户仍然需要相应的权限来访问文件，因此重定向HOME不允许他们编写他们不应该写的其他人的文件。如果您的应用程序是set-uid，则在打开用户目录中的文件时应始终恢复为用户的ID，而不是使用提升的权限。