Re: [PATCH] get_home_path: use HOME
От | Daniel Verite |
---|---|
Тема | Re: [PATCH] get_home_path: use HOME |
Дата | |
Msg-id | ce44d5de-34cd-408b-b71d-f936f315b418@mm обсуждение исходный текст |
Ответ на | Re: [PATCH] get_home_path: use HOME (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > If we take this patch, what's to stop someone from complaining that we > broke *their* badly-designed system that abuses the HOME variable? POSIX warns against doing that, listing HOME in the variables that should be left to their intended usage: http://pubs.opengroup.org/onlinepubs/9699919799/ <quote> If the variables in the following two sections are present in the environment during the execution of an applicationor utility, they shall be given the meaning described below [...] HOME The system shall initialize this variableat the time of login to be a pathname of the user's home directory. See <pwd.h>. </quote> psql is indirectly using $HOME already for readline and terminfo: $ HOME=/tmp/home2 strace psql 2>tr ; grep home2 tr ... stat("/tmp/home2/.terminfo", 0x7ff985bf4730) = -1 ENOENT (No such file or directory) stat("/tmp/home2/.inputrc", 0x7fff3f641d70) = -1 ENOENT (No such file or directory) Also when using Debian's psql, the wrapper looks for it own config file in $HOME: open("/tmp/home2/.postgresqlrc", O_RDONLY) = -1 ENOENT (No such file or directory) Being written in Perl, it could use getpwuid(), but it doesn't, like I believe the majority of programs that just want the home directory. +1 on using HOME for being consistent with other pieces of code around postgres, and for the easiness of locally overriding it when troubleshooting problems with dot files. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
В списке pgsql-hackers по дате отправления: