Opened 8 years ago
Last modified 5 years ago
#3342 assigned defect
Support addon modules written in Bash
Reported by: | wenzeslaus | Owned by: | wenzeslaus |
---|---|---|---|
Priority: | normal | Milestone: | 7.8.3 |
Component: | Addons | Version: | svn-trunk |
Keywords: | shell, bash, g.extension, addons | Cc: | |
CPU: | Unspecified | Platform: | Unspecified |
Description
I think we should officially support, at the least to certain extent, addon modules written in Bash.
With the attached files I'm able to compile modules written in Bash locally and get the generated GUI on Linux.
Linux and Mac users have Bash or other shells and on Windows many users will have Bash as part of something else or can install it (but very likely it will not be on path).
I think on Windows we can say that users need to set some environmental variable to use Bash which will be used in a BAT file to run the script, so following what is in source:grass/trunk/scripts/windows_launch.bat it would look like this:
@"%GRASS_SHELL%" "SCRIPT_DIR/SCRIPT_NAME.py" %*
Different shells won't be a problem on Linux as long as the user has the right one. On Windows it will be a problem but I would just aim it towards Bash and see if it is enough.
Just be be clear: I don't think Bash modules should be allowed in the core.
Attachments (3)
Change History (11)
by , 8 years ago
Attachment: | ShScript.make added |
---|
by , 8 years ago
Attachment: | bash_scripts_as_modules.diff added |
---|
Patch to create Makefiles for Bash modules (svn cp from existing Python-related files)
comment:1 by , 8 years ago
The submitted patch works for me locally (make MODULE_TOPDIR=...
) on Linux with r.edm.eval
, r.stream.variables
and r.stream.watersheds
.
MS Windows users will need to set GRASS_SHELL
variable to something reasonable make it work:
SET GRASS_SHELL="%programfiles%\someapp\bin\bash.exe"
This is the case also for the server which compiles the addons to be consumed by g.extension on MS Windows. I suppose something more is needed there to have them packed by the scripts on the server and unpacked by g.extension - I don't know where to start at this point (please suggest), but I assume it is doable.
I plan to extent the Windows launch script with this code to give a nice error message (not tested):
REM Unfortunately not a translatable message IF "%GRASS_SHELL%"=="" ( ECHO The GRASS_SHELL environmental variable is not defined. ECHO To use Bash/Shell scripts in GRASS GIS, set the variable using something like: ECHO SET GRASS_SHELL="C:\path\to\bash.exe" EXIT /b )
What needs to be documented is making this work on Windows from user perspective and then for the contributors we need suggestions on when to use Bash/Shell (like perhaps prefer /bin/sh over Bash, when to switch to Python, etc.).
If there are no objections I will commit what I have together with fixes in the individual addon modules.
comment:2 by , 8 years ago
Experimental support committed in r71041. It is expected to work locally (make MODULE_TOPDIR=...
) on Linux and other unix-like systems.
Not tested on MS Windows, please test if possible (you need to have GRASS compilation up and running). You need to set the GRASS_SHELL
environmental variable to point to Bash or whatever the particular script needs (usually /bin/sh
or /bin/bash
is specified).
Shell addon modules fixed in r71043. There is still few shell scripts not working and I'm not sure if these should be modules or not.
comment:4 by , 7 years ago
Milestone: | 7.4.1 → 7.4.2 |
---|
comment:5 by , 6 years ago
Milestone: | 7.4.2 → 7.6.1 |
---|
comment:8 by , 5 years ago
Milestone: | → 7.8.3 |
---|
G7 Script.make modified for Bash