[GRASS5] winGRASS: mingw32 and execl (g.list)

GRASS GIS GRASS GIS developer
1

Hi,

I was able to make further changes for winGRASS native (thanks to
instructions of Radim how to compile all the needed libs).
Now all modules except for display related libs/modules
are compilable.

Some quick tests in 'commmand.com' with r.mapcalc, r.slope.aspect,
v.voronoi were successful. I kept the data in a network directory
so that I was able to display the new maps via Linux. In future
QGIS 0.8 or other software will take care of the display
(or someone ports also the display stuff).

Now a question: While 'g.list' compiled, it just does not display
anything and exits. May execl() be the problem?
general/manage/cmd/list.c

Or do we have to implement some .../path/... vs ...\path\...
tricks there?

Any ideas?

Markus

2

On Thu, Jan 19, 2006 at 04:41:50PM +0100, Markus Neteler wrote:

Hi,

I was able to make further changes for winGRASS native (thanks to
instructions of Radim how to compile all the needed libs).
Now all modules except for display related libs/modules
are compilable.

Some quick tests in 'commmand.com' with r.mapcalc, r.slope.aspect,
v.voronoi were successful. I kept the data in a network directory
so that I was able to display the new maps via Linux. In future
QGIS 0.8 or other software will take care of the display
(or someone ports also the display stuff).

Now a question: While 'g.list' compiled, it just does not display
anything and exits. May execl() be the problem?
general/manage/cmd/list.c

Or do we have to implement some .../path/... vs ...\path\...
tricks there?

an addition:
If so, could we automatically change / to \ in G_system()
to resolve such cases using G_str_replace():

general/manage/lib/do_copy.c
...
            sprintf (command, "%s/etc/copy '%s' '", G_gisbase(), path);
            G__file_name (path, list[n].element[i], new, G_mapset());
            strcat (command, path);
            strcat (command, "'");
            system (command);
...

?

Markus

3

On Thu, 19 Jan 2006, Markus Neteler wrote:

On Thu, Jan 19, 2006 at 04:41:50PM +0100, Markus Neteler wrote:
> Hi,
>
> I was able to make further changes for winGRASS native (thanks to
> instructions of Radim how to compile all the needed libs).
> Now all modules except for display related libs/modules
> are compilable.
>
> Some quick tests in 'commmand.com' with r.mapcalc, r.slope.aspect,
> v.voronoi were successful. I kept the data in a network directory
> so that I was able to display the new maps via Linux. In future
> QGIS 0.8 or other software will take care of the display
> (or someone ports also the display stuff).
>
> Now a question: While 'g.list' compiled, it just does not display
> anything and exits. May execl() be the problem?
> general/manage/cmd/list.c
>
> Or do we have to implement some .../path/... vs ...\path\...
> tricks there?

an addition:
If so, could we automatically change / to \ in G_system()
to resolve such cases using G_str_replace():

general/manage/lib/do_copy.c
...
            sprintf (command, "%s/etc/copy '%s' '", G_gisbase(), path);
            G__file_name (path, list[n].element[i], new, G_mapset());
            strcat (command, path);
            strcat (command, "'");
            system (command);
...

?

Markus,

Since the other commands work, the handling of path and file names may not
be the problem. All recent Windows systems respect / as a path separator,
as far as I know - try dir "somedir/somedir" to see - if it isn't quoted,
some Windows programs and command.com shell commands try to interpret it
as an argument. It's much more likely to be execl(), I feel.

Roger

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

4

Could the Windows-native GRASS run with the new GIS Manager?

It would use Windows native TclTk and doesn't require X11 or X11 emulation.
It uses the PNG driver instead of the xdriver, and all displays take place
in a TclTk canvas rather than an x-monitor. I think all but about a dozen
GRASS commands--including displays--should run.

The main ones missing include NVIZ, digitizing, and raster rectification.

Both NVIZ and vector digitization should be fixable since both depend
primarily on TclTk.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Thu, 19 Jan 2006 16:47:36 +0100
To: grass developers list <grass5@grass.itc.it>
Subject: Re: [GRASS5] winGRASS: mingw32 and execl (g.list)

On Thu, Jan 19, 2006 at 04:41:50PM +0100, Markus Neteler wrote:

Hi,

I was able to make further changes for winGRASS native (thanks to
instructions of Radim how to compile all the needed libs).
Now all modules except for display related libs/modules
are compilable.

Some quick tests in 'commmand.com' with r.mapcalc, r.slope.aspect,
v.voronoi were successful. I kept the data in a network directory
so that I was able to display the new maps via Linux. In future
QGIS 0.8 or other software will take care of the display
(or someone ports also the display stuff).

Now a question: While 'g.list' compiled, it just does not display
anything and exits. May execl() be the problem?
general/manage/cmd/list.c

Or do we have to implement some .../path/... vs ...\path\...
tricks there?

an addition:
If so, could we automatically change / to \ in G_system()
to resolve such cases using G_str_replace():

general/manage/lib/do_copy.c
...
            sprintf (command, "%s/etc/copy '%s' '", G_gisbase(), path);
            G__file_name (path, list[n].element[i], new, G_mapset());
            strcat (command, path);
            strcat (command, "'");
            system (command);
...

?

Markus

5

Roger Bivand wrote:

Since the other commands work, the handling of path and file names may not
be the problem. All recent Windows systems respect / as a path separator,

Use of / as a path separator has worked since DOS 2.x (the first
version of DOS which had directories). The only situation where you
have to use \ is in command-line arguments, where / is used to
indicate options (analogous to - on Unix).

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

6

Markus Neteler wrote:

Now a question: While 'g.list' compiled, it just does not display
anything and exits. May execl() be the problem?
general/manage/cmd/list.c

Possibly. mon.start uses spawnl() instead:

  #ifdef __W98__
  
  #include <process.h>
  
  #define execl(fullpath,path,name,bg,link,nul) \
  do { \
    spawnl(_P_DETACH,fullpath,path,name,"-",link,nul); \
    return 0; \
  } while (0)
  
  #endif /* __W98__ */

However, if list.c compiles and links, something is providing an
execl() function.

It seems more likely that the access() check is failing. Maybe the
lister program has a ".exe" suffix cauing it not to be found?

Ideally, libgis needs a standard interface for command execution.
There is already a (mostly untested) Unix implementation in
lib/gis/spawn.c. A Windows implementation would need to use
CreateProcess instead.

Or do we have to implement some .../path/... vs ...\path\...
tricks there?

Nope; it isn't related to path handling.

FWIW, I will be able to help on Windows issues shortly. The reason why
I haven't been around much is that I've just got a new PC (running
Windows XP Pro), and I've been rather busy setting it up and
re-learning how to use Windows.

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

7

Michael Barton wrote:

It would use Windows native TclTk and doesn't require X11 or X11 emulation.
It uses the PNG driver instead of the xdriver, and all displays take place
in a TclTk canvas rather than an x-monitor. I think all but about a dozen
GRASS commands--including displays--should run.

The main ones missing include NVIZ, digitizing, and raster rectification.

Both NVIZ and vector digitization should be fixable since both depend
primarily on TclTk.

The Togl widget (OpenGL canvas widget) which NVIZ uses supports
Windows. The main portability issue is likely to be the glX stuff in
do_zoom.c; if that can be disabled (it isn't necessary for normal
operation), getting it to work natively on Windows shouldn't be too
much of a problem.

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

8

On Sun, Jan 22, 2006 at 09:39:59AM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> Now a question: While 'g.list' compiled, it just does not display
> anything and exits. May execl() be the problem?
> general/manage/cmd/list.c

OK, it's not execl().

The problem is here:
lib/gis/list.c

        if (lister)
            sprintf(buf,"ls '%s'", path);
        else
            sprintf(buf,"ls -C '%s'", path);

which is unlikely to work in MS-Windows. No idea, how to
solve that, though. Someone may implement a workaround
for MS-Windows.

Markus

9

Markus Neteler wrote:

> > Now a question: While 'g.list' compiled, it just does not display
> > anything and exits. May execl() be the problem?
> > general/manage/cmd/list.c
>

OK, it's not execl().

The problem is here:
lib/gis/list.c

        if (lister)
            sprintf(buf,"ls '%s'", path);
        else
            sprintf(buf,"ls -C '%s'", path);

which is unlikely to work in MS-Windows. No idea, how to
solve that, though. Someone may implement a workaround
for MS-Windows.

For Unix, the standard way to enumerate a directory's contents is
with opendir/readdir/closedir, e.g.:

  DIR *dir = opendir(path);

  for (;:wink:
  {
    struct dirent *d = readdir(dir);

    if (!d)
      break;

    puts(d->d_name);
  }

  closedir(dir);

Windows has FindFirstFile/FindNextFile/FindClose, e.g.:

  WIN32_FIND_DATA data;
  HANDLE handle;

  handle = FindFirstFile("*", &data);

  for (;:wink:
  {
    if (!handle)
      break;

    puts(data.cFileName);

    if (!FindNextFile(handle, &data))
      break;
  }

  FindClose(handle);

More generally, we should stop spawning external programs for simple
tasks, e.g. ls, rm, mv, cat. We need to examine all uses of system(),
G_system() and G_popen(). Many (most?) of those calls will introduce
portability issues.

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