Re: pgsql/src/bin/pg_dump pg_dumpall.sh

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql/src/bin/pg_dump pg_dumpall.sh
Date: 2002-04-11 21:03:01
Message-ID: 200204112103.g3BL31A03332@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Tom Lane wrote:
> momjian(at)postgresql(dot)org (Bruce Momjian - CVS) writes:
> > Modified files:
> > src/bin/pg_dump: pg_dumpall.sh
>
> > Log message:
> > Fix pg_upgrade to handle dbnames, user/group names with spaces.
>
> I think it's illusory to imagine that this fixes the issue. Unless
> "read"'s behavior is more tightly specified than I think, you are still
> gonna have trouble with leading, trailing, or consecutive blanks.

Yes, it does fail on leading/trailing spaces, but it is better than it
was before.

> I'm also concerned that you've opened up portability issues concerning
> newlines embedded in shell literals (eg, does that sed command portably
> do what you think?).

I certainly think so. It is:

echo "a b c" | sed 's/ /\
/g'

outputs:

a
b
c

Embedding backslash-n in 'sed' is a portability problem.

Clearly read has problems:

#$ read X
a b
#$ echo $X
a b

I could so IFS="newline" to handle the space issue. Let me try that.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(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-committers by date

  From Date Subject
Next Message Bruce Momjian - CVS 2002-04-11 21:16:30 pgsql/src/bin/pg_dump pg_dumpall.sh
Previous Message Tom Lane 2002-04-11 20:56:00 Re: pgsql/src/bin/pg_dump pg_dumpall.sh