Re: [GRASS-dev] clean_temp.c versus deleting mapset's .tmp
On 21/05/15 18:11, Vaclav Petras wrote: On Thu, May 21, 2015 at 11:01 AM, William Hargrove h...@geobabble.org mailto:h...@geobabble.org wrote: This is for old GRASS codgers like me who run GRASS commands *outside* the GRASS shell, by setting all of the environment variables. This is the way that we change active mapsets as well. I do this to have all of the *nix commands integrated seamlessly with GRASS commands. Hi Bill, it's good to have this feedback. I understand what you are doing but I'm not sure about the details. If a particular GRASS command aborts or dies, the temp files in the .tmp directory are left behind. Since we never run the shell, .tmp is never deleted, and they build up, eating disk space. So you are using clean_temp in your scripts? This thread is also germane with respect to the current discussion of GRASS environment variables. Currently I shift between GRASS 6 and 7 by sourcing an alternative .bashrc file that makes use of the strippath function to clean GRASS 6 stuff from the existing paths ... Please don't eliminate env variables or alter them too significantly ... It would be best if you send the scripts and .bashrc you are using. If you have there too much private stuff and you don't want to clean it, please send it to me, I'll should be able to understand. It's hard to tell which parts of interface people are actually using (or what they consider as an interface). The actual code is thus necessary. Note also that there is a new interface (in trunk) which removes the need for setting up the (fake) GRASS session manually [1]. But changes to user's scripts are needed. [1] https://trac.osgeo.org/grass/ticket/2579#comment:14 I think this new interface is really great and will be really useful for many of us. Thanks Vaclav ! However, if you write a script calling many different GRASS commands, it might still be more convenient to just set a few variables at the beginning of the script (or source a specific rc files as Bill) and then just be able to call grass commands as any other shell command, instead of having to type 'grass71 ~/grassdata/nc_spm_08_grass7/user1/ --exec' every time you want to run a module. I think that more generally, unless a feature really causes trouble, it is safer to just leave it instead of trying to remove it for reasons of code cleanliness or aesthetics. Or said more simply: if it's not clearly broken, don't fix it. GRASS GIS is so old that many different use forms have developed over the decades and it would be very difficult to know about all of them. And even though many new users (and sometimes developers) approach GRASS GIS as a monolothic GUI application, many older users use it in the form it was conceived in, i.e. a collection of command line tools that integrate into the *nix environment. Please don't make life harder for those. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] clean_temp.c versus deleting mapset's .tmp
Vaclav Petras wrote: when I was working on grass.py I saw there usage of clean_temp function which calls clean_temp program and deletion of the whole .tmp directory and I can't make sense out of it. It seems to me that clean_temp (lib/init/clean_temp.c) executable called in grass.py is not necessary because the whole .tmp directory is anyway deleted at the beginning and at the end of the session. clean_temp is doing some special cleaning according to pids but whole directory is deleted anyway at the end. Can the whole lib/init/clean_temp.c can be safely removed? Or maybe it has some meaning when executed before the session starts because at that point .tmp is not deleted. Can someone please clarify this for me here or in the source code? Also, the clean_temp function is called manually while other cleanups are called using at exit mechanism. Supposing we need the clean up at all, I'm not sure if there is any reason to keep it explicit. Perhaps this was just inconsistency, not an intention. clean_temp is more restrictive in what it will remove (only files owned by the current user, only files older than 4 days). The original rationale for this behaviour is probably forgotten, and it's unclear if it's still valid (probably not, if the startup script is removing the entire directory at the end of the session and no-one has complained). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] clean_temp.c versus deleting mapset's .tmp
This is for old GRASS codgers like me who run GRASS commands *outside* the GRASS shell, by setting all of the environment variables. This is the way that we change active mapsets as well. I do this to have all of the *nix commands integrated seamlessly with GRASS commands. If a particular GRASS command aborts or dies, the temp files in the .tmp directory are left behind. Since we never run the shell, .tmp is never deleted, and they build up, eating disk space. This thread is also germane with respect to the current discussion of GRASS environment variables. Currently I shift between GRASS 6 and 7 by sourcing an alternative .bashrc file that makes use of the strippath function to clean GRASS 6 stuff from the existing paths ... Please don't eliminate env variables or alter them too significantly ... Thanks, Bill H. On 05/21/2015 04:45 AM, Glynn Clements wrote: Vaclav Petras wrote: when I was working on grass.py I saw there usage of clean_temp function which calls clean_temp program and deletion of the whole .tmp directory and I can't make sense out of it. It seems to me that clean_temp (lib/init/clean_temp.c) executable called in grass.py is not necessary because the whole .tmp directory is anyway deleted at the beginning and at the end of the session. clean_temp is doing some special cleaning according to pids but whole directory is deleted anyway at the end. Can the whole lib/init/clean_temp.c can be safely removed? Or maybe it has some meaning when executed before the session starts because at that point .tmp is not deleted. Can someone please clarify this for me here or in the source code? Also, the clean_temp function is called manually while other cleanups are called using at exit mechanism. Supposing we need the clean up at all, I'm not sure if there is any reason to keep it explicit. Perhaps this was just inconsistency, not an intention. clean_temp is more restrictive in what it will remove (only files owned by the current user, only files older than 4 days). The original rationale for this behaviour is probably forgotten, and it's unclear if it's still valid (probably not, if the startup script is removing the entire directory at the end of the session and no-one has complained). -- William W. Hargrove Eastern Forest Environmental Threat Assessment Center USDA Forest Service Southern Research Station 200 WT Weaver Boulevard Asheville, NC 28804-3454 (828) 257-4846 (865) 235-4753 (cell) (828) 257-4313 (fax) h...@geobabble.org http://www.geobabble.org/~hnw ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] clean_temp.c versus deleting mapset's .tmp
On Thu, May 21, 2015 at 11:01 AM, William Hargrove h...@geobabble.org wrote: This is for old GRASS codgers like me who run GRASS commands *outside* the GRASS shell, by setting all of the environment variables. This is the way that we change active mapsets as well. I do this to have all of the *nix commands integrated seamlessly with GRASS commands. Hi Bill, it's good to have this feedback. I understand what you are doing but I'm not sure about the details. If a particular GRASS command aborts or dies, the temp files in the .tmp directory are left behind. Since we never run the shell, .tmp is never deleted, and they build up, eating disk space. So you are using clean_temp in your scripts? This thread is also germane with respect to the current discussion of GRASS environment variables. Currently I shift between GRASS 6 and 7 by sourcing an alternative .bashrc file that makes use of the strippath function to clean GRASS 6 stuff from the existing paths ... Please don't eliminate env variables or alter them too significantly ... It would be best if you send the scripts and .bashrc you are using. If you have there too much private stuff and you don't want to clean it, please send it to me, I'll should be able to understand. It's hard to tell which parts of interface people are actually using (or what they consider as an interface). The actual code is thus necessary. Note also that there is a new interface (in trunk) which removes the need for setting up the (fake) GRASS session manually [1]. But changes to user's scripts are needed. [1] https://trac.osgeo.org/grass/ticket/2579#comment:14 Thanks, Bill H. On 05/21/2015 04:45 AM, Glynn Clements wrote: Vaclav Petras wrote: when I was working on grass.py I saw there usage of clean_temp function which calls clean_temp program and deletion of the whole .tmp directory and I can't make sense out of it. It seems to me that clean_temp (lib/init/clean_temp.c) executable called in grass.py is not necessary because the whole .tmp directory is anyway deleted at the beginning and at the end of the session. clean_temp is doing some special cleaning according to pids but whole directory is deleted anyway at the end. Can the whole lib/init/clean_temp.c can be safely removed? Or maybe it has some meaning when executed before the session starts because at that point .tmp is not deleted. Can someone please clarify this for me here or in the source code? Also, the clean_temp function is called manually while other cleanups are called using at exit mechanism. Supposing we need the clean up at all, I'm not sure if there is any reason to keep it explicit. Perhaps this was just inconsistency, not an intention. clean_temp is more restrictive in what it will remove (only files owned by the current user, only files older than 4 days). The original rationale for this behaviour is probably forgotten, and it's unclear if it's still valid (probably not, if the startup script is removing the entire directory at the end of the session and no-one has complained). -- William W. Hargrove Eastern Forest Environmental Threat Assessment Center USDA Forest Service Southern Research Station 200 WT Weaver Boulevard Asheville, NC 28804-3454 (828) 257-4846 (865) 235-4753 (cell) (828) 257-4313 (fax) h...@geobabble.org http://www.geobabble.org/~hnw ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] clean_temp.c versus deleting mapset's .tmp
Hi, when I was working on grass.py I saw there usage of clean_temp function which calls clean_temp program and deletion of the whole .tmp directory and I can't make sense out of it. It seems to me that clean_temp (lib/init/clean_temp.c) executable called in grass.py is not necessary because the whole .tmp directory is anyway deleted at the beginning and at the end of the session. clean_temp is doing some special cleaning according to pids but whole directory is deleted anyway at the end. Can the whole lib/init/clean_temp.c can be safely removed? Or maybe it has some meaning when executed before the session starts because at that point .tmp is not deleted. Can someone please clarify this for me here or in the source code? Also, the clean_temp function is called manually while other cleanups are called using at exit mechanism. Supposing we need the clean up at all, I'm not sure if there is any reason to keep it explicit. Perhaps this was just inconsistency, not an intention. Thanks for your opinions, Vaclav Related code: http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass.py#L1486 http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass.py#L1741 http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass.py#L1801 http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass.py#L1702 https://trac.osgeo.org/grass/browser/grass/trunk/lib/init/clean_temp.c ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
