> > Glynn wrote: > >> Modify the g.extension script to use sudo rather than "su -c ...". Hamish: > > I've already done that. Try the -u flag. Markus: > I have drastically simplified g.extension to two lines, being > a wrapper for the way better g.extension.py which is included > in the wxGUI of 6.4 and 6.5.
is it way better? How? Why? I really doubt it because the main problems with g.extension have nothing to do with the programming language or programmer's ability, and are common to both. the main structural problems with it are: - ill/dual-defined use of GRASS_ADDON_PATH as both a /usr/local/bin substitute and a /usr/local prefix. William has also implemented a partial solution to that on OSX some time ago. - different systems will have different ways of authorizing administration permissions. on linux there is su and sudo in the wild, on OSX there is sudo and a $USER's personal Library, on MS Windows there are other layers... getting this right on all permutations and combinations will take time. - to install system wide or per-user? - gcc/Makefile linking issues for C programs - ... probably more but I'm in a rush right now (back in the office next week) > Find it attached. In my opinion there is not much point to > continue to hack the shell version if the Python script > does it much better. Of course you need Python being installed. I need to research the python version more, but I don't understand how it could magically solve the above problems, or what is fundamentally broken the the existing shell version. I never really understood the rationale for backporting the python version of it in the first place, but I trust Martin to sculpt the wxGUI as he sees fit so don't mind it there, even if keeping two live copies of the same thing in the same release is inefficient to support. most of g.ext is moving files around and running shell programs, which is a natural thing to keep in a shell script. > I didn't submit it yet to SVN. Before we blast away any existing code, I'd like to know if there are programming or structural problems in the shell version, if the python version really solves these problems in a fundamentally better way, and why the shell version can't use the same method. I am willing to put up my time to fix the shell scripts if need be, but right now I'm not aware of any problems which are not structural in nature, ie independent of implementation language. I would like to post a more constructive email, but I'm being pulled out the door right now, and don't know of specific code problems that need work so can't give a patch to fix it. thanks for your patience, Hamish _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
