[GRASS-user] grass prompt default working directory

GRASS GRASS user
1

Hello list,
when launching grass64, the working directory of the process (I mean the
grass prompt in the terminal window) is located at user's home (e.g pwd
command returns: /home/vincent). I did not find if this path was stored
in a Grass environment variable ? is it possible to change the default
path ?

The point is I often need to cd to the current mapset directory, it
could be convenient to have the ability to set this default path at
grass startup in a given location/mapset.

Has anyone any advice/idea for this ?
Thanks,
Vincent

2

More about my previous post, as a kind of self-answer:

I understand grass64 launched from a terminal shell is a child process
which inherits from the shell's working directory.

Sometimes paths are quite annoying to type (even with the help of
autocompletion, I'm lazy!).

For the time being I wrote a little script, located in my home directory
(~/g.cd). It evals GISDBASE, LOCATION_NAME, GISMAPSET with g.gisenv,
then changes directory to the current mapset. In order to take into
account the cd command in the parent process, I source the script from
grass prompt :
. g.cd

It's quite straight.
Any better/cleaner solution is welcome,

Vincent

Le mardi 26 février 2013 à 14:13 +0100, Vincent Bain a écrit :

Hello list,
when launching grass64, the working directory of the process (I mean the
grass prompt in the terminal window) is located at user's home (e.g pwd
command returns: /home/vincent). I did not find if this path was stored
in a Grass environment variable ? is it possible to change the default
path ?

The point is I often need to cd to the current mapset directory, it
could be convenient to have the ability to set this default path at
grass startup in a given location/mapset.

Has anyone any advice/idea for this ?
Thanks,
Vincent

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

3

On Tuesday 26 of February 2013 14:13:02 Vincent Bain wrote:

Hello list,

Hi Vincent.

when launching grass64, the working directory of the process (I mean the
grass prompt in the terminal window) is located at user's home (e.g pwd
command returns: /home/vincent). I did not find if this path was stored
in a Grass environment variable ?

You work in a linux-box, right? I think the GRASS-working-directory (if I can
name it like that as per the pwd command) it just remains there from where you
actually launching grass.

Try launching from a different directory.

is it possible to change the default path ?

I think there is no GRASS_HOME variable! Not sure however -- maybe check here:
<http://grass.osgeo.org/grass64/manuals/variables.html&gt;\.

The point is I often need to cd to the current mapset directory, it
could be convenient to have the ability to set this default path at
grass startup in a given location/mapset.

Me too!

Has anyone any advice/idea for this ?

It sounds easy to do!? Something like using GRASS' existing environment
variables GISDBASE, LOCATION_NAME, MAPSET and instructing inside the GRASS
initialization (Python) script to navigate to this directory?

Don't know if this breaks anything...
Sorry, no time to test myself.

Best, Nikos

4

Thank you Nikos for your reply,

I let you read my previous message as an answer.
The thing is I mostly run grass in text mode.

Yours,
Vincent

Le mardi 26 février 2013 à 15:29 +0200, Nikos Alexandris a écrit :

On Tuesday 26 of February 2013 14:13:02 Vincent Bain wrote:
> Hello list,

Hi Vincent.

> when launching grass64, the working directory of the process (I mean the
> grass prompt in the terminal window) is located at user's home (e.g pwd
> command returns: /home/vincent). I did not find if this path was stored
> in a Grass environment variable ?

You work in a linux-box, right? I think the GRASS-working-directory (if I can
name it like that as per the pwd command) it just remains there from where you
actually launching grass.

Try launching from a different directory.

> is it possible to change the default path ?

I think there is no GRASS_HOME variable! Not sure however -- maybe check here:
<http://grass.osgeo.org/grass64/manuals/variables.html&gt;\.

> The point is I often need to cd to the current mapset directory, it
> could be convenient to have the ability to set this default path at
> grass startup in a given location/mapset.

Me too!

> Has anyone any advice/idea for this ?

It sounds easy to do!? Something like using GRASS' existing environment
variables GISDBASE, LOCATION_NAME, MAPSET and instructing inside the GRASS
initialization (Python) script to navigate to this directory?

Don't know if this breaks anything...
Sorry, no time to test myself.

Best, Nikos

5

On 26/02/13 14:26, Vincent Bain wrote:

More about my previous post, as a kind of self-answer:

I understand grass64 launched from a terminal shell is a child process
which inherits from the shell's working directory.

Sometimes paths are quite annoying to type (even with the help of
autocompletion, I'm lazy!).

For the time being I wrote a little script, located in my home directory
(~/g.cd). It evals GISDBASE, LOCATION_NAME, GISMAPSET with g.gisenv,
then changes directory to the current mapset.

I would not recommend using the GISDBASE as your working directoy. My general advice: let GRASS handle everything in there and create your own files elsewhere.

Moritz

6

Vincent:

Thank you Nikos for your reply,

I let you read my previous message as an answer.

I guess I was writing while it hit my inbox! :-p

The thing is I mostly run grass in text mode.

Me too -- and I truly understand your need(s), I think. For your interest, you
might want to read the threads

"Bash aliases in GRASS" and "Simple bash auto-completion for GRASS" in grass-
dev's ML.

Thanks, Nikos

7

Vincent Bain wrote:

> More about my previous post, as a kind of self-answer:

> I understand grass64 launched from a terminal shell is a child process
> which inherits from the shell's working directory.

> Sometimes paths are quite annoying to type (even with the help of
> autocompletion, I'm lazy!).

> For the time being I wrote a little script, located in my home directory
> (~/g.cd). It evals GISDBASE, LOCATION_NAME, GISMAPSET with g.gisenv,
> then changes directory to the current mapset.

Moritz:

I would not recommend using the GISDBASE as your working directoy. My
general advice: let GRASS handle everything in there and create your own
files elsewhere.

Moritz,

if I understand Vincent's need(s), and if they coincide with mine, I think
it's about checking map names, colr rules, maybe check the subgroups which is
not easy via the "g.list type=group" nor the "i.group group=yourGroup -l"
commands, etc.

It is not about manipulating files in the GRASS db. Imagine, that I just want
to

d.rast some map among the

cm_fmap_2006_ellas
cm_fmap_2006_ellas_forested_areas
cm_fmap_2006_tile_51
cm_fmap_2006_tile_52
cm_ftype_2006_tile_51
cm_ftype_2006_tile_52

(here only a few -- imagine hundreds). Why do I need to g.list first, mark-
copy-paste (via the middle mouse-button or Ctrl + Shift + C and +V
respectively in the keyboard)? I simply want quick access and the awesome
autocompletion feature to all of my map(name)s and don't need to re-type the
complete name. Luckily, the history functions of bash are very handy (e.g.
Ctrl + R and more).

I simply navigate inside the respective CELL or FCELL or DCELL or cell_misc
directory sometimes...

Just my old 2 drachmas, Nikos

8

I would not recommend using the GISDBASE as your working directoy. My
general advice: let GRASS handle everything in there and create your own
files elsewhere.

Hello Moritz,

two reasons I use to cd to mapset directory :
- general - that described by Nikos, like browsing data via bash
commands;
- particular - the wish to keep a mapset-specific directory I usually
call "ps"; it contains settings files for my recursive ps.map runs,
refering each to a saved region. To my mind this kind of data is
strongly linked to the geodatabase structure, particularly in long-term
cartographic projects.

Another point is that working on a bunch of gisdbases, I am trying to
avoid data scattering, for archiving convenience mainly. But files are
mainly stored at the gisdbase level.

Concerning my first issue: the home-made g.cd script suits me well.

Thank you both for your points of view !
Vincent.

9

On 26 February 2013 15:29, Vincent Bain <bain@toraval.fr> wrote:

I would not recommend using the GISDBASE as your working directoy. My
general advice: let GRASS handle everything in there and create your own
files elsewhere.

Hello Moritz,

two reasons I use to cd to mapset directory :
- general - that described by Nikos, like browsing data via bash
commands;
- particular - the wish to keep a mapset-specific directory I usually
call "ps"; it contains settings files for my recursive ps.map runs,
refering each to a saved region. To my mind this kind of data is
strongly linked to the geodatabase structure, particularly in long-term
cartographic projects.

Another point is that working on a bunch of gisdbases, I am trying to
avoid data scattering, for archiving convenience mainly. But files are
mainly stored at the gisdbase level.

Concerning my first issue: the home-made g.cd script suits me well.

Thank you both for your points of view !
Vincent.

Hi, you all made some interesting points. Please consider creating
wiki page on this topic. Something like "Using GRASS from shell
effectively" or "Ps.map files management/workflow" could be
interesting not only for newbies to understand why cmd like is good
but also for advanced users. I guess there is no such wiki page.

Vaclav

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

10

Le mardi 26 février 2013 à 16:49 +0100, Vaclav Petras a écrit :

Hi, you all made some interesting points. Please consider creating
wiki page on this topic. Something like "Using GRASS from shell
effectively" or "Ps.map files management/workflow" could be
interesting not only for newbies to understand why cmd like is good
but also for advanced users. I guess there is no such wiki page.

Vaclav,

writing a few lines on the wiki about ps.map workflow solutions is on my
todo list (to the truth, it's been for quite a long time...)

Scripting ps.map in combination with other command-line tools (convert,
ps2pdf, latex/pstricks, pure postscript instructions, etc.) opens a wide
variety of methods to design accurate, sophisticated and efficient
production flows (OK, everyone here knows it... sorry ;-))

I'll try to spend some time on it soon.
Vincent.

11

Hi,

a couple of points,

firstly, you can add this to ~/.grass.bashrc:

g.cd()
{
  MAPSET=`g.gisenv get=MAPSET`
  LOCATION_NAME=`g.gisenv get=LOCATION_NAME`
  GISDBASE=`g.gisenv get=GISDBASE`
  LOCATION="$GISDBASE/$LOCATION_NAME/$MAPSET"
  cd "$LOCATION"
}

(as I just did, nice idea, thanks!)

these used to be enviro vars in earlier versions of GRASS, but
were changed to g.gisenv enviro vars as changing context needs
to happen for the whole GIS. Once the GUI is launched, any changes
to enviro vars in either it or the command prompt only propogate
to children of each, not to siblings or past-spawned children
processes. So the command prompt and GUI would get out of sync
wrt which mapset or location you are in and it would be a big
mess.

Note that the mapset dir is (in a way) set to be the home dir
in a soft way, so that .bash_history for the grass command
session is written to the mapset dir, not real $HOME. Using
that, the above g.cd could be simplifiled to:

  alias g.home='cd `dirname "$HISTFILE"`'

Hamish

12

Nikos wrote:

if I understand Vincent's need(s), and if they coincide with
mine, I think it's about checking map names, colr rules, maybe
check the subgroups which is not easy via the "g.list
type=group" nor the "i.group group=yourGroup -l"
commands, etc.

fwiw, g.findfile might be useful for that (mostly for use by
scripts).

It is not about manipulating files in the GRASS db.
Imagine, that I just want to

d.rast some map among the

cm_fmap_2006_ellas
cm_fmap_2006_ellas_forested_areas
cm_fmap_2006_tile_51
cm_fmap_2006_tile_52
cm_ftype_2006_tile_51
cm_ftype_2006_tile_52

(here only a few -- imagine hundreds). Why do I need
to g.list first, mark-copy-paste (via the middle mouse-button
or Ctrl + Shift + C and +V respectively in the keyboard)?

g.mlist? :slight_smile:

I simply want quick access and the awesome autocompletion
feature to all of my map(name)s and don't need to re-type the
complete name. Luckily, the history functions of bash
are very handy (e.g. Ctrl + R and more).

re. "and more", fwiw, I find adding this to ~/.inputrc is much
nicer to use than ^r,

# -------- Bind page up/down wih history search ---------
"\e[5~": history-search-backward
"\e[6~": history-search-forward

type the first few letters, then PgUp to see earlier matches..

hoping the recent work on command line completion continues, :slight_smile:
Hamish

13

Hamish wrote:

firstly, you can add this to ~/.grass.bashrc:

g.cd()
{
MAPSET=`g.gisenv get=MAPSET`
LOCATION_NAME=`g.gisenv get=LOCATION_NAME`
GISDBASE=`g.gisenv get=GISDBASE`
LOCATION="$GISDBASE/$LOCATION_NAME/$MAPSET"
cd "$LOCATION"
}

(as I just did, nice idea, thanks!)

here is a slight modification so you can also do "g.cd colr/",
or even "g.cd .." to get to the LOCATION's dir:

g.cd()
{
  MAPSET=`g.gisenv get=MAPSET`
  LOCATION_NAME=`g.gisenv get=LOCATION_NAME`
  GISDBASE=`g.gisenv get=GISDBASE`
  LOCATION="$GISDBASE/$LOCATION_NAME/$MAPSET"
  cd "$LOCATION/$1"
}

Hamish

14

Hi,

2013/2/26 Hamish <hamish_b@yahoo.com>:

Hamish wrote:

firstly, you can add this to ~/.grass.bashrc:

g.cd()
{
  MAPSET=`g.gisenv get=MAPSET`
  LOCATION_NAME=`g.gisenv get=LOCATION_NAME`
  GISDBASE=`g.gisenv get=GISDBASE`
  LOCATION="$GISDBASE/$LOCATION_NAME/$MAPSET"
  cd "$LOCATION"
}

cool, as Vaclav noted please add such useful notes on the wiki.
Otherwise it will be lost in ML jungle.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

15

Nikos wrote:

> if I understand Vincent's need(s), and if they coincide with
> mine, I think it's about checking map names, colr rules, maybe
> check the subgroups which is not easy via the "g.list
> type=group" nor the "i.group group=yourGroup -l"
> commands, etc.

Hamish:

fwiw, g.findfile might be useful for that (mostly for use by
scripts).

That to be honest, I use(d) that rarely.

..

> (here only a few -- imagine hundreds). Why do I need
> to g.list first, mark-copy-paste (via the middle mouse-button
> or Ctrl + Shift + C and +V respectively in the keyboard)?

g.mlist? :slight_smile:

Yes, very frequently, every day actually. In one-liners and scripts -- can't
live without it.

..

Luckily, the history functions of bash are very handy (e.g. Ctrl + R and
more).

re. "and more", fwiw, I find adding this to ~/.inputrc is much
nicer to use than ^r,

So cool!! -- ...hey, that's not fair :-/

Will test it for some time to see if it fits to my habits :-p

# -------- Bind page up/down wih history search ---------
"\e[5~": history-search-backward
"\e[6~": history-search-forward

type the first few letters, then PgUp to see earlier matches..

I guess this replicates the continuous "Ctrl + R" functionality.

hoping the recent work on command line completion continues, :slight_smile:

Happy cli user here :-). Recent additions in the wxGUI are, however, very
nice and necessary.

Thanks, Nikos

16

Martin wrote:

cool, as Vaclav noted please add such useful notes on the wiki.

done @ http://grasswiki.osgeo.org/wiki/GRASS_and_Shell

Otherwise it will be lost in ML jungle.

"the distributed backup method" :wink:

Hamish

17

Le mardi 26 février 2013 à 12:30 -0800, Hamish a écrit :

re. "and more", fwiw, I find adding this to ~/.inputrc is much
nicer to use than ^r,

# -------- Bind page up/down wih history search ---------
"\e[5~": history-search-backward
"\e[6~": history-search-forward

type the first few letters, then PgUp to see earlier matches..

So nice !
Thx a lot Hamish,

Vincent

18

Nikos, I have some related wiki-notes.

1) Maybe, it is not an easy task but I would prefer to have two pages,
one for "Writing Shell scripts" and one for "Using GRASS from Shell".
Now both is mixed in "GRASS and Shell" which, however, can be still
there to contain common things. What do you think?

2) Probably, we need a template "Main article: XXX". ...considering
the article "Working with GRASS without starting it explicitly" which
should be referenced also from "GRASS and Shell". (I added the link in
semi-wikipedia style, so you can see, if you like the style. The usage
of template on Wikipedia looks like this "{{main|Anonymous
function#C++}}".)

http://grasswiki.osgeo.org/wiki/GRASS_and_Shell#Automated_batch_jobs:_Setting_the_GRASS_environmental_variables

Vaclav

On 27 February 2013 08:20, Vincent Bain <bain@toraval.fr> wrote:

Le mardi 26 février 2013 à 12:30 -0800, Hamish a écrit :

re. "and more", fwiw, I find adding this to ~/.inputrc is much
nicer to use than ^r,

# -------- Bind page up/down wih history search ---------
"\e[5~": history-search-backward
"\e[6~": history-search-forward

type the first few letters, then PgUp to see earlier matches..

So nice !
Thx a lot Hamish,

Vincent

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

19

Vaclav Petras wrote:

Nikos, I have some related wiki-notes.

Thanks ;-). Will try to take care of that next week. I wonder if we need
just another wikipage to keep notes of stuff that are wanted in the wiki?!

- Special pages are useful for maintenance
- extra User-scratched page will notes on stuff to be added?

1) Maybe, it is not an easy task but I would prefer to have two pages,
one for "Writing Shell scripts" and one for "Using GRASS from Shell".
Now both is mixed in "GRASS and Shell" which, however, can be still
there to contain common things. What do you think?

Fully agree.

2) Probably, we need a template "Main article: XXX". ...considering
the article "Working with GRASS without starting it explicitly" which
should be referenced also from "GRASS and Shell". (I added the link in
semi-wikipedia style, so you can see, if you like the style. The usage
of template on Wikipedia looks like this "{{main|Anonymous
function#C++}}".)

http://grasswiki.osgeo.org/wiki/GRASS_and_Shell#Automated_batch_jobs:_Settin
g_the_GRASS_environmental_variables

Cool! I like it -- it'll make things easier.

BTW -- are you folks interested in having a template to display "keys" and
"key combinations" (something like, or exactly the "key press" template in
Wikipedia)?

It will help (me and hopefully all) a lot.

Best, Nikos

20

Vaclav Petras wrote:

..

> 2) Probably, we need a template "Main article: XXX". ...considering
> the article "Working with GRASS without starting it explicitly" which
> should be referenced also from "GRASS and Shell". (I added the link in
> semi-wikipedia style, so you can see, if you like the style. The usage
> of template on Wikipedia looks like this "{{main|Anonymous
> function#C++}}".)

> http://grasswiki.osgeo.org/wiki/GRASS_and_Shell#Automated_batch_jobs:_Sett
> in g_the_GRASS_environmental_variables

And, maybe it's not that easy, but what do you think of a bi-directional
behaviour?

The template, not only should add a reference to the main article/page, it
should also add automatically a link in the main page itself, something alike
a mini Table of sub-articles? This might mix things with the "See also" user-
scratched sections!

What do you think? Possible? Will re-search next-week.

Of course, there is the "What links here" function (standard menu on the
left). Maybe just stay on this and use it, and simply try to make it more
obvious -- it's something that does not catch my eye!

Thanks, Nikos