Re: [HACKERS] Development installation fails

On Sun, 28 Nov 1999, Tom Lane wrote:

> I'm not convinced your "which $0" implementation for finding BINDIR is
> portable/reliable.  On my system, man which says that it determines
> aliases and path by reading ~/.cshrc, which has got obvious problems if
> I'm not a csh user.  My references say that "which" isn't available on
> all systems anyway.  It'd probably be a good idea to verify that
> $BINDIR/postgres exists after you think you have the value.

I did a little "which" survey, it seems you're right. On GNU/Linux systems
"which" is a binary which does the seemingly right thing. Under bash
"which" is also often aliased to "type -path". That led me to believe that
the sh built-in "type" might do, but its output format is rather
unpredicable. On FreeBSD "which" is a Perl script, which seems to work
fine.

On Solaris and SGI the problems you pointed out seem to be present, as
"which" is actually implemented as a csh script. However, on the
particular systems I surveyed, the sysadmins were smart enough to provide
working versions (either the GNU or the FreeBSD variant).

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

> BTW, seems like doing PATH=$BINDIR:$PATH in the script would be a lot
> easier than hacking all the references to programs --- and it covers
> the possibility that one of the invoked programs tries to call another.

I'm really hesitant to changing the path, even if only temporarily. Will
ponder.

> The other bit of environment state that initdb currently depends on is
> USER.  This is a big risk factor IMHO, since it won't be right if you
> are su'd to the postgres account.  Can you add code to verify that it
> is set (or set it if not) and that it matches the actual ownership of
> the process?

Yes, I noticed that too. Again, I really don't think that the script
should set USER. If the user chose to unset it, they might have had a
reason for it. The same happened in the createdb, etc. scripts and in
those cases there wasn't even a point for knowing the user at all, AFAI
recall. 

Seems like cleaning out the logic of initdb in general is a good idea, so
I'll work on that.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden