Hi Justin, Hi Malcolm,
i tested the adding of
#!/bin/sh to etc/Init.sh
and it _partially_ works now.
There are some really mysterious things happening on CYGWIN, i'll give a
rundown of them in the hope that someone helps me to get this running as
it is expected.
- there is no clear bin. But "tput clear" works. This works for me on
Linux, IRIX and CYGWIN, so IMHO it can be changed.
- on CYGWIN $SHELL is always "/bin/sh", even if running in bash. This is
the reason grass5 starts always with sh. If i do a "export SHELL=`which
bash`" before starting grass5, it does not work, as SHELL is set to
"D:/cygwin/bin/bash.exe", so that `basename $SHELL` is bash.exe.
If i add bash|bash.exe) in the shell check in Init.sh, everything starts
up as expected, but $ETC/run $SHELL gets into a dead loop. If i Ctrl-C,
i am in a grass session (but PS1 and others are not correctly set), if i
wait, the PATH-variable is expanded until the resource is exhausted and
i get a "fork: resource not available". I can manually start $ETC/run
$SHELL with SHELL=/bin/bash or SHELL=D:/cygwin/bin/bash.exe.
I am totally clueless whats happening here. I tested many combinations.
Only the /bin/sh setup works.
PATH is set to something like this (only snippet):
/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local...
I just want a grass session running through the bash shell, as working
without command completion and command history is a pain. I fear that
simply copying bash.exe to sh.exe will break something else on the
CYGWIN system.
What i noted too: If i delete .grassrc, .gislock (after killing the dead
loop this is left behind) and the .bashrc etc. in the mapset i work in
and re-start grass5, i get not the message that no X window system is
running. This is only shown sometimes when starting up the session
again. Very strange. Is this stored somewhere else than in the .grassrc
file?
g.manual does not work on CYGWIN:
g.manual d.erase
fgets: error 0
Error reading manual page
No entry ...
cu,
Andreas
Justin Hickey wrote:
Hi Andreas and Malcolm
Andreas Lange wrote:
>
> Malcolm Blue wrote:
> > > Does this mean that CYGWIN does not have a sh program but a bash
> > > one instead? Should we put "if CYGWIN copy /bin/bash.exe to
> > > /bin/sh.exe" code in the Makefile or somewhere? Just an idea.
> >
> > It might be better to test which shell is being used and tell the
> > user that Init.sh (and grass5) won't run with the ash shell - which
> > I think is what is used for the default sh.exe program in the cygwin
> > setup. This information should also be added to the INSTALL file and
> > to the Cygwin instructions. A lot of people prefer the borne shell
> > anyway. Since other shells may be available (csh, ksh, etc.) now or
> > in the future it is probably best to avoid making changes to a users
> > setup.
> >
Hmmm. It appears that you may have misunderstood me. The fault is mine,
I was pretty vague with that post so I'll try to be more clear. At first
I thought the error message Andreas posted meant that CYGWIN could not
find the file Init.sh. After your reply, it reminded me that the error
message could be complaining about not finding the correct shell script
interpreter. Since you copied bash.exe.to sh.exe, I thought that CYGWIN
did not provide the sh interpreter which is required by our shell
scripts.
The way it is supposed to work is that programmers are supposed to write
their shell scripts as sh scripts since sh is supposed to be installed
in every version of UNIX. The sh interpreter is specified in the script
and thus, the script is portable. Therefore, it shouldn't matter which
shell people use, since the script is always supposed to use the sh
interpreter regardless of the shell it is called from.
So, the user should not have to change his/her setup, and the problem is
either in the script or with the CYGWIN installation. But I think I
found the problem, please see below. You may already know all this but I
thought a thourough explanation would be better.
> thanks for the hints. I'll test for this later. But what is changed
> internally to Init.sh that it does no longer work on CYGWIN. The CVS
> Version before beta9 worked flawlessly with standard CYGWIN setup.
Andreas, I just checked the Init.sh file in CVS and it doesn't contain
the standard
#! /bin/sh
line as the first line. Could you please put this in your copy of
Init.sh and see if this fixes the problem? Thanks.
--
Sincerely,
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Seems to be a problem in src/general/init/Gmakefile.
