I wrote:
> Meh. I guess there's not much point in arguing with facts on the
> ground. Anders' proposed behavior seems like the way to go then,
> at least so far as libpq is concerned.
So I pushed that, but while working on it I grew quite annoyed
at the messy API exhibited by src/port/thread.c,
Christoph Moench-Tegeder writes:
> ## Tom Lane (t...@sss.pgh.pa.us):
>> Isn't that a flat out violation of POSIX 8.3 Other Environment Variables?
> After poking around across some Linuxes, it looks like people silently
> agreed that "services" are not logged-in users: among the daemons,
> having
## Tom Lane (t...@sss.pgh.pa.us):
> Isn't that a flat out violation of POSIX 8.3 Other Environment Variables?
>
> HOME
> The system shall initialize this variable at the time of login to
> be a pathname of the user's home directory. See .
>
> To claim it's not, you have to cl
Christoph Moench-Tegeder writes:
> ## Tom Lane (t...@sss.pgh.pa.us):
>> Given the POSIX requirements, it's basically impossible to believe
>> that there are interesting cases where $HOME isn't set.
> When I look at a random Debian with the usual PGDG packages, the
> postmaster process (and every
## Tom Lane (t...@sss.pgh.pa.us):
> Given the POSIX requirements, it's basically impossible to believe
> that there are interesting cases where $HOME isn't set.
When I look at a random Debian with the usual PGDG packages, the
postmaster process (and every backend) has a rather minimal environment
On Sun, Jan 09, 2022 at 01:59:02PM -0500, Tom Lane wrote:
> Given the POSIX requirements, it's basically impossible to believe
> that there are interesting cases where $HOME isn't set.
I've run into this before - children of init may not have HOME set.
It's easy enough to add it if it's needed, b
On 1/9/22 13:04, Tom Lane wrote:
The only case that the v1 patch helps such a user for is if they
unset HOME or set it precisely to ''. If they set it to anything
else, it's still broken from their perspective. So I do not find
that that argument holds water.
Moreover, ISTM that the only plaus
Anders Kaseorg writes:
> On 1/9/22 10:59, Tom Lane wrote:
>> Given the POSIX requirements, it's basically impossible to believe
>> that there are interesting cases where $HOME isn't set. Thus, it
>> seems to me that keeping the getpwuid calls will just mean carrying
>> untestable dead code, so we
On 1/9/22 10:59, Tom Lane wrote:
Given the POSIX requirements, it's basically impossible to believe
that there are interesting cases where $HOME isn't set. Thus, it
seems to me that keeping the getpwuid calls will just mean carrying
untestable dead code, so we should simplify matters by ripping
Anders Kaseorg writes:
> On 10/20/21 04:55, Daniel Gustafsson wrote:
>> Is the proposed change portable across all linux/unix systems we support?
>> Reading aobut indicates that it's likely to be, but neither NetBSD nor
>> FreeBSD
>> have the upthread referenced wording in their manpages.
> Sinc
On 10/20/21 04:55, Daniel Gustafsson wrote:
Is the proposed change portable across all linux/unix systems we support?
Reading aobut indicates that it's likely to be, but neither NetBSD nor FreeBSD
have the upthread referenced wording in their manpages.
Since the proposed change falls back to th
> On 20 Oct 2021, at 07:40, Kyotaro Horiguchi wrote:
>
> At Tue, 19 Oct 2021 02:44:03 -0700, Anders Kaseorg wrote in
>> On 10/19/21 01:34, Kyotaro Horiguchi wrote:
>>> I tend to agree to this, but seeing ssh ignoring $HOME, I'm not sure
>>> it's safe that we follow the variable at least when ac
At Tue, 19 Oct 2021 02:44:03 -0700, Anders Kaseorg wrote in
> On 10/19/21 01:34, Kyotaro Horiguchi wrote:
> > I tend to agree to this, but seeing ssh ignoring $HOME, I'm not sure
> > it's safe that we follow the variable at least when accessing
> > confidentiality(?) files. Since I don't underst
On 10/19/21 01:34, Kyotaro Horiguchi wrote:
I tend to agree to this, but seeing ssh ignoring $HOME, I'm not sure
it's safe that we follow the variable at least when accessing
confidentiality(?) files. Since I don't understand the exact
reasoning for the ssh's behavior so it's just my humbole opi
At Mon, 18 Oct 2021 19:23:50 -0300, Alvaro Herrera
wrote in
> On 2021-Oct-14, Anders Kaseorg wrote:
>
> > This is important for systems where many users share the same UID, and
> > for test systems that change HOME to avoid interference with the
> > user’s real home directory. It matches what
On Mon, Oct 18, 2021 at 07:23:50PM -0300, Alvaro Herrera wrote:
> I think modifying $HOME is a strange way to customize things, but given
> how widespread it is [claimed to be] today, it seems reasonable to do
> things that way.
I am not sure about this claim, but it seems to me that we could get
On 2021-Oct-14, Anders Kaseorg wrote:
> This is important for systems where many users share the same UID, and
> for test systems that change HOME to avoid interference with the
> user’s real home directory. It matches what most applications do, as
> well as what glibc does for glob("~", GLOB_TIL
According to getpwnam(3):
An application that wants to determine its user's home directory
should inspect the value of HOME (rather than the value
getpwuid(getuid())->pw_dir) since this allows the user to modify
their notion of "the home directory" during a login session.
This is importan
18 matches
Mail list logo
