Thread: pg_ctl failure with older Bourne shells (use ${1:+"$@"})

pg_ctl failure with older Bourne shells (use ${1:+"$@"})

From
Mike Coleman
Date:
Your name        :    Mike Coleman
Your email address    :    mkc@mathdogs.com


System Configuration
---------------------
  Architecture (example: Intel Pentium)      :alpha

  Operating System (example: Linux 2.0.26 ELF)     :Tru64 5.1

  PostgreSQL version (example: PostgreSQL-7.2.1):   PostgreSQL-7.2.1

  Compiler used (example:  gcc 2.95.2)        :gcc 3.1


Please enter a FULL description of your problem:
------------------------------------------------

The pg_ctl script uses the "$@" construct.  Newer shells will replace
this with nothing if $@ is empty, but older shells will not.  The
alternate form in the patch below will work for both new and old
shells.


Please describe a way to repeat the problem.   Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------

The problem occurs with this command, for example:

$ /usr/local/pgsql/bin/pg_ctl -D /data1/postgres-0 -l logfile start




If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------


--- /usr/local/pgsql/bin/pg_ctl.dist    2002-07-18 11:34:25.000000000 -0500
+++ /usr/local/pgsql/bin/pg_ctl 2002-07-18 14:44:35.000000000 -0500
@@ -332,12 +332,12 @@
     fi

     if [ -n "$logfile" ]; then
-        "$po_path" "$@" </dev/null >>$logfile 2>&1 &
+        "$po_path" ${1:+"$@"} </dev/null >>$logfile 2>&1 &
     else
         # when starting without log file, redirect stderr to stdout, so
         # pg_ctl can be invoked with >$logfile and still have pg_ctl's
         # stderr on the terminal.
-        "$po_path" "$@" </dev/null 2>&1 &
+        "$po_path" ${1:+"$@"} </dev/null 2>&1 &
     fi

     # if had an old lockfile, check to see if we were able to start

Re: pg_ctl failure with older Bourne shells (use ${1:+"$@"})

From
Bruce Momjian
Date:
Yes, I have seen this fix before.  Are people still using shells that
don't handle "$@" properly?  I guess so or you wouldn't have reported
it.

We only use "$@" in a few places so I am applying this patch.

---------------------------------------------------------------------------

Mike Coleman wrote:
> Your name        :    Mike Coleman
> Your email address    :    mkc@mathdogs.com
>
>
> System Configuration
> ---------------------
>   Architecture (example: Intel Pentium)      :alpha
>
>   Operating System (example: Linux 2.0.26 ELF)     :Tru64 5.1
>
>   PostgreSQL version (example: PostgreSQL-7.2.1):   PostgreSQL-7.2.1
>
>   Compiler used (example:  gcc 2.95.2)        :gcc 3.1
>
>
> Please enter a FULL description of your problem:
> ------------------------------------------------
>
> The pg_ctl script uses the "$@" construct.  Newer shells will replace
> this with nothing if $@ is empty, but older shells will not.  The
> alternate form in the patch below will work for both new and old
> shells.
>
>
> Please describe a way to repeat the problem.   Please try to provide a
> concise reproducible example, if at all possible:
> ----------------------------------------------------------------------
>
> The problem occurs with this command, for example:
>
> $ /usr/local/pgsql/bin/pg_ctl -D /data1/postgres-0 -l logfile start
>
>
>
>
> If you know how this problem might be fixed, list the solution below:
> ---------------------------------------------------------------------
>
>
> --- /usr/local/pgsql/bin/pg_ctl.dist    2002-07-18 11:34:25.000000000 -0500
> +++ /usr/local/pgsql/bin/pg_ctl 2002-07-18 14:44:35.000000000 -0500
> @@ -332,12 +332,12 @@
>      fi
>
>      if [ -n "$logfile" ]; then
> -        "$po_path" "$@" </dev/null >>$logfile 2>&1 &
> +        "$po_path" ${1:+"$@"} </dev/null >>$logfile 2>&1 &
>      else
>          # when starting without log file, redirect stderr to stdout, so
>          # pg_ctl can be invoked with >$logfile and still have pg_ctl's
>          # stderr on the terminal.
> -        "$po_path" "$@" </dev/null 2>&1 &
> +        "$po_path" ${1:+"$@"} </dev/null 2>&1 &
>      fi
>
>      # if had an old lockfile, check to see if we were able to start
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
Index: src/bin/pg_ctl/pg_ctl.sh
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_ctl/pg_ctl.sh,v
retrieving revision 1.25
diff -c -r1.25 pg_ctl.sh
*** src/bin/pg_ctl/pg_ctl.sh    29 Sep 2001 03:09:32 -0000    1.25
--- src/bin/pg_ctl/pg_ctl.sh    19 Jul 2002 13:48:21 -0000
***************
*** 332,343 ****
      fi

      if [ -n "$logfile" ]; then
!         "$po_path" "$@" </dev/null >>$logfile 2>&1 &
      else
          # when starting without log file, redirect stderr to stdout, so
          # pg_ctl can be invoked with >$logfile and still have pg_ctl's
          # stderr on the terminal.
!         "$po_path" "$@" </dev/null 2>&1 &
      fi

      # if had an old lockfile, check to see if we were able to start
--- 332,343 ----
      fi

      if [ -n "$logfile" ]; then
!         "$po_path" ${1:+"$@"} </dev/null >>$logfile 2>&1 &
      else
          # when starting without log file, redirect stderr to stdout, so
          # pg_ctl can be invoked with >$logfile and still have pg_ctl's
          # stderr on the terminal.
!         "$po_path" ${1:+"$@"} </dev/null 2>&1 &
      fi

      # if had an old lockfile, check to see if we were able to start
Index: src/bin/pgaccess/main.tcl
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pgaccess/main.tcl,v
retrieving revision 1.6
diff -c -r1.6 main.tcl
*** src/bin/pgaccess/main.tcl    2 Jul 2002 06:11:23 -0000    1.6
--- src/bin/pgaccess/main.tcl    19 Jul 2002 13:48:22 -0000
***************
*** 1,6 ****
  #!/bin/sh
  # the next line restarts using wish \
! exec wish "$0" "$@"

  image create bitmap dnarw -data  {
  #define down_arrow_width 15
--- 1,6 ----
  #!/bin/sh
  # the next line restarts using wish \
! exec wish "$0" ${1:+"$@"}

  image create bitmap dnarw -data  {
  #define down_arrow_width 15

Re: pg_ctl failure with older Bourne shells (use ${1:+"$@"})

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, I have seen this fix before.  Are people still using shells that
> don't handle "$@" properly?  I guess so or you wouldn't have reported
> it.

I remember having submitted just such a patch a few years ago (for a
different one of our scripts of course) when I was still using HPUX 9.
I'm not sure if later HPUXen have better shells.  Plain /bin/sh on this
platform is ancient.

> We only use "$@" in a few places so I am applying this patch.

Could you check for other scripts where the same thing may have snuck
in?

BTW, O'Reilly's "Unix Power Tools" recommends
    ${1+"$@"}
as the most portable replacement for "$@".  Mike's version has :+
which is not the same.  My man page for the Bourne shell says

     ${parameter:+word}
                    If parameter is set and is non-null, substitute word;
                    otherwise substitute nothing.

     ...

     If the colon (:) is omitted from the above expressions, the shell only
     checks whether parameter is set or not.

It looks to me like the book's method is more correct --- it won't mess
up in the case where $1 has been explicitly given as "".

            regards, tom lane

Re: pg_ctl failure with older Bourne shells (use ${1:+"$@"})

From
Bruce Momjian
Date:
Tom Lane wrote:
> > We only use "$@" in a few places so I am applying this patch.
>
> Could you check for other scripts where the same thing may have snuck
> in?

Yes, I checked, and I saw pgaccess using it too.  I sent them a patch.

>
> BTW, O'Reilly's "Unix Power Tools" recommends
>     ${1+"$@"}
> as the most portable replacement for "$@".  Mike's version has :+
> which is not the same.  My man page for the Bourne shell says

Changed.

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

Re: pg_ctl failure with older Bourne shells (use ${1:+"$@"})

From
"Coleman, Michael"
Date:
Blah.  Yeah, I muffed that--don't use a colon.

Regarding Bruce's comment, you wouldn't think they're still around, but thi=
s is what /bin/sh does on Tru64 5.1.  (5.1 is almost the latest version; th=
ere's a 5.1a.)

Mike


> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Friday, July 19, 2002 9:38 AM
> To: Bruce Momjian
> Cc: Coleman, Michael; pgsql-bugs@postgresql.org; mkc@mathdogs.com
> Subject: Re: [BUGS] pg_ctl failure with older Bourne shells (use
> ${1:+"$@"})=20
>=20
>=20
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Yes, I have seen this fix before.  Are people still using=20
> shells that
> > don't handle "$@" properly?  I guess so or you wouldn't=20
> have reported
> > it.
>=20
> I remember having submitted just such a patch a few years ago (for a
> different one of our scripts of course) when I was still using HPUX 9.
> I'm not sure if later HPUXen have better shells.  Plain=20
> /bin/sh on this
> platform is ancient.
>=20
> > We only use "$@" in a few places so I am applying this patch.
>=20
> Could you check for other scripts where the same thing may have snuck
> in?
>=20
> BTW, O'Reilly's "Unix Power Tools" recommends
>     ${1+"$@"}
> as the most portable replacement for "$@".  Mike's version has :+
> which is not the same.  My man page for the Bourne shell says
>=20
>      ${parameter:+word}
>                     If parameter is set and is non-null,=20
> substitute word;
>                     otherwise substitute nothing.
>=20
>      ...
>=20
>      If the colon (:) is omitted from the above expressions,=20
> the shell only
>      checks whether parameter is set or not.
>=20
> It looks to me like the book's method is more correct --- it=20
> won't mess
> up in the case where $1 has been explicitly given as "".
>=20
>             regards, tom lane
>=20