On Thu, 14 May 2009, Kenneth Ölwing wrote:
>  > This is already possible with --tmpdir, so I assume what you are
>  > asking for is that PerlApp should try to create this directory if it
>  > doesn't already exist. Would that already solve the problem?
>  >
>  Yes.
> 
>  I think the point may be that --tmpdir might need to understand some
>  more stuff, to ensure that it stays backward compatible; it'd make
>  sense to have to add something to cater for this 'extended' need. And,
>  if it changes in that direction, it would also be possible to throw in
>  some more stuff (like what envvar should be used rather than the
>  default). But that's really optional - if it just stops requiring that
>  the dir exists and just creates it (by default with 777, I guess) it'd
>  go a long way.

No, it would be 700, or 744 at most.  You don't want other users to
be able to write to your temp directory; that way they can inject any
code they want into your program.

>  > Note that you can be as flexible as you want if you distribute your
>  > app as 2 files: the actual PerlApp'ed executable and a simple
>  > wrapper script or batchfile to run it (untested, just typed into
>  > email client):
>  >
>  Oh, absolutely - but one of the defining points with perlapp'ing I
>  really, really like is that I get one (1) executable and that's it
>  (ok, one per platform I support...). It becomes incredibly easy to
>  move around as a completely selfcontained unit. That's not to say I

I understand that having the single file deployment is one of the
reasons to use PerlApp in the first place.  I was only offering the
wrapper script idea as a potential workaround if you must be more
flexible than what PerlApp itself offers.

>  don't *also* offer the wrapper - it's required in situations where I
>  have to define how to start my tool in a way that's generic to many
>  platforms, and so it runs a wrapper to get the correct executable by
>  using uname -s -p. But 1) it's far from the only way to run it, and 2)
>  there's the slight overhead that it imposes.
> 
>  Well, it's certainly not critical and I appreciate everyones input.
>  Whether it makes sense I let you decide as you obviously have to weigh
>  aspects of support, unforeseen trickiness, where it'd on a bug/feature
>  request priority scale etc etc.

All the code implementing this will have to be written in C, might be
different for each platform and will be in the part of the code included
in every single generated PerlApp.

So I definitely don't want to overengineer it, and I'm also wary of
introducing potential problems/vulnerabilities for the majority of
the users who will never use this mechanism.

So I thing creating the --tmpdir directory if it doesn't exist makes
sense, and maybe allowing to specify an environment variable
instead of a static PATH might be reasonable too.  But any kind of
cascading fallbacks (if the environment variable isn't set), or
a more complex variable substitution sublanguage, or setting different
mode bits etc are all too much complicated.

Cheers,
-Jan

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