[GRASS-dev] [GRASS GIS] #887: db.describe fails if $GISBASE contains a space

GRASS GRASS developer
1

#887: db.describe fails if $GISBASE contains a space
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
     Type: defect | Status: new
Priority: normal | Milestone: 6.5.0
Component: Database | Version: svn-releasebranch64
Keywords: spaces | Platform: Linux
      Cpu: x86-64 |
----------------------+-----------------------------------------------------
Hi,

If I move "dist.x86_64-unknown-linux-gnu/" to "dist.x86_64-unknown-linux
gnu/" (and edit ./bin.$ARCH/grass65), db.describe fails:

{{{
g.copy roads,roads2
db.describe roads2

D2/5: dbDbmscap(): opendir [/usr/local/src/grass/svn/grass65/dist.x86_64-
unknown-linux gnu/driver/db/]
D2/5: dbDbmscap(): opendir [/usr/local/src/grass/svn/grass65/dist.x86_64-
unknown-linux gnu/driver/db/]

sh: /usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux: No such
file or directory
dbmi: Protocol error
ERROR: Unable to start driver <dbf>
}}}

near EOF of lib/db/dbmi_client/start.c:
{{{
   execl("/bin/sh", "sh", "-c", startup, NULL);
}}}

The startup string is set correctly; I guess execl() wants to see quotes
in the string itself?

n.b. all programs in $GISBASE/driver/db/ are ELF binaries, so is sh really
needed at all? why not just run them directly?

Hamish

ps- building GRASS in a dir with spaces seems impossible because
Autoconf2.13 expansion code does not always quote $srcdir.
(unless we run a second sed script after autoconf2.13 to run around the
resulting `configure` file and quote variables as needed* -- but not all
variables, e.g. $pwd can expand to "pwd -W".

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/887&gt;
GRASS GIS <http://grass.osgeo.org>

2

#887: db.describe fails if $GISBASE contains a space
-----------------------+----------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Database | Version: svn-releasebranch64
Resolution: | Keywords: spaces
  Platform: Linux | Cpu: x86-64
-----------------------+----------------------------------------------------
Comment (by glynn):

Replying to [ticket:887 hamish]:

> near EOF of lib/db/dbmi_client/start.c:
{{{
   execl("/bin/sh", "sh", "-c", startup, NULL);
}}}
>
> The startup string is set correctly; I guess execl() wants to see quotes
in the string itself?

execl() doesn't care; it's "sh" which wants the quotes.

> n.b. all programs in $GISBASE/driver/db/ are ELF binaries, so is sh
really needed at all? why not just run them directly?

Why not, indeed :wink: IOW:

{{{
- execl("/bin/sh", "sh", "-c", startup, NULL);
+ execl(startup, startup, NULL);
}}}

Hmm. The !__MINGW32__ version uses _spawnl(). I'm not sure whether this is
an issue. The documentation says that arguments must be quoted, but I
don't think that applies to the program.

Actually ... maybe we should just replace the bulk of db_start_driver()
with G_spawn_ex(). Redirection (including to/from pipes) should work on
Windows now.

> ps- building GRASS in a dir with spaces seems impossible because
Autoconf2.13 expansion code does not always quote $srcdir.

Forbidding spaces at compile time isn't a problem, and is probably
inevitable. FWIW, I just use "/c/progra~1/..." for packages (e.g.
!GnuWin32) which are installed there (although apparently it's possible to
disable generation of 8.3 filenames).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/887#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

3

#887: db.describe fails if $GISBASE contains a space
-----------------------+----------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Database | Version: svn-releasebranch64
Resolution: | Keywords: spaces
  Platform: Linux | Cpu: x86-64
-----------------------+----------------------------------------------------
Comment (by neteler):

Is the attached change a 6.4 candidate?

Markus

PS: The spaces-in-path at compile time is discussed in #682

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/887#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

4

#887: db.describe fails if $GISBASE contains a space
-----------------------+----------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Database | Version: svn-releasebranch64
Resolution: | Keywords: spaces
  Platform: Linux | Cpu: x86-64
-----------------------+----------------------------------------------------
Comment (by glynn):

Replying to [comment:2 neteler]:
> Is the attached change a 6.4 candidate?
I think so.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/887#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

5

#887: db.describe fails if $GISBASE contains a space
-----------------------+----------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Database | Version: svn-releasebranch64
Resolution: fixed | Keywords: spaces
  Platform: Linux | Cpu: x86-64
-----------------------+----------------------------------------------------
Changes (by neteler):

  * status: new => closed
  * resolution: => fixed

Comment:

Fixed in r41132 (6.4). In 6.5 and 7 it was already done.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/887#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

6

Glynn wrote:

Hmm. The !__MINGW32__ version uses _spawnl(). I'm not sure whether this
is an issue. The documentation says that arguments must be
quoted, but I don't think that applies to the program.

Actually ... maybe we should just replace the bulk of db_start_driver()
with G_spawn_ex(). Redirection (including to/from pipes) should work on
Windows now.

fwiw db/dbmi_client/start.c in trunk and that + G_system() in 6.5/6.4
still use _spawnl(), we should probably test anything that uses G_system()
for whitespace safety as well as the problematic dbf.exe client.

r.support (6.x), r.watershed(6+7)?

Hamish