[GRASS-dev] updates to grass startup

[cmbarton]

I just committed a set of patches to the GRASS startup tcltk files (gis_set.tcl, epsg_option.tcl, and file_option.tcl). These are designed to make creating a new location from EPSG code or georeferenced file more robust. This is especially important for Windows users who cannot make a new location with g.proj.

I’ve tested these on my Mac OSX with x11 GRASS cvs build of last Friday and they seem to be fine. Please test on other platforms.

Also, if we are going to have EPSG codes as a standard way to create a new location (and I think this is a handy way to go), can we distribute a copy of the EPSG file inside the GRASS directory structure (e.g., in the infamous catchall etc or another directory)? The EPSG file is ending up in different places on different architectures making it difficult to find. If it was always in the same place, within the GRASS hierarchy, it would be easy to make this the default location for the GUI.

Obviously the next thing to do is to make it searchable.

Michael

---

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

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

[H_B]

when creating a new location from EPSG code an xterm flashes up and then
disappears. This might have some important info/warning/error in it.

I have prepared the following patch, but not applied it as it makes the
script partially interactive. (ie it asks the user to press <enter> to
continue, but times out in 2 minutes [enough time to find a pen and
write down an error])

So not a great solution, but here it is.

Better? put a pause at end of exec grass-xterm-wrapper:

lib/init/epsg_option.tcl.in:

exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e \
         $env(GISBASE)/etc/make_location_epsg.sh \
         $epsg_code $epsgLocation $locpath >@stdout 2>@stderr; \
         read -t 120

or somehow like that?

Hamish

(attachments)

make_loc_pause.diff (2.01 KB)

[H_B]

Michael Barton wrote:

I just committed a set of patches to the GRASS startup tcltk files
(gis_set.tcl, epsg_option.tcl, and file_option.tcl). These are
designed to make creating a new location from EPSG code or
georeferenced file more robust. This is especially important for
Windows users who cannot make a new location with g.proj.

I¹ve tested these on my Mac OSX with x11 GRASS cvs build of last
Friday and they seem to be fine. Please test on other platforms.

now locations and mapsets are not sorted in alphabetical order.

Also, if we are going to have EPSG codes as a standard way to create a
new location (and I think this is a handy way to go), can we
distribute a copy of the EPSG file inside the GRASS directory
structure (e.g., in the infamous catchall etc or another directory)?
The EPSG file is ending up in different places on different
architectures making it difficult to find. If it was always in the
same place, within the GRASS hierarchy, it would be easy to make this
the default location for the GUI.

not for, but not strongly against, however:
- The EPSG database and proj.4 are likely to be updated more often than
GRASS is.
- packagers should set --with-proj-share=, ./configure should give a
clear error message if not found for home-brew. Tcl then finds this dir
in the "PROJSHARE" variable.

Obviously the next thing to do is to make it searchable.

yes please, and auto-fill the highlighted value in the create dialogue.

Hamish

[marisn]

Hi,

my cleanup just fixed bugs 5328 and 5373. It also pariatly fixed 5372
and 5371 (My fault - too much bugs in one report).

Summarising up:

Currently there is no mechanism to catch error if creating of new
location has failed. Current code always will look like it has suceed
and will restart GRASS to strat use newly created location. Hamish
code will only make error message visible to user (good thing), but
GRASS should not continue as if everything was OK.

When creating new location from EPSG code, there is some error in
cleaning up temporary location in case of error. (See below)

Creating new location from georeferenced file still will not work, as
it needs some (temporary) location to run g.proj. Probably
make_location_epsg.sh.in could be used to create new, similar script
for georeferenced file too. Or probaby some new script, that creates
valid temporary location and then cleans up for any module, that may
need temporary location for running (do we need such script?).

To reproduce problems - 1) rm .grassrc6 (This why n00bs report
unreporoducable errors - daily grass users always have .grassrc6 with
valid locations/mapsets);
2) create new location with EPSG code 1234 - tmp location is left over;
3) repeat 1st step and now create new location from valid
georeferenced file - error.

Currently I'm not as good in coding to fix those problems

Just trying to make GRASS fool proof,
Maris.

2006/12/13, Hamish <hamish_nospam@yahoo.com>:

when creating a new location from EPSG code an xterm flashes up and then
disappears. This might have some important info/warning/error in it.

I have prepared the following patch, but not applied it as it makes the
script partially interactive. (ie it asks the user to press <enter> to
continue, but times out in 2 minutes [enough time to find a pen and
write down an error])

So not a great solution, but here it is.

Better? put a pause at end of exec grass-xterm-wrapper:

lib/init/epsg_option.tcl.in:

exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e \
         $env(GISBASE)/etc/make_location_epsg.sh \
         $epsg_code $epsgLocation $locpath >@stdout 2>@stderr; \
         read -t 120

or somehow like that?

Hamish

[Paul_Kelly]

Hello Michael

On Tue, 12 Dec 2006, Michael Barton wrote:

I just committed a set of patches to the GRASS startup tcltk files
(gis_set.tcl, epsg_option.tcl, and file_option.tcl). These are designed to
make creating a new location from EPSG code or georeferenced file more
robust. This is especially important for Windows users who cannot make a new
location with g.proj.

BTW that is no longer true. g.setproj and etc/set_data work fine on Windows (better if you have Msys in your path though - I'm working on replacing a system("ls -C") call). If you click the "projection values" button in gis_set.tcl it will pop up a Window running set_data so you can create a location the traditional way. Current problem though is that the list of locations doesn't refresh to show the new location after you return from the box. I had a quick look a week or two ago but the design of gis_set.tcl seemed to make it very difficult to refresh that. Although if you click after the database directory and press Enter it refreshes. Maybe you have improved something to make that easier though?

I¹ve tested these on my Mac OSX with x11 GRASS cvs build of last Friday and
they seem to be fine. Please test on other platforms.

Also, if we are going to have EPSG codes as a standard way to create a new
location (and I think this is a handy way to go), can we distribute a copy
of the EPSG file inside the GRASS directory structure (e.g., in the infamous
catchall etc or another directory)? The EPSG file is ending up in different
places on different architectures making it difficult to find. If it was
always in the same place, within the GRASS hierarchy, it would be easy to
make this the default location for the GUI.

I tried to create a location with EPSG code but it just says "WARNING: The epsg-codes file was not found!" and nothing appears to happen. Surely it isn't necessary to have that file installed if you already know the code you need? It isn't used for anything other than browsing and while including it in GRASS is definitely preferable to having to look for it wherever it was installed with PROJ, my preference would be to remove it altogether and instead in some way generate the lists from the .csv files in lib/proj that are actually used by g.proj to generate the location. Not sure how to do that but I think it's very confusing the way the file used for browsing is different from and potentially out of sync with the file used in the location generation.

Or another option would be to use the PROJ.4 definitions in that file directly and forget about the roundabout way it is currently done by passing the EPSG code to g.proj as part of a PROJ-style projection description? Whatever's done will probably need a bit of work though.

Paul

[Paul_Kelly]

On Wed, 13 Dec 2006, Maris Nartiss wrote:

Hi,

my cleanup just fixed bugs 5328 and 5373. It also pariatly fixed 5372
and 5371 (My fault - too much bugs in one report).

Summarising up:

Currently there is no mechanism to catch error if creating of new
location has failed. Current code always will look like it has suceed
and will restart GRASS to strat use newly created location. Hamish
code will only make error message visible to user (good thing), but
GRASS should not continue as if everything was OK.

When creating new location from EPSG code, there is some error in
cleaning up temporary location in case of error. (See below)

Creating new location from georeferenced file still will not work, as
it needs some (temporary) location to run g.proj. Probably
make_location_epsg.sh.in could be used to create new, similar script
for georeferenced file too. Or probaby some new script, that creates
valid temporary location and then cleans up for any module, that may
need temporary location for running (do we need such script?).

I think we could maybe include the "demolocation" in the released distribution? It is small so not much overhead and contains a valid GISRC file that can be used in the initial stages.

To reproduce problems - 1) rm .grassrc6 (This why n00bs report
unreporoducable errors - daily grass users always have .grassrc6 with
valid locations/mapsets);
2) create new location with EPSG code 1234 - tmp location is left over;
3) repeat 1st step and now create new location from valid
georeferenced file - error.

Currently I'm not as good in coding to fix those problems

Just trying to make GRASS fool proof,

Really important. The startup is IMHO one of the most awkward, antiquated and bugprone parts of GRASS which I'm sure really puts people off!

Paul

[cmbarton]

On 12/13/06 4:10 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

now locations and mapsets are not sorted in alphabetical order.

I wonder what changed this? Need to look back at the code. Maris?

Also, if we are going to have EPSG codes as a standard way to create a
new location (and I think this is a handy way to go), can we
distribute a copy of the EPSG file inside the GRASS directory
structure (e.g., in the infamous catchall etc or another directory)?
The EPSG file is ending up in different places on different
architectures making it difficult to find. If it was always in the
same place, within the GRASS hierarchy, it would be easy to make this
the default location for the GUI.

not for, but not strongly against, however:
- The EPSG database and proj.4 are likely to be updated more often than
GRASS is.
- packagers should set --with-proj-share=, ./configure should give a
clear error message if not found for home-brew. Tcl then finds this dir
in the "PROJSHARE" variable.

Point well taken. Still, I'm slightly in favor of including this small file
with GRASS to make using what is now an essential tool easier. Even if PROJ
is updated regularly, this doesn't mean that GRASS users update their PROJ
installation. So it's likely out of sync in many cases anyway. This is a
simple text file that is easy to drop into GRASS. But of course, who should
be the one to do it so that it doesn't get way out of date.

Obviously the next thing to do is to make it searchable.

yes please, and auto-fill the highlighted value in the create dialogue.

I'm working on that now. I figured that it would be a chore and so had
avoided it. It turns out that I was right, but I'm making progress.

Michael

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

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

[mlennert]

On Wed, December 13, 2006 18:32, Michael Barton wrote:

Also, if we are going to have EPSG codes as a standard way to create a
new location (and I think this is a handy way to go), can we
distribute a copy of the EPSG file inside the GRASS directory
structure (e.g., in the infamous catchall etc or another directory)?
The EPSG file is ending up in different places on different
architectures making it difficult to find. If it was always in the
same place, within the GRASS hierarchy, it would be easy to make this
the default location for the GUI.

not for, but not strongly against, however:
- The EPSG database and proj.4 are likely to be updated more often than
GRASS is.
- packagers should set --with-proj-share=, ./configure should give a
clear error message if not found for home-brew. Tcl then finds this dir
in the "PROJSHARE" variable.

Point well taken. Still, I'm slightly in favor of including this small
file
with GRASS to make using what is now an essential tool easier. Even if
PROJ
is updated regularly, this doesn't mean that GRASS users update their PROJ
installation. So it's likely out of sync in many cases anyway. This is a
simple text file that is easy to drop into GRASS. But of course, who
should
be the one to do it so that it doesn't get way out of date.

I have never found it a problem that the user has to define the location
of the file if it is not in the default location. So I would rather keep
one version in proj than have to update both...

Moritz

[cmbarton]

On 12/13/06 4:46 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Hello Michael

On Tue, 12 Dec 2006, Michael Barton wrote:

I just committed a set of patches to the GRASS startup tcltk files
(gis_set.tcl, epsg_option.tcl, and file_option.tcl). These are designed to
make creating a new location from EPSG code or georeferenced file more
robust. This is especially important for Windows users who cannot make a new
location with g.proj.

BTW that is no longer true. g.setproj and etc/set_data work fine on
Windows (better if you have Msys in your path though - I'm working on
replacing a system("ls -C") call). If you click the "projection values"
button in gis_set.tcl it will pop up a Window running set_data so you can
create a location the traditional way. Current problem though is that the
list of locations doesn't refresh to show the new location after you
return from the box. I had a quick look a week or two ago but the design
of gis_set.tcl seemed to make it very difficult to refresh that. Although
if you click after the database directory and press Enter it refreshes.
Maybe you have improved something to make that easier though?

This is very good news. The design of gis_set.tcl is difficult overall,
because it is pretty old legacy code. I'm not sure there is an easy way to
do an automatic refresh after returning from the terminal window. If there
is some kind of return code, maybe it could be bound to an update event of
some kind.

I¹ve tested these on my Mac OSX with x11 GRASS cvs build of last Friday and
they seem to be fine. Please test on other platforms.

Also, if we are going to have EPSG codes as a standard way to create a new
location (and I think this is a handy way to go), can we distribute a copy
of the EPSG file inside the GRASS directory structure (e.g., in the infamous
catchall etc or another directory)? The EPSG file is ending up in different
places on different architectures making it difficult to find. If it was
always in the same place, within the GRASS hierarchy, it would be easy to
make this the default location for the GUI.

I tried to create a location with EPSG code but it just says "WARNING: The
epsg-codes file was not found!" and nothing appears to happen. Surely it
isn't necessary to have that file installed if you already know the code
you need?

I don't know how this work. I'll look into it as I'm currently working with
this file.

It isn't used for anything other than browsing and while
including it in GRASS is definitely preferable to having to look for it
wherever it was installed with PROJ, my preference would be to remove it
altogether and instead in some way generate the lists from the .csv files
in lib/proj that are actually used by g.proj to generate the location.

I think this is an excellent suggestion. Note, however, that these files are
not in the same place on all platforms. Hamish notes that this needs to be
set in configure at compile time. If we could do as you suggest, configure
should generate an error if the relevant proj directory is not found.

Not
sure how to do that but I think it's very confusing the way the file used
for browsing is different from and potentially out of sync with the file
used in the location generation.

Agreed

Or another option would be to use the PROJ.4 definitions in that file
directly and forget about the roundabout way it is currently done by
passing the EPSG code to g.proj as part of a PROJ-style projection
description? Whatever's done will probably need a bit of work though.

This is worth following up, especially for new versions. Could you explain a
bit more.

Michael

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

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

[cmbarton]

I AGREE!!!

Thanks to all of you for working to make this better. A ways to go, but
improving.

Michael

On 12/13/06 4:52 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Really important. The startup is IMHO one of the most awkward, antiquated
and bugprone parts of GRASS which I'm sure really puts people off!

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

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

[cmbarton]

On 12/13/06 4:30 AM, "Maris Nartiss" <maris.gis@gmail.com> wrote:

Creating new location from georeferenced file still will not work, as
it needs some (temporary) location to run g.proj. Probably
make_location_epsg.sh.in could be used to create new, similar script
for georeferenced file too. Or probaby some new script, that creates
valid temporary location and then cleans up for any module, that may
need temporary location for running (do we need such script?).

Maris,

Just to clarify

creating a location from a georeferenced file will NOT work if you don't
have a valid database and location in .grassrc6. But it WILL work if you do
have a valid database and location in .grassrc6.

Correct?

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

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

[marisn]

(en route form offlist conversation)
Hi,

Michael: As I understood, PROJSHARE is one of variable strings, that
gets replaced by exact value by make process. It's done with sed in
lib/init/Make file line 175. You can replace it by hand or run Make.

Unfortunately till weekend i will have no time to digg deeply in code,
but I THINK, that my changes in code SHOULD not affect location/mapset
ordering, as I only added crash preventing code.

About that georeferenced file problem - it's a "chicken and egg" type
problem. Currently to create new location from georeferenced file,
user needs valid location to run "g.proj -c georef=". If user has no
existing locations and only georeferenced file, user can't* create new
(first) location from that file, as he needs location to create
location from georeferenced file, what needs valid location to create
location from georeferenced file and so on in endless loop
I took short look in to "make_location_epsg.sh.in". It could be easely
converted to similar "make_location_georef.sh.it". But problem how to
notify user about failed process still remains (hint - there is some
code, that catches g.* error in gis.m mapcanvas.tcl).

* User still can create new (first) location in other ways - by EPSG
code or proj values.

IMHO for current code there is no use in including copy of proj epsg
file in GRASS. IF code is changed in such way, that allows search and
select in those epsg codes, then there could be some benefit from
keeping an fallback epsg code file inside GRASS (like, if
--with-proj-share-dir is not set, then use internal version).

Just my 0.02 cents,
Maris.

PS. I'm happy to see, that few lines of code can triger such HUGE
activity from others

[mlennert]

On Wed, December 13, 2006 18:40, Michael Barton wrote:

Current problem though is that
the
list of locations doesn't refresh to show the new location after you
return from the box. I had a quick look a week or two ago but the design
of gis_set.tcl seemed to make it very difficult to refresh that.
Although
if you click after the database directory and press Enter it refreshes.
Maybe you have improved something to make that easier though?

This is very good news. The design of gis_set.tcl is difficult overall,
because it is pretty old legacy code. I'm not sure there is an easy way to
do an automatic refresh after returning from the terminal window. If there
is some kind of return code, maybe it could be bound to an update event of
some kind.

I don't have the possibility of testing this now (since in the Linux
version all options close or enter GRASS automatically), but I seem to
remember that in the very first experimental native wingrass it was enough
to just put the mouse cursor in the GRASS database text field and press
enter and this would refresh the list of locations.

Moritz

[Helena_Mitasova]

Just a note regarding my experiences with testing various startup options
with the new data set.
It worked from the existing file smoothly, EPSG code did not work - but I think
that the recently submitted fixes from Maris should have fixed the problem (I will
update and test). The third option, leading to the old, text based interface
did not work for sp and ll but that was fixed too.

But the main reason I am writing is that when working with locations created
from the file or EPSG, the region is set to default 1,1,1 (as opposed to the
"old way" when you are required to set the default region for the new location).
This is OK if you are experienced user and you know that you have
to import something with option to expand the region to this file or to define
a meaningful "starting region" using g.region, but it may be confusing for new users.
And what I found very inconvenient was the fact already mentioned some time ago,
that you are stuck with 1,1,1 default region unless you edit the file manually
as there is no tool to modify the default region. Normally I don't use the default
region, but in this case I was using many different regions as I was importing
different types of data and it would have been nice to have a region to get back to.

Maybe just modifying the message that you get when creating the region
from file or EPSG that you need to "restart grass and define your region using
g.region" would be helpful. Of course, automatically importing the file and setting
region to its extent would be the best solution for the "new location from file"
option, becuase then the user has a new location and can display the
map right away.

It is great to see this long neglected part of GRASS moving forward

Helena

On Dec 13, 2006, at 3:45 PM, Maris Nartiss wrote:

(en route form offlist conversation)
Hi,

Michael: As I understood, PROJSHARE is one of variable strings, that
gets replaced by exact value by make process. It's done with sed in
lib/init/Make file line 175. You can replace it by hand or run Make.

Unfortunately till weekend i will have no time to digg deeply in code,
but I THINK, that my changes in code SHOULD not affect location/mapset
ordering, as I only added crash preventing code.

About that georeferenced file problem - it's a "chicken and egg" type
problem. Currently to create new location from georeferenced file,
user needs valid location to run "g.proj -c georef=". If user has no
existing locations and only georeferenced file, user can't* create new
(first) location from that file, as he needs location to create
location from georeferenced file, what needs valid location to create
location from georeferenced file and so on in endless loop
I took short look in to "make_location_epsg.sh.in". It could be easely
converted to similar "make_location_georef.sh.it". But problem how to
notify user about failed process still remains (hint - there is some
code, that catches g.* error in gis.m mapcanvas.tcl).

* User still can create new (first) location in other ways - by EPSG
code or proj values.

IMHO for current code there is no use in including copy of proj epsg
file in GRASS. IF code is changed in such way, that allows search and
select in those epsg codes, then there could be some benefit from
keeping an fallback epsg code file inside GRASS (like, if
--with-proj-share-dir is not set, then use internal version).

Just my 0.02 cents,
Maris.

PS. I'm happy to see, that few lines of code can triger such HUGE
activity from others

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

[cmbarton]

The issue is that the default location is different on different systems.
For example, I found my epsg file in

/Library/Frameworks/PROJ.framework/Resources/proj

I have no idea where it lives on Windows, but I'll bet it's not in
/usr/local/share/proj

Michael

On 12/13/06 3:47 PM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

I don't have the possibility of testing this now (since in the Linux
version all options close or enter GRASS automatically), but I seem to
remember that in the very first experimental native wingrass it was enough
to just put the mouse cursor in the GRASS database text field and press
enter and this would refresh the list of locations.

Moritz

__________________________________________
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

[H_B]

Michael Barton wrote:

The issue is that the default location is different on different
systems. For example, I found my epsg file in

/Library/Frameworks/PROJ.framework/Resources/proj

I have no idea where it lives on Windows, but I'll bet it's not in
/usr/local/share/proj

so if you were the Mac packager, you would build your binary with
./configure --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj
and then it would work for all the people who used your grass +
frameworks packages.

Same goes for the Windows binary packager, or linux, or...

if you build from source, it's up to you to tell ./configure where it
lives. If you are using a binary package it's a controlled environment.

Hamish

[H_B]

Michael Barton wrote:

>
> now locations and mapsets are not sorted in alphabetical order.
>
>

I wonder what changed this? Need to look back at the code.

maybe this?

CVS log for grass6/lib/init/gis_set.tcl

Revision 1.41 / (as text) / (view) - annotate - [select for diffs] , Wed Dec 6 00:01:53 2006 UTC (8 days, 6 hours ago) by michael
Branch: MAIN
Changes since 1.40: +18 -26 lines
Replace exec ls with pure TclTk (glob, etc) for Windows compatibility.

Perhaps glob gives raw order?

Hamish

[cmbarton]

You are probably correct.

Michael

On 12/13/06 11:29 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Michael Barton wrote:

now locations and mapsets are not sorted in alphabetical order.

I wonder what changed this? Need to look back at the code.

maybe this?

CVS log for grass6/lib/init/gis_set.tcl

Revision 1.41 / (as text) / (view) - annotate - [select for diffs] , Wed Dec 6
00:01:53 2006 UTC (8 days, 6 hours ago) by michael
Branch: MAIN
Changes since 1.40: +18 -26 lines
Replace exec ls with pure TclTk (glob, etc) for Windows compatibility.

Perhaps glob gives raw order?

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

[Glynn_Clements1]

Hamish wrote:

> > now locations and mapsets are not sorted in alphabetical order.
> >
> >
>
> I wonder what changed this? Need to look back at the code.

maybe this?

CVS log for grass6/lib/init/gis_set.tcl

Revision 1.41 / (as text) / (view) - annotate - [select for diffs] , Wed Dec 6 00:01:53 2006 UTC (8 days, 6 hours ago) by michael
Branch: MAIN
Changes since 1.40: +18 -26 lines
Replace exec ls with pure TclTk (glob, etc) for Windows compatibility.

Perhaps glob gives raw order?

According to the glob(n) manpage:

       The glob command differs from csh globbing in two ways. First, it does
       not sort its result list (use the lsort command if you want the list
       sorted). [snip]

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

[Markus_Neteler1]

Hamish wrote on 12/13/2006 12:10 PM:

Michael Barton wrote:
  

Also, if we are going to have EPSG codes as a standard way to create a
new location (and I think this is a handy way to go), can we
distribute a copy of the EPSG file inside the GRASS directory
structure (e.g., in the infamous catchall etc or another directory)?
The EPSG file is ending up in different places on different
architectures making it difficult to find. If it was always in the
same place, within the GRASS hierarchy, it would be easy to make this
the default location for the GUI.
    
not for, but not strongly against, however:
- The EPSG database and proj.4 are likely to be updated more often than
GRASS is.
  
While I am also against it, I always keep GRASS PROJ stuff in sync with
GDAL (csv files).
GDAL follows which follows PROJ (same time) which follows EPSG.

Markus