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)