[GRASS-dev] Using a multi-"${GIS_OPT_X}" input in a shell for loop

Hamish hamish_b at yahoo.com
Wed Nov 13 11:06:00 PST 2013



Glynn:
>>Example:
>>
>>        $ hello='hi     there'
>>        $ echo $hello
>>        hi there
>>        $ echo "$hello"
>>        hi     there


here's another example:
FOO="a b"
BAR="c d"
mkdir ${FOO}
mkdir "$BAR"
ls -l
drwxr-xr-x  a/
drwxr-xr-x  b/
drwxr-xr-x  c d/


Vaclav:
> I remember that we had this conversation recently.

I tend to repost that lesson every time I see curly brackets, in a quixotic attempt to stamp them out. :)


> What about putting some (ba)sh(ell) primer into the manual?

My concern with that is where does it end? Do we add a UNIX primer too? I think it's a very good idea to put links in the wiki to existing tutorials though, but no need for us to rewrite what's already been written many times. Some tips are already in the SUBMITTING_SCRIPTS files. Often the best advice is to just use the existing GRASS scripts as a template. (be it python or bourne scripting)

> However, I must say the same I said before. If you need some
> advanced bash functionality such as `if` and `for` or even
> functions it is better to use/learn Python instead.

I humbly disagree, but probably only on what would be
considered 'advanced functionality'. I'd put the bar more at
the subtle quoting for dynamic variable names needing `eval`
and nested multi-level $(``) executions, or needing to write
some complicated awk or regex statement. i.e. once it gets to
the point where it isn't human readable anymore.. but I guess
the discussion is highly academic since we're not proposing to
change anything from what we do now.



For manipulating huge amounts of ascii data there's not
much in the world that can beat the UNIX powertools piped
together in a shell script. Also it's hard to beat the
simplicity of cutting and pasting the last five lines
you entered onto the command line into a text editor
and saving the file with a ".sh" extension.  i.e. a gentle
introduction to programming for command line users. (this
is why I really like having the command line self-assemble at the bottom of the module GUIs)

Both python and shell scripting are fine tools, each with their
own niche; I would hope we could identify the best tool for the
job based on the niche, and not devolve into me trying to use
shell scripting for everything because I know it well, and
others trying to use python for everything because they know it
well. And rather both use the most appropriate tool for the job
on a needs basis, and get better in both. :)


2c,
Hamish



More information about the grass-dev mailing list