[GRASS-dev] Re: grass-dev Digest, Vol 10, Issue 46

GRASS GIS GRASS GIS developer
1

Probably showing undue ignorance, but I have to ask. How can we know if
something is bash specific or more generally POSIX-compatible?

Michael

On 2/18/07 9:08 PM, "grass-dev-request@grass.itc.it"
<grass-dev-request@grass.itc.it> wrote:

The only thing which you can absolutely rely upon is that /bin/sh will
be a POSIX-compatible Bourne shell. Anyone writing scripts would do
well to bear this in mind (IOW, please avoid using bash-specific
features).

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

2

Michael Barton wrote:

Probably showing undue ignorance, but I have to ask. How can we know
if something is bash specific or more generally POSIX-compatible?

the grass-bugs feedback loop. :slight_smile:

Hamish

3

Ah yes,

While x>0
    x=x+1

On 2/19/07 12:35 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Michael Barton wrote:

Probably showing undue ignorance, but I have to ask. How can we know
if something is bash specific or more generally POSIX-compatible?

the grass-bugs feedback loop. :slight_smile:

Hamish

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

4

Michael Barton wrote:

Probably showing undue ignorance, but I have to ask. How can we know if
something is bash specific or more generally POSIX-compatible?

Run it under a less "enhanced" shell such as ash or dash.

I suspect that this may be the "real" motivation for using dash for
/bin/sh on Ubuntu. Using bash as /bin/sh is asking for people to write
bash-specific scripts (and putting #!/bin/sh at the top of them).

Or see the "Shell & Utilities" section at:

  http://www.opengroup.org/onlinepubs/009695399/toc.htm

--
Glynn Clements <glynn@gclements.plus.com>

5

Michael Barton wrote:
> Probably showing undue ignorance, but I have to ask. How can we know
> if something is bash specific or more generally POSIX-compatible?

ash -n scriptname

$ ash -n r.tileset
r.tileset: 258: Syntax error: Bad for loop variable

$ cat -n r.tileset | grep '^.* 258'
   258 for ((min_i=0;min_i<min_n;min_i+=1)) ; do

(( )) is a Bashism. possible replacement:

min_i=0
while [ min_i -lt min_n ] ; do
   ...
   ...

   min_i=`expr $min_i + 1`
done

but the r.tileset script makes Heavy use of SIZE_ARRAY[0]="" style
Bash arrays, so I fear it will need to be totally rewritten or
declared "Bash only". Is this enough for such a test?

if [ "`basename $SHELL`" != "bash" ] ; then
   echo "$0: This script requires Bash" 2>&1
   exit 1
fi

(apparently not, starting ash from the bash prompt preserved $SHELL
as /bin/bash; but maybe it helps catch real world cases? I guess the
real issue is testing what the /bin/sh symlink points to. I guess
Init.sh could run a little test and set GRASS_HAVE_BASH=1, but it
is better to just fix r.tileset)

To my surprise SUBMITTING_SCRIPTS didn't say anything about Bashisms.
Fixed in 6.3 CVS.

scripts/r.in.wms/wms.request has SIZE_ARRAY[0]="", but AFAICT it goes
unused? Otherwise r.in.wms is ok?

Glynn Clements wrote:

Run it under a less "enhanced" shell such as ash or dash.

I suspect that this may be the "real" motivation for using dash for
/bin/sh on Ubuntu. Using bash as /bin/sh is asking for people to write
bash-specific scripts (and putting #!/bin/sh at the top of them).

see https://wiki.ubuntu.com/DashAsBinSh

"Ubuntu switched from Bash to Dash in Edgy to noticeably shorten boot
times. Apparently booting involves forking a LOT of shells, and Bash is
big, featureful, and slow (and has the most convoluted syntax of any
programming language that I know -- including APL -- but I digress...)"
--bronson http://lwn.net/Articles/220255/

The Ubuntu bug report for this is a passionate meeting of idealogues
and pragmatists, worthy of classic usenet:
  https://launchpad.net/ubuntu/+source/dash/+bug/61463
  http://www.ubuntuforums.org/archive/index.php/t-221769.html

"As the symlink is adjustable via a debconf question, any users who do
not wish to have a POSIX shell as the default can run dpkg-reconfigure
dash and restore bash."

Also on Debian [so prob Ubuntu as well] there is "update-alternatives"
to change where /bin/sh points to.

In other circles, the new Debian installer will use [d]ash as part of a
micro-deb (udeb) package. The motivation is that this is much smaller
than bash and can be included on the floppy disk installer -- just the
bare minimum to get the network install started. The package description
also mentions that it depends on less things, so is less likely to be
problematic on a machine suffering library hell/anemia.

http://packages.debian.org/unstable/debian-installer/dash-udeb

On Debian bash is a required package, and AFAICT it is on Ubuntu Edgy+
as well.

Hamish

6

Hamish wrote:

but the r.tileset script makes Heavy use of SIZE_ARRAY[0]="" style
Bash arrays, so I fear it will need to be totally rewritten or
declared "Bash only". Is this enough for such a test?

if [ "`basename $SHELL`" != "bash" ] ; then
   echo "$0: This script requires Bash" 2>&1
   exit 1
fi

(apparently not, starting ash from the bash prompt preserved $SHELL
as /bin/bash; but maybe it helps catch real world cases? I guess the
real issue is testing what the /bin/sh symlink points to. I guess
Init.sh could run a little test and set GRASS_HAVE_BASH=1, but it
is better to just fix r.tileset)

how about:

BASH_TEST[0]="" 2> /dev/null
if [ $? -ne 0 ] ; then
   echo "$0: This script requires Bash" 2>&1
   exit 1
fi

or just change the shebang to #!/bin/bash and let folks with it
in /usr/bin/bash or /usr/local/bin/bash live with the pain?

Hamish

7

Hamish wrote:

but the r.tileset script makes Heavy use of SIZE_ARRAY[0]="" style
Bash arrays, so I fear it will need to be totally rewritten or
declared "Bash only". Is this enough for such a test?

if [ "`basename $SHELL`" != "bash" ] ; then
   echo "$0: This script requires Bash" 2>&1
   exit 1
fi

(apparently not, starting ash from the bash prompt preserved $SHELL
as /bin/bash; but maybe it helps catch real world cases?

No. $SHELL contains the user's preferred interactive shell; it is set
on login from the last field in the user's entry in /etc/passwd, and
won't normally change thereafter.

It is used mainly by programs which provide an option to spawn an
interactive shell (a feature which goes back to a time when many
Unices didn't provide job control, so you couldn't just use Ctrl-Z to
suspend the program).

I guess the real issue is testing what the /bin/sh symlink points
to. I guess Init.sh could run a little test and set
GRASS_HAVE_BASH=1, but it is better to just fix r.tileset)

There's no guarantee that /bin/sh is a symlink. A more reliable test
is to check $BASH or $BASH_VERSION.

> Run it under a less "enhanced" shell such as ash or dash.
>
> I suspect that this may be the "real" motivation for using dash for
> /bin/sh on Ubuntu. Using bash as /bin/sh is asking for people to write
> bash-specific scripts (and putting #!/bin/sh at the top of them).

see https://wiki.ubuntu.com/DashAsBinSh

You shouldn't believe everything you read on the web :wink:

I'm aware that the stated reason is for speed, but I wouldn't expect
them to do such a thing with the stated intention of breaking stuff.

Not only would there be many people who would favour the quick fix of
going back to bash, but the ones in that camp are likely to be the
hardest to try to reason with; i.e. a combination of impatient "make
it work now" types, delusional "it's not really a problem" types, and
the "my scripts are broken but I'd prefer to claim it's your fault"
types).

OTOH, it could just be for speed; you can never be sure about other
people's motivations (and you can't necessarily be sure of your own).

--
Glynn Clements <glynn@gclements.plus.com>