[GRASS-user] SHELL variable not set

GRASS GRASS user
1

Hello,

unfortunately I added 'rm .* ' instead of a 'rm $variable.*' in a GRASS
script, hence I had to setup a new user account but when starting grass63 as
the new user I get:

sh-3.1$ grass63
Cleaning up temporary files.....
Starting GRASS ...
GISDBASE='/data1/grassdb_africa';
LOCATION_NAME='HI';
MAPSET='nlm';
ERROR: The SHELL variable is not set

I never encountered it when installing Linux/GRASS for the first time, I
searched a bit and found some GRASS shell scripts with this error message but
I couldn't find a hint how to fix that.

Is is a GRASS or Linux specific problem? Any idea which SHELL variable I have
to set? And how to do so?

Martin

P.S.:using 6.3 cvs access hence pretty "old" and Debian testing GRASS version

2

Hello Martin and all,

Martin Wegmann escribió:

Is is a GRASS or Linux specific problem? Any idea which SHELL variable I have to set? And how to do so?

I'm not sure, but I think you have to set just the SHELL variable. Try to check in this way: 'echo $SHELL'. If you get nothing then you can set it to '/bin/bash' in the terminal you are using. If you want to set it permanently, try this: chsh -s /bin/bash. You can use BASH or whatever other shell you like.

I hope this helps,
Roberto.

--
Roberto Antolín Sánchez
Politecnico di Milano - Polo Regionale di Como
(Laboratorio di Geomatica V2.8)
Via Valleggio, 11 - 22100 Como, Italy
tel: +39 031 332 7533 || fax: +39 031 332 7519
roberto.antolin@polimi.it

3

On Jan 28, 2008 6:15 PM, Martin Wegmann
<wegmann@biozentrum.uni-wuerzburg.de> wrote:

Hello,

unfortunately I added 'rm .* ' instead of a 'rm $variable.*' in a GRASS
script, hence I had to setup a new user account but when starting grass63 as
the new user I get:

sh-3.1$ grass63
Cleaning up temporary files.....
Starting GRASS ...
GISDBASE='/data1/grassdb_africa';
LOCATION_NAME='HI';
MAPSET='nlm';
ERROR: The SHELL variable is not set

I never encountered it when installing Linux/GRASS for the first time, I
searched a bit and found some GRASS shell scripts with this error message but
I couldn't find a hint how to fix that.

Is is a GRASS or Linux specific problem? Any idea which SHELL variable I have
to set? And how to do so?

I am afraid that this is a local problem:

The relevant bit is in the start script:
# check for SHELL
if [ ! -x "$SHELL" ] ; then
    echo "ERROR: The SHELL variable is not set" 1>&2
    rm -f "$lockfile"
    rm -rf "$tmp" # remove session files from tmpdir
    exit 1
fi

The $SHELL variable is set when you login: example:

[neteler@localhost ~]$ echo $SHELL
/bin/bash

IMHO something is still messed up with your user account.

Markus

4

Am Montag, 28. Januar 2008 19:17:12 schrieb Roberto Antolin:

Hello Martin and all,

Martin Wegmann escribió:
> Is is a GRASS or Linux specific problem? Any idea which SHELL variable I
> have to set? And how to do so?

I'm not sure, but I think you have to set just the SHELL variable. Try
to check in this way: 'echo $SHELL'. If you get nothing then you can set
it to '/bin/bash' in the terminal you are using. If you want to set it
permanently, try this: chsh -s /bin/bash. You can use BASH or whatever
other shell you like.

thanks, that did it. No idea why this wasn't set.

now echo $SHELL gives me /bin/bash

Martin

5

Martin Wegmann wrote:

unfortunately I added 'rm .* ' instead of a 'rm $variable.*' in a GRASS
script, hence I had to setup a new user account but when starting grass63 as
the new user I get:

sh-3.1$ grass63
Cleaning up temporary files.....
Starting GRASS ...
GISDBASE='/data1/grassdb_africa';
LOCATION_NAME='HI';
MAPSET='nlm';
ERROR: The SHELL variable is not set

I never encountered it when installing Linux/GRASS for the first time, I
searched a bit and found some GRASS shell scripts with this error message but
I couldn't find a hint how to fix that.

Is is a GRASS or Linux specific problem? Any idea which SHELL variable I have
to set? And how to do so?

SHELL should be set from the last field in the user's /etc/passwd
entry[1] by any program which creates a session, e.g. login for
console logins, xdm/gdm/kdm for X sessions, sshd for ssh logins, etc.

[1] To be precise, the value of the pw_shell field in the "passwd",
structure returned by getpwnam() or getpwuid(). Some systems use e.g.
NIS or LDAP for storing user accounts instead of /etc/passwd.

The standard way for a user to change their shell is with the "chsh"
command.

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

6

Martin Wegmann wrote:

unfortunately I added 'rm .* ' instead of a 'rm $variable.*' in a
GRASS script, hence I had to setup a new user account

just to highlight the trap, as I've fallen into it too:

if $variable is unset for some reason, 'rm "$variable".*' becomes
'rm "".*' which is processed by the shell as 'rm .*'

lesson: be very careful with rm, try to anticiapte failure modes, and
set up that rsync cron job to backup your home directory.

Hamish

      ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

7

On Jan 29, 2008 11:42 AM, Hamish <hamish_b@yahoo.com> wrote:

Martin Wegmann wrote:
> unfortunately I added 'rm .* ' instead of a 'rm $variable.*' in a
> GRASS script, hence I had to setup a new user account

just to highlight the trap, as I've fallen into it too:

if $variable is unset for some reason, 'rm "$variable".*' becomes
'rm "".*' which is processed by the shell as 'rm .*'

lesson: be very careful with rm, try to anticiapte failure modes, and
set up that rsync cron job to backup your home directory.

... and maybe do $variable testing in the script, e.g.

if [ -z "$variable" ] ; then
    echo "variable not set"
else
    rm -f "$variable".*
fi

Markus