[GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as wxgui is a shell script

[Glynn Clements]

Ivan Shmakov wrote:

>  >>> but for more complex programming python will be better. It's just a
>  >>> matter of choosing a compromise. e.g. for your g.mlist example sh
>  >>> is hard to beat.
> 
>  >> But that's exactly my point -- Python is hardly an alternative for
>  >> the 1.5-liners that you type into the Shell interactively.  And
>  >> depriving a GRASS user of a Shell does, in my opinion, seriously
>  >> limit the usefulness of GRASS.
> 
>  > We aren't depriving them of a shell. We're eliminating the
>  > requirement to install bash even for users who would normally use
>  > either the GUI or cmd.exe.
> 
> 	However, in the other post you're saying that you ``wouldn't
> 	suggest using cmd.exe for scripts.''  And that's the whole
> 	point: cmd.exe is a much worser ``programming language'' than
> 	even POSIX Shell is.

That's a false dichotomy. There are many languages which can be used
for scripting, and interactive shells (i.e. cmd.exe or /bin/sh) are
the worst of the available choices.

On Unix, /bin/sh has the advantage that it's guaranteed to be
available. That's its *only* advantage.

On Windows, you don't even have guaranteed availability as a reason to
use /bin/sh. If you're going to install an interpreter for scripts
which you will be writing yourself, you may as well install Python,
Perl, Tcl, VB, or just about anything other than /bin/sh.

Also, many users have no need for non-trivial scripts. cmd.exe is fine
for trivial scripts where you just want to run a canned sequence of
commands without conditionals, loops, string manipulation, etc. It's
equally fine for use as an interactive shell. Such users shouldn't
need a Bourne shell, and wouldn't need one if GRASS didn't make it a
requirement.

>  > Oh, and we're also eliminating a source of problems for GRASS
>  > developers. On Windows, the problems with shell scripts begin with
>  > the need to install bash, but they certainly don't end there.
> 
> 	Unfortunately, I have to agree on that.
> 
> 	However, won't the communication issues arise due to the fact
> 	that while GRASS/Unix users would use Shell (as it's quite a
> 	natural choice), while their GRASS/W32 counterparts would be
> 	advised to choose, e. g., Python?

Unix programmers would also also be advised to choose something other
than /bin/sh for scripts. Of course, they're free to use /bin/sh if
they really want to, just as Windows programmers are free to use
cmd.exe (or even to install a Bourne shell, if they're feeling
masochistic).

> 	In my opinion, a portable implementation of a Shell (and the
> 	related tools) would be of a much help to the both sides of the
> 	problem.  (And fixing MSYS issues may be an option.)  Though
> 	it's completely out of the scope of the GRASS project.

Unfortunately, Bourne shell is just too "weak" a language to write
portable scripts without going to a lot of trouble. Windows ports of
Bourne shells invariably make some compromises to maintain
compatibility with Unix (e.g. internal filename syntax to avoid the
fact that PATH uses a colon as the separator but Windows uses it for
drive lettors), with the result that you lose compatibility with
Windows (if you pass an MSys filename to a program which then passes
it to the MSVCRT functions, it fails).

Bourne shell sucks as a programming language on Unix, but it sucks
even worse on Windows.

> 	Finally, I could only hope of that there'd be more GNU
> 	installations in the future.  (Would there be a little more help
> 	for me here, I'd certainly prefer running GRASS under GNU/Linux
> 	in the classroom.)

Also, bear in mind that the Cygwin version won't be going anywhere. 
That has the advantage that you don't need to deal with the mismatch
between MSys' syntax and Windows syntax, as Cygwin maintains Unix
compatibility all the way down.

>  >> Thus, while MSYS' or Cygwin's Shell (and the ``usual'' tools) may be
>  >> somewhat difficult to deploy on W32, it seems to me just unavoidable
>  >> to have them installed in order to do anything useful with GRASS.
> 
>  > Not really. Simple tasks can be done with just the GUI.
> 
> 	One certainly won't go far only doing simple tasks.
> 
>  > More complex tasks really deserve a proper programming language.  The
>  > range inbetween, where bash is a reasonable solution, is actually
>  > quite narrow.
> 
> 	The only thing that I have to say in the defense of Bash is that
> 	the little languages always have a narrow, but not a negligible
> 	niche.

It's narrow enough that, for any task where bash is the optimal
solution, either cmd.exe or a real language won't be all that far from
optimal. IOW, it's not a major problem if you don't have it.

>  > Even moreso when you consider that the lower end of that range is
>  > adequately covered by cmd.exe (and most Windows users will probably
>  > be more familiar with that than with bash).
> 
> 	I guess that most of the Windows users which aren't familiar
> 	with programming aren't probably familiar with cmd.exe either,
> 	and those who're familiar with the former most probably know a
> 	programming language which is much better suited for GRASS
> 	programming than cmd.exe.

I'm not sure what your point is here. bash has no merit for either set
of users. Users who don't know cmd.exe won't know bash either. Users
who only know a real language should (and probably will) use that. 
Windows users who know bash but not cmd.exe are likely to be
non-existent. Windows users who only know cmd.exe but find it
inadequate need to learn another language, and they would be better
off learning anything but bash.

>  > IOW, anything which is too complex for cmd.exe should probably be
>  > done with a real language, even if it can be done with bash.
> 
> 	I don't think so.

Why?

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