[GRASS-user] g.mremove error: "Argument list too long"

Hi

I am using GRASS for a simulation which generates litrealy thousands
of layers. Before I start a new simulation, I want to delete all
existing layers, and I run into th following error message:

g.mremove -f rast=* vect=* region=*

Collecting map names for current mapset <simulation>...
Forcing ...
exec: 218: g.remove: Argument list too long

Is there anything I can do? except iterating through all layers and
deleting them separately?

And if no, How could I do this easily?

Thanks

Rainer

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa

Hi,

How about separating it in smaller chunks.
Try 3 comands first
g.mremove -f rast=*
g.mremove -f vect=*
g.mremove -f region=*

If you still get "argument list to long" you will have to split the
rast/vect/region list once more. I don't know how your rasters are
named but, for example, remove all that starts with the letter a
g.remove -f rast=a*

or some other division

Cheers
Daniel

On Wed, Sep 24, 2008 at 10:27 AM, Rainer M Krug <r.m.krug@gmail.com> wrote:

Hi

I am using GRASS for a simulation which generates litrealy thousands
of layers. Before I start a new simulation, I want to delete all
existing layers, and I run into th following error message:

g.mremove -f rast=* vect=* region=*

Collecting map names for current mapset <simulation>...
Forcing ...
exec: 218: g.remove: Argument list too long

Is there anything I can do? except iterating through all layers and
deleting them separately?

And if no, How could I do this easily?

Thanks

Rainer

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

On Wed, Sep 24, 2008 at 4:01 PM, Daniel Victoria
<daniel.victoria@gmail.com> wrote:

Hi,

How about separating it in smaller chunks.
Try 3 comands first
g.mremove -f rast=*
g.mremove -f vect=*
g.mremove -f region=*

That would not help much - all (except of a handfull of layers) are raster

If you still get "argument list to long" you will have to split the
rast/vect/region list once more. I don't know how your rasters are
named but, for example, remove all that starts with the letter a
g.remove -f rast=a*

That would be an option - but as it is used in a simulation, I don't
know for sure that not to many starting with a are created.
I therefore resorted to iterate through them:

for I in `g.mlist type=rast`;do g.remove $I; done

But in general, I would consider it a bug if an operation with
wildcard results in an error when to many are selected. I will file a
bug report for that.

Thanks

Rainer

or some other division

Cheers
Daniel

On Wed, Sep 24, 2008 at 10:27 AM, Rainer M Krug <r.m.krug@gmail.com> wrote:

Hi

I am using GRASS for a simulation which generates litrealy thousands
of layers. Before I start a new simulation, I want to delete all
existing layers, and I run into th following error message:

g.mremove -f rast=* vect=* region=*

Collecting map names for current mapset <simulation>...
Forcing ...
exec: 218: g.remove: Argument list too long

Is there anything I can do? except iterating through all layers and
deleting them separately?

And if no, How could I do this easily?

Thanks

Rainer

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa

I've bumped into this problem before, with the same error, but outside
GRASS. Which shows that this is not a GRASS bug but a limitation of
the operating system.

As for dividing the raster groups, probably your model output has some
sort of logic at how it names the raster (time period for example).
Use that to divide the groups. The starting with a was just a
suggestion...

Daniel

On Wed, Sep 24, 2008 at 11:50 AM, Rainer M Krug <r.m.krug@gmail.com> wrote:

On Wed, Sep 24, 2008 at 4:01 PM, Daniel Victoria
<daniel.victoria@gmail.com> wrote:

Hi,

How about separating it in smaller chunks.
Try 3 comands first
g.mremove -f rast=*
g.mremove -f vect=*
g.mremove -f region=*

That would not help much - all (except of a handfull of layers) are raster

If you still get "argument list to long" you will have to split the
rast/vect/region list once more. I don't know how your rasters are
named but, for example, remove all that starts with the letter a
g.remove -f rast=a*

That would be an option - but as it is used in a simulation, I don't
know for sure that not to many starting with a are created.
I therefore resorted to iterate through them:

for I in `g.mlist type=rast`;do g.remove $I; done

But in general, I would consider it a bug if an operation with
wildcard results in an error when to many are selected. I will file a
bug report for that.

Thanks

Rainer

or some other division

Cheers
Daniel

On Wed, Sep 24, 2008 at 10:27 AM, Rainer M Krug <r.m.krug@gmail.com> wrote:

Hi

I am using GRASS for a simulation which generates litrealy thousands
of layers. Before I start a new simulation, I want to delete all
existing layers, and I run into th following error message:

g.mremove -f rast=* vect=* region=*

Collecting map names for current mapset <simulation>...
Forcing ...
exec: 218: g.remove: Argument list too long

Is there anything I can do? except iterating through all layers and
deleting them separately?

And if no, How could I do this easily?

Thanks

Rainer

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa

On 24/09/08 16:50, Rainer M Krug wrote:

On Wed, Sep 24, 2008 at 4:01 PM, Daniel Victoria
<daniel.victoria@gmail.com> wrote:

Hi,

How about separating it in smaller chunks.
Try 3 comands first
g.mremove -f rast=*
g.mremove -f vect=*
g.mremove -f region=*

That would not help much - all (except of a handfull of layers) are raster

If you still get "argument list to long" you will have to split the
rast/vect/region list once more. I don't know how your rasters are
named but, for example, remove all that starts with the letter a
g.remove -f rast=a*

That would be an option - but as it is used in a simulation, I don't
know for sure that not to many starting with a are created.
I therefore resorted to iterate through them:

for I in `g.mlist type=rast`;do g.remove $I; done

But in general, I would consider it a bug if an operation with
wildcard results in an error when to many are selected. I will file a
bug report for that.

There is a C replacement of the current scripts in the GRASS 6.x and GRASS 7.x development branches (see e.g. [1]).
Maybe you could just compile that and see if it solves the problem.

[1] http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/general/g.mremove

Moritz

On Thu, Sep 25, 2008 at 9:13 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 24/09/08 16:50, Rainer M Krug wrote:

On Wed, Sep 24, 2008 at 4:01 PM, Daniel Victoria
<daniel.victoria@gmail.com> wrote:

Hi,

How about separating it in smaller chunks.
Try 3 comands first
g.mremove -f rast=*
g.mremove -f vect=*
g.mremove -f region=*

That would not help much - all (except of a handfull of layers) are raster

If you still get "argument list to long" you will have to split the
rast/vect/region list once more. I don't know how your rasters are
named but, for example, remove all that starts with the letter a
g.remove -f rast=a*

That would be an option - but as it is used in a simulation, I don't
know for sure that not to many starting with a are created.
I therefore resorted to iterate through them:

for I in `g.mlist type=rast`;do g.remove $I; done

But in general, I would consider it a bug if an operation with
wildcard results in an error when to many are selected. I will file a
bug report for that.

There is a C replacement of the current scripts in the GRASS 6.x and GRASS
7.x development branches (see e.g. [1]).
Maybe you could just compile that and see if it solves the problem.

[1]
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/general/g.mremove

Moritz

Thanks - I'll do so on a later stage. For now I am iteratting...

Rainer

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa

Moritz Lennert wrote:

There is a C replacement of the current scripts in the GRASS 6.x and
GRASS 7.x development branches (see e.g. [1]).
Maybe you could just compile that and see if it solves the problem.

Note that the C version relies upon new features in libgis
(specifically, in lib/gis/ls.c) and the build system, so you can't
just import general/g.mremove from SVN into 6.3.

However, there is also a standalone version (named g.xremove) in the
GRASS add-ons repository:

https://svn.osgeo.org/grass/grass-addons/general/g.xremove

Also, g.xlist:

https://svn.osgeo.org/grass/grass-addons/general/g.xlist

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

On Wed, Sep 24, 2008 at 5:04 PM, Daniel Victoria
<daniel.victoria@gmail.com> wrote:

I've bumped into this problem before, with the same error, but outside
GRASS. Which shows that this is not a GRASS bug but a limitation of
the operating system.

AFAIK, to find the limit, you can run (file is from glibc-devel):

grep ARG_MAX /usr/include/linux/limits.h
#define ARG_MAX 131072 /* # bytes of args + environ for exec() */

Markus

Markus Neteler wrote:

On Wed, Sep 24, 2008 at 5:04 PM, Daniel Victoria
<daniel.victoria@gmail.com> wrote:
> I've bumped into this problem before, with the same error, but outside
> GRASS. Which shows that this is not a GRASS bug but a limitation of
> the operating system.

AFAIK, to find the limit, you can run (file is from glibc-devel):

grep ARG_MAX /usr/include/linux/limits.h
#define ARG_MAX 131072 /* # bytes of args + environ for exec() */

It's more robust to use sysconf(_SC_ARG_MAX), as the limit isn't
necessarily fixed at compile time (e.g. it can vary between kernel
versions).

Also, the limit is divided between argv and the environment. If you
have a lot of space taken up by environment variables, it will eat
into the space available. This can be significant on older systems,
where the limit may be as low as 4KiB (a single page of memory).

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