[GRASS-dev] Re: [GRASS GIS] #132: Extend GRASS-command history (at least to 1000) by default

Glynn Clements glynn at gclements.plus.com
Tue May 20 13:20:01 EDT 2008


GRASS GIS wrote:

> #132: Extend GRASS-command history (at least to 1000) by default
> --------------------------+-------------------------------------------------
>   Reporter:  nikos        |       Owner:  grass-dev at lists.osgeo.org
>       Type:  enhancement  |      Status:  new                      
>   Priority:  major        |   Milestone:  6.4.0                    
>  Component:  default      |     Version:  unspecified              
> Resolution:               |    Keywords:                           
> --------------------------+-------------------------------------------------
> Comment (by epatton):
> 
>  Using fresh svn update from today, I get a $HISTFILE size of 5000...but
>  HISTSIZE gets exported to 3000 in Init.sh:
> 
>  {{{
>  888:    echo "set history = 3000 savehist = 3000  noclobber ignoreeof" >> "$cshrc"
>  889:    echo "set histfile = $HOME/.history" >> "$cshrc"
>  927:    # save command history in mapset dir and remember more
>  928:    export HISTFILE="$LOCATION/.bash_history"
>  929:    if [ -z "$HISTSIZE" ] && [ -z "$HISTFILESIZE" ] ; then
>  930:    export HISTSIZE=3000
>  }}}
> 
>  But I can't remember if this difference is due to some change I made
>  elsewhere on my system.

The code doesn't touch HISTSIZE if either HISTSIZE or HISTFILESIZE are
already set.

It's quite possible that one of those is being set in one of the
(many) shell startup scripts, i.e. /etc/profile, ~/.bash_profile,
~/.bash_login, ~/.profile, ~/.bashrc, or any script which is sourced
from one of those.

Many systems have a whole directory (e.g. /etc/profile.d or
/etc/env.d) of scripts which are sourced from /etc/profile, in order
to allow individual packages to customise the environment.

In addition, programs which are involved in initialising X sessions
(e.g. xdm/gdm/kdm, Gnome/KDE, the window manager, etc) may set
environment variables which will then be inherited by any shells.

Finally, any "login" program (e.g. xdm/gdm/kdm) normally uses PAM,
which may set environment variables via the pam_env module.

All in all, determining how an environment variable gets set can
sometimes require exhaustive knowledge of your process' ancestors and
their behaviour.

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


More information about the grass-dev mailing list