Thread: BUG #5978: Running postgress in a shell script fails

The following bug has been logged online:

Bug reference:      5978
Logged by:          Paul Deschamps
Email address:      pdescham49@gmail.com
PostgreSQL version: 8.4.6
Operating system:   Ubuntu 10.4
Description:        Running postgress in a shell script fails
Details:

When running postgres in a shell using the -c option it looks as though it
parses the contents of the --command as command line arguments.


---BEGIN SCRIPT---
#!/bin/bash
psql --version
PCOMMAND='psql postgres -c"SELECT tablename FROM PG_TABLES limit 1;"'

echo "PGSQL - Execution from a shell script test"
echo
echo "Running Command:"${PCOMMAND}

echo "TEST 1 "
OUTPUT1=$(${PCOMMAND})
echo $OUTPUT1
echo
echo "TEST 2"
OUTPUT2=`$PCOMMAND`
echo $OUTPUT2
echo
echo "TEST 3"
OUTPUT3=`exec $PCOMMAND`
echo $OUTPUT3
echo
echo "TEST 4"
$PCOMMAND

echo "TEST 5"
psql postgres -c"SELECT tablename FROM PG_TABLES limit 1;"
---END SCRIPT---

---BEGIN OUTPUT---
[postgres@host03 scripts]$ ./test.sh
psql (PostgreSQL) 8.4.6
PGSQL - Execution from a shell script test

Running Command:psql postgres -c"SELECT tablename FROM PG_TABLES limit 1;"
TEST 1
psql: warning: extra command-line argument "FROM" ignored
psql: warning: extra command-line argument "PG_TABLES" ignored
psql: warning: extra command-line argument "limit" ignored
psql: warning: extra command-line argument "1;"" ignored
psql: FATAL:  role "tablename" does not exist


TEST 2
psql: warning: extra command-line argument "FROM" ignored
psql: warning: extra command-line argument "PG_TABLES" ignored
psql: warning: extra command-line argument "limit" ignored
psql: warning: extra command-line argument "1;"" ignored
psql: FATAL:  role "tablename" does not exist


TEST 3
psql: warning: extra command-line argument "FROM" ignored
psql: warning: extra command-line argument "PG_TABLES" ignored
psql: warning: extra command-line argument "limit" ignored
psql: warning: extra command-line argument "1;"" ignored
psql: FATAL:  role "tablename" does not exist


TEST 4
psql: warning: extra command-line argument "FROM" ignored
psql: warning: extra command-line argument "PG_TABLES" ignored
psql: warning: extra command-line argument "limit" ignored
psql: warning: extra command-line argument "1;"" ignored
psql: FATAL:  role "tablename" does not exist
TEST 5
 tablename
-----------
 pg_type
(1 row)


---END OUTPUT---

"Paul Deschamps" <pdescham49@gmail.com> writes:
> PostgreSQL version: 8.4.6
> Operating system:   Ubuntu 10.4
> Description:        Running postgress in a shell script fails
> Details:

> When running postgres in a shell using the -c option it looks as though it
> parses the contents of the --command as command line arguments.

> Running Command:psql postgres -c"SELECT tablename FROM PG_TABLES limit 1;"
> TEST 1
> psql: warning: extra command-line argument "FROM" ignored
> psql: warning: extra command-line argument "PG_TABLES" ignored
> psql: warning: extra command-line argument "limit" ignored
> psql: warning: extra command-line argument "1;"" ignored
> psql: FATAL:  role "tablename" does not exist

I think this is a bug in Ubuntu's version of getopt_long(); it does not
happen that way for me on any of the platforms I use.  I get either

psql: FATAL:  role "-cSELECT tablename FROM PG_TABLES limit 1;" does not exist

on platforms where getopt_long does not think it has a charter to try to
rearrange command line arguments, or

$ psql postgres -c"SELECT tablename FROM PG_TABLES limit 1;"
  tablename
--------------
 pg_statistic
(1 row)

on platforms where getopt_long does move the database name after the
switch+argument.  What you've evidently got is a getopt_long that tries
to rearrange the command-line arguments but produces the equivalent of

psql "-cSELECT" "postgres" "tablename" "FROM" "PG_TABLES" "limit" "1;"

which is flat out wrong.

Recommendation is to use the documented command line order, which is

    psql [OPTION]... [DBNAME [USERNAME]]

rather than assuming getopt_long will fix it for you.

You can try filing a bug against Ubuntu's glibc, but I dunno whether
you'll get any satisfaction there.  I think we've heard of this before
and the misbehavior is of long standing.

            regards, tom lane