Thread: [PATCH] Improve portability of pgweb/load_initial_data.sh

[PATCH] Improve portability of pgweb/load_initial_data.sh

From
Nils
Date:
The shell script doesn't use bash extensions and bash may not be
available on all systems at that location.

If CDPATH is set, in certain cases, the call to cd can result in
unwanted behaviour.
---
 pgweb/load_initial_data.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/pgweb/load_initial_data.sh b/pgweb/load_initial_data.sh
index fb16e70c..c419f298 100755
--- a/pgweb/load_initial_data.sh
+++ b/pgweb/load_initial_data.sh
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 # We keep this in a separate script because using initial_data.xxx in django will overwrite
 # critical data in the database when running a 'syncdb'. We'd like to keep the ability to
@@ -8,7 +8,7 @@ echo WARNING: this may overwrite some data in the database with an initial set o
 echo 'Are you sure you want this (answer "yes" to overwrite)'
 read R
 
-cd $(dirname $0)
+CDPATH= cd $(dirname $0)
 
 if [ "$R" == "yes" ]; then
    find . -name data.json | xargs ../manage.py loaddata
-- 
2.31.1




Re: [PATCH] Improve portability of pgweb/load_initial_data.sh

From
Magnus Hagander
Date:
Hi!

Yeah, I think the fact that it says bash is just a "knee-jerk default" and not that it ever did either. So I have no problem changing that to sh. I'm a bit curious though, as to in which scenario this actually causes a problem?

The second change I'm less sure about. There are many different things you could change to break a script. This is one of them. You could change PATH, or you could replace "find" or "xargs" with commands that don't work the same way. CDPATH is not a variable that should, I believe, ever be exported into non-interactive scripts in the first place.

//Magnus

On Sun, Nov 7, 2021 at 5:49 PM Nils <nils@nilsand.re> wrote:
The shell script doesn't use bash extensions and bash may not be
available on all systems at that location.

If CDPATH is set, in certain cases, the call to cd can result in
unwanted behaviour.
---
 pgweb/load_initial_data.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/pgweb/load_initial_data.sh b/pgweb/load_initial_data.sh
index fb16e70c..c419f298 100755
--- a/pgweb/load_initial_data.sh
+++ b/pgweb/load_initial_data.sh
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh

 # We keep this in a separate script because using initial_data.xxx in django will overwrite
 # critical data in the database when running a 'syncdb'. We'd like to keep the ability to
@@ -8,7 +8,7 @@ echo WARNING: this may overwrite some data in the database with an initial set o
 echo 'Are you sure you want this (answer "yes" to overwrite)'
 read R

-cd $(dirname $0)
+CDPATH= cd $(dirname $0)

 if [ "$R" == "yes" ]; then
    find . -name data.json | xargs ../manage.py loaddata
--
2.31.1





--

Re: [PATCH] Improve portability of pgweb/load_initial_data.sh

From
Nils Andre
Date:
Hi,

On Mon, Nov 08, 2021 at 10:03:50AM +0100, Magnus Hagander wrote:
> Yeah, I think the fact that it says bash is just a "knee-jerk default" and
> not that it ever did either. So I have no problem changing that to sh. I'm
> a bit curious though, as to in which scenario this actually causes a
> problem?

This causes problems on [NixOS][1] which only has `/bin/sh` and
`/usr/bin/env` in the location one would "expect" them.

> The second change I'm less sure about. There are many different things you
> could change to break a script. This is one of them. You could change PATH,
> or you could replace "find" or "xargs" with commands that don't work the
> same way. CDPATH is not a variable that should, I believe, ever be exported
> into non-interactive scripts in the first place.

I didn't realise I was exporting CDPATH, which is ~~probably~~ a mistake
(and would have prevented previous painful and long headaches).

For what it's worth, I use a program I have written that makes use of
CDPATH (and hence requires it to be exported (but I think I will
reconsider the program's usage of CDPATH)).

However I do understand this is an issue with my particular setup.

Attached, is the patch amended without the CDPATH change.

Thanks,

Nils

[1]: https://nixos.org/

> //Magnus
> 
> On Sun, Nov 7, 2021 at 5:49 PM Nils <nils@nilsand.re> wrote:
> 
> > The shell script doesn't use bash extensions and bash may not be
> > available on all systems at that location.
> >
> > If CDPATH is set, in certain cases, the call to cd can result in
> > unwanted behaviour.
> > ---
> >  pgweb/load_initial_data.sh | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/pgweb/load_initial_data.sh b/pgweb/load_initial_data.sh
> > index fb16e70c..c419f298 100755
> > --- a/pgweb/load_initial_data.sh
> > +++ b/pgweb/load_initial_data.sh
> > @@ -1,4 +1,4 @@
> > -#!/bin/bash
> > +#!/bin/sh
> >
> >  # We keep this in a separate script because using initial_data.xxx in
> > django will overwrite
> >  # critical data in the database when running a 'syncdb'. We'd like to
> > keep the ability to
> > @@ -8,7 +8,7 @@ echo WARNING: this may overwrite some data in the database
> > with an initial set o
> >  echo 'Are you sure you want this (answer "yes" to overwrite)'
> >  read R
> >
> > -cd $(dirname $0)
> > +CDPATH= cd $(dirname $0)
> >
> >  if [ "$R" == "yes" ]; then
> >     find . -name data.json | xargs ../manage.py loaddata
> > --
> > 2.31.1
> >
> >
> >
> >
> 
> -- 
>  Magnus Hagander
>  Me: https://www.hagander.net/ <http://www.hagander.net/>
>  Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

Attachment

Re: [PATCH] Improve portability of pgweb/load_initial_data.sh

From
Magnus Hagander
Date:
On Tue, Nov 9, 2021 at 11:57 PM Nils Andre <nils@nilsand.re> wrote:
Hi,

On Mon, Nov 08, 2021 at 10:03:50AM +0100, Magnus Hagander wrote:
> Yeah, I think the fact that it says bash is just a "knee-jerk default" and
> not that it ever did either. So I have no problem changing that to sh. I'm
> a bit curious though, as to in which scenario this actually causes a
> problem?

This causes problems on [NixOS][1] which only has `/bin/sh` and
`/usr/bin/env` in the location one would "expect" them.

Hmm. Interesting. Anyway, this part seems perfectly fine to fix. 


> The second change I'm less sure about. There are many different things you
> could change to break a script. This is one of them. You could change PATH,
> or you could replace "find" or "xargs" with commands that don't work the
> same way. CDPATH is not a variable that should, I believe, ever be exported
> into non-interactive scripts in the first place.

I didn't realise I was exporting CDPATH, which is ~~probably~~ a mistake
(and would have prevented previous painful and long headaches).

I'm pretty sure that one will break a lot of other things... 


For what it's worth, I use a program I have written that makes use of
CDPATH (and hence requires it to be exported (but I think I will
reconsider the program's usage of CDPATH)).

I would recommend that :)


However I do understand this is an issue with my particular setup.

Attached, is the patch amended without the CDPATH change.


Thanks, applied as such!

//Magnus