On approximately 1/1/2004 5:58 PM, came the following characters from the keyboard of Glenn Linderman:
On approximately 1/1/2004 3:27 PM, came the following characters from the keyboard of Morbus Iff:
I deleted a bunch of discussion I couldn't follow the logic of...
Here is what I want:
# as per your thoughts: use $TEMP/par-$USER-EXEID, and # clean up the existing files inside at BEGIN/END. pp -o AmphetaDesk.exe AmphetaDesk.pl
# as per your thoughts: use $TEMP/par-$PID, and # clean up the existing files inside at BEGIN/END. pp -o AmphetaDesk.exe -cleartemp AmphetaDesk.pl
It is not clear to me why par-$USER-EXEID would be used sometimes, and par-$PID would be used sometimes. Seems like the latter is more unique over time, if a single user can run multiple copies of the same par .exe file.
# where-ever the .exe ends up, assume a data/internal # directory exists. if it doesn't, create it automatically. # no cleaning at BEGIN/END. pp -o AmphetaDesk.exe -temp data/internal AmphetaDesk.pl
# where-ever the .exe ends up, assume a data/internal # directory exists. if it doesn't, create it automatically. # since "cleartemp" is set, we cleanup at BEGIN/END. pp -o AmphetaDesk.exe -temp data/internal -cleartemp AmphetaDesk.pl
This data/internal thing... really, if AmphetaDesk.exe (per the example) is installed in c:\Program Files\somewhere, then data/internal should not be placed underneath it. It is dynamic user data, and should be placed (per Windows recommendations) under c:\Documents and Settings\user\Application Data\somewhere\data\internal where "somewhere" is probably AmphetaDesk, or MorbusSoftware or some such thing. So it would be nice to have an option that -temp could be specified on the pp command line to eventually wind up at the runtime location specified by $ENV{APPDATA}/AmphetaDesk/data/internal
If $ENV{APPDATA} doesn't exist (Windows pre 2000), then the installation location of the .exe is probably an appropriate prefix for the path, as is suggested here (the rules were different on Win9x; not sure what they were on NT4, actually)
I'm not sure if this needs to be conditional on the .exe being installed in Program Files, but could simply be used regardless of where it is installed, if it is running on a Windows that defines $ENV{APPDATA}, and a relative -temp path was specified.
Since the options are to pp, they'd be internal to the .exe, not dependent
on anything from the environment (save $TEMP and $USER, where needed).
At runtime, no $ENV: $TEMP/par-$USER-$EXEID, clean at BEGIN/END.
At runtime, $PAR_TEMP: use that directory, no cleaning.
At runtime, $PAR_CLEARTEMP: use $TEMP/par-$PID, clean at BEGIN/END.
At runtime, $PAR_TEMP/CLEARTEMP: use that directory, clean at BEGIN/END.
My second comment is that at build time it might be nice to be able to disable some or all of these runtime options. At least, to be able to disable all of them.
Other than the above comment, the set of desired functionality sounds practical to me, even though I didn't understand the discussion leading up to it.
Like I sound, the sounded practical, and then I thought about it more, and came up with these additional 2 comments.
-- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing.
