Re: initdb.sh fixed

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: initdb.sh fixed
Date: 1999-12-18 20:21:06
Message-ID: 199912182021.PAA05716@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> People, I thought you would at least test this once before applying it. I
> explicitly (maybe not explicitly enough) mentioned it, because writing
> complex shell scripts is a nut job. Maybe this thing should really be
> written in C. Then there will be no EUID, no echo, no function, no grep,
> no whoami, or other problems. Perhaps the whole genbki.sh thing could be
> scrapped then, with initdb interpreting the DATA() macros itself. It
> would even reduce the overhead of calling postgres about 12 times and
> could get it down to 2 or 3. A project for 7.1?

I had enough trouble applying the patch, let alone testing it...

Making it in C presents all sorts of portability problems that are even
harder to figure. There is no portability free lunch. I think a script
is the way to go with this.

The big problem seems to be reliance on bash-isms like $UID and
functions with spaces like:

function func () {
}

Only bash knows about that. I have written enough shells scripts to
know that, but it is hard to get that knowledge.

Also, env args without quotes around them is a problem.

All fixed now.

>
> On 1999-12-17, Bruce Momjian mentioned:
>
> > OK, initdb should now work. There were a variety of non-portable things
> > in initdb.sh, like assuming $EUID is defined, and other shell script and
> > command args that do not exist on BSDI.
>
> Hmm, that $EUID seems to have be the root of all trouble because then the
> 'insert ( data data data )' bootstrap commands are containing gaps. On the
> other hand, this was one of the key things that were supposed to be
> improved because relying on $USER was not su-safe. Maybe $UID would work,
> since initdb isn't supposed to be setuid anyway.

Again, a bash-ism. Let's face, it, the postgres binary is going to
croak on root anyway, so we are just doing an extra check in initdb.

>
> > I think I got them all. If anyone sees problems, let me know. This is
> > not really Peter's fault. It takes a long time to know what is
> > portable and what is not portable.
>
> The more time I spend with this the more I think that the only thing
> that's portable is echo. Oh wait, that's not portable either. :)

Don't think so.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-12-18 20:26:15 Re: [PATCHES] Lock
Previous Message Oliver Elphick 1999-12-18 18:31:05 Re: [HACKERS] SPI header dependencies