Re: [HACKERS] Development installation fails

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Development installation fails
Дата
Msg-id 16453.943890298@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Development installation fails  (Peter Eisentraut <e99re41@csd.uu.se>)
Ответы Portability (was Re: [HACKERS] Development installation fails)  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <e99re41@csd.uu.se> writes:
> On Sun, 28 Nov 1999, Tom Lane wrote:
>> I'm not convinced your "which $0" implementation for finding BINDIR is
>> portable/reliable.

> To make a long story short, using the implementation I suggested with the
> checks you suggested would probably benefit 90% of our users.

And fail entirely for the other 10%?  Not good enough if so :-( ... the
idea is to make install easier not harder.  How much code would it take
to emulate as much of "which" as we need, do you think?  What's our
fallback position if it doesn't work?

>> The other bit of environment state that initdb currently depends on is
>> USER.

> Yes, I noticed that too. Again, I really don't think that the script
> should set USER.

After thinking about it for a while, I think that there shouldn't be any
dependency on USER, period.  initdb (and anything else that cares) ought
to get the name of the user they are executing as, and use that.  I
can't see any good reason why the name inserted into the databases
should be potentially different from the ownership of the files.

Is 'whoami' a portable way of getting the current user id, or not?
The only reference I have about portable shell programming says that
the POSIX-approved command for this is 'id -u -n', and that 'whoami'
is a BSD-ism.  I've got doubts that either one is universal ... we might
have to try both.  Grumble.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: [ADMIN] When postgres will be faster?
Следующее
От: Oleg Broytmann
Дата:
Сообщение: Re: [HACKERS] Re: [ADMIN] When postgres will be faster?