Re: initdb.sh fixed

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: initdb.sh fixed
Дата
Msg-id 199912182021.PAA05716@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: initdb.sh fixed  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: initdb.sh fixed  (Peter Eisentraut <peter_e@gmx.net>)
Список 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@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: pgindent (Re: [HACKERS] LONG varsize - how to go on)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] Lock