Hi,

I guess this is mostly aimed at Jan, but I'm sure someone else could 
have useful input...

Before filing a bug/improvement request I figured it could be useful to 
get some pre-response here...:-)

I seem to recall discussion about this flag a couple of years back, but 
it hasn't really been something I needed to care about. However, I now 
have some considerations that would be helped by 'improving' it a bit.

I have a fairly large perlapped application that I distribute 
internally. A hundred or more users, all working on 30-40 'servers', 
desktop machines etc, collectively a variety of platforms (Linux, 
Windows, Solaris, 32/64 bits etc etc) are involved. The app contains a 
fairly large number of extra modules, many with .so/.dll files, so they 
need to be unpacked while in use - I regularly add/update to new 
versions, so new md5'ed copies will show up.

Now, this all works well. But what I would like to do would be to get a 
better grip of the numerous 'pdk-user' dirs that are used for the 
caching of unpacked data, since I don't want them littering /tmp on the 
common servers for all eternity. Silly thing perhaps, but given our 
environment this is something users have asked about and there are other 
reasons for us to keep /tmp et al as 'clean' as possible. (Yes, --dyndll 
is in use but only relevant for Windows, --clean is not desirable - the 
caching makes sense etc).

One way to collect them would be to set the TMPDIR or TEMP envvar 
beforehand - but this is not something I can realistically control for 
all users. Another simple and effective way for me to control them 
better, would be if I could use --tmpdir to ensure they get put under a 
common root. However, the current impl is very limited - it requires 
hardcoding a dir and that it should exist beforehand; also not something 
I can realistically control everywhere.

I see a multitude of possibilities here - allow me to define --tmpdir so 
that it will automatically creates it before using it (with some chmod 
value...). Combine this with making it overridable by an envvar defined 
by me. Possibly, it would also need some way of downgrading to the 
current defaults if nothing else applies.

Yes - this opens some questions and would need some trashing to get 
right. Further, it should obviously not break anything that uses 
--tmpdir today. My thought would be to equip the --tmpdir with something 
similar to --bind for the extra features I'd like to see.

TIA,

ken1

_______________________________________________
PDK mailing list
PDK@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs