Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
/tmp and exec on OS X
83 views
Skip to first unread message
Kevin Walzer
Nov 9, 2012, 11:21:45 AM11/9/12
to
I'm trying to configure a Tcl/Tk application for the Mac App Store, and
under Apple's increasingly stringent sandbox guidelines, /tmp is no
longer generally available for writing temporary files. For explicitly
writing temp files I can obtain an alternate, approved location via the
env(TMPDIR) variable, but I'm running into a serious issue when trying
to run "exec" or open a pipe: it appears that, under the hood, Tcl
hard-codes "/tmp" as the Unix temporary directory. This means that I'm
not able to call any external programs in the current setup because I
can't write to /tmp. Is there any way to work around this, for instance
by configuring exec to respect the env(TMPDIR) variable? I am dependent
on a system installation of Tcl so patching Tcl itself is not an option.
Advice is appreciated.
Thanks,
Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
under Apple's increasingly stringent sandbox guidelines, /tmp is no
longer generally available for writing temporary files. For explicitly
writing temp files I can obtain an alternate, approved location via the
env(TMPDIR) variable, but I'm running into a serious issue when trying
to run "exec" or open a pipe: it appears that, under the hood, Tcl
hard-codes "/tmp" as the Unix temporary directory. This means that I'm
not able to call any external programs in the current setup because I
can't write to /tmp. Is there any way to work around this, for instance
by configuring exec to respect the env(TMPDIR) variable? I am dependent
on a system installation of Tcl so patching Tcl itself is not an option.
Advice is appreciated.
Thanks,
Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Alexandre Ferrieux
Nov 9, 2012, 5:41:18 PM11/9/12
to
does seem to take env(TMPDIR) into account, and resort to /tmp only if
TMPDIR is not usable.
Please clarify (1) how you discovered that /tmp was hard-coded
(syscall trace ?) and (2) your options regarding Tcl versions,
specific builds etc. (I'm ignorant about the Mac appstore; can you
assume or require a standard Tcl distro on the Mac, or do you
necessarily ship a wrapped Tcl ?)
-Alex
Kevin Walzer
Nov 9, 2012, 6:22:38 PM11/9/12
to
On 11/9/12 5:41 PM, Alexandre Ferrieux wrote:
>
> Looking at 8.6 HEAD, function DefaultTempDir in unix/tclUnixFCmd.c
> does seem to take env(TMPDIR) into account, and resort to /tmp only if
> TMPDIR is not usable.
>
> Please clarify (1) how you discovered that /tmp was hard-coded
> (syscall trace ?) and (2) your options regarding Tcl versions,
> specific builds etc. (I'm ignorant about the Mac appstore; can you
> assume or require a standard Tcl distro on the Mac, or do you
> necessarily ship a wrapped Tcl ?)
Using Tcl 8.5.9, the system install on OS X 10.7. The sandbox daemon
>
> Looking at 8.6 HEAD, function DefaultTempDir in unix/tclUnixFCmd.c
> does seem to take env(TMPDIR) into account, and resort to /tmp only if
> TMPDIR is not usable.
>
> Please clarify (1) how you discovered that /tmp was hard-coded
> (syscall trace ?) and (2) your options regarding Tcl versions,
> specific builds etc. (I'm ignorant about the Mac appstore; can you
> assume or require a standard Tcl distro on the Mac, or do you
> necessarily ship a wrapped Tcl ?)
returns this output in the console:
deny file-write-create /private/var/tmp/tcl3RN6Si
The C-API-level command that's being called is TclpCreateTempFile.
This thread from c.l.t suggested that I could work around the issue by
redirecting stderr to a directory that I had permission to write to:
https://groups.google.com/forum/?fromgroups#!topic/comp.lang.tcl/ync_gL_Gufg
but I haven't been able to get it working.
Kevin Walzer
Nov 9, 2012, 6:41:47 PM11/9/12
to
On 11/9/12 6:22 PM, Kevin Walzer wrote:
> This thread from c.l.t suggested that I could work around the issue by
> redirecting stderr to a directory that I had permission to write to:
>
> https://groups.google.com/forum/?fromgroups#!topic/comp.lang.tcl/ync_gL_Gufg
>
>
> but I haven't been able to get it working.
Looks like I *can* get it working If i request the appropriate
> This thread from c.l.t suggested that I could work around the issue by
> redirecting stderr to a directory that I had permission to write to:
>
> https://groups.google.com/forum/?fromgroups#!topic/comp.lang.tcl/ync_gL_Gufg
>
>
> but I haven't been able to get it working.
entitlements from the Mac sandbox daemon, per the instructions in the
thread above...just redirect stdout to a writable directory.
Alexandre Ferrieux
Nov 9, 2012, 6:45:51 PM11/9/12
to
On Nov 10, 12:22 am, Kevin Walzer <k...@codebykevin.com> wrote:
> On 11/9/12 5:41 PM, Alexandre Ferrieux wrote:
>
>
>
> > Looking at 8.6 HEAD, function DefaultTempDir in unix/tclUnixFCmd.c
> > does seem to take env(TMPDIR) into account, and resort to /tmp only if
> > TMPDIR is not usable.
>
> > Please clarify (1) how you discovered that /tmp was hard-coded
> > (syscall trace ?) and (2) your options regarding Tcl versions,
> > specific builds etc. (I'm ignorant about the Mac appstore; can you
> > assume or require a standard Tcl distro on the Mac, or do you
> > necessarily ship a wrapped Tcl ?)
>
> Using Tcl 8.5.9, the system install on OS X 10.7. The sandbox daemon
Ah, OK, old version, then. Any reason to stick to it ?
> On 11/9/12 5:41 PM, Alexandre Ferrieux wrote:
>
>
>
> > Looking at 8.6 HEAD, function DefaultTempDir in unix/tclUnixFCmd.c
> > does seem to take env(TMPDIR) into account, and resort to /tmp only if
> > TMPDIR is not usable.
>
> > Please clarify (1) how you discovered that /tmp was hard-coded
> > (syscall trace ?) and (2) your options regarding Tcl versions,
> > specific builds etc. (I'm ignorant about the Mac appstore; can you
> > assume or require a standard Tcl distro on the Mac, or do you
> > necessarily ship a wrapped Tcl ?)
>
> Using Tcl 8.5.9, the system install on OS X 10.7. The sandbox daemon
> This thread from c.l.t suggested that I could work around the issue by
> redirecting stderr to a directory that I had permission to write to:
> but I haven't been able to get it working.
Yeah, if you redirect stderr, Tcl will not attempt to create a
tempfile (because this tempfile is here to gather stderr output
feeding the final error message of [exec]).
Can you clarify "not been able to get it working" ? Precise script and
errors please.
-Alex
Kevin Walzer
Nov 9, 2012, 10:58:27 PM11/9/12
to
On 11/9/12 6:45 PM, Alexandre Ferrieux wrote:
> Can you clarify "not been able to get it working" ? Precise script and
> errors please.
This structure works around the problem by avoiding the /tmp directory,
> Can you clarify "not been able to get it working" ? Precise script and
> errors please.
redirecting both stdout and stderr to other files:
exec /usr/bin/open mailto:k...@codebykevin.com?subject=$appname >$filename
2>$errfile
Donal K. Fellows
Nov 10, 2012, 5:57:20 PM11/10/12
to
On 10/11/2012 03:58, Kevin Walzer wrote:
> On 11/9/12 6:45 PM, Alexandre Ferrieux wrote:
>> Can you clarify "not been able to get it working" ? Precise script and
>> errors please.
>
> This structure works around the problem by avoiding the /tmp directory,
> redirecting both stdout and stderr to other files:
Ugh, the code in tclUnixFCmd.c and tclUnixPipe.c are different in what
> On 11/9/12 6:45 PM, Alexandre Ferrieux wrote:
>> Can you clarify "not been able to get it working" ? Precise script and
>> errors please.
>
> This structure works around the problem by avoiding the /tmp directory,
> redirecting both stdout and stderr to other files:
they respect. That's bad. The code in tclUnixPipe.c also includes
near-duplications, which isn't good code-smell either.
If you're up to recompiling in this particular situation, edit
tclUnixPipe.c to alter the definition of P_tmpdir (after all #includes
have been done) to be the location that is permissible. (Really, that
ought to be set to the correct place during the build process, but it
sounds like it isn't for some reason.)
And do file a bug on this. Too much duplication with things wrong in too
many places.
Donal.
Kevin Walzer
Nov 10, 2012, 7:26:12 PM11/10/12
to
On 11/10/12 5:57 PM, Donal K. Fellows wrote:
>
> Ugh, the code in tclUnixFCmd.c and tclUnixPipe.c are different in what
> they respect. That's bad. The code in tclUnixPipe.c also includes
> near-duplications, which isn't good code-smell either.
>
> If you're up to recompiling in this particular situation, edit
> tclUnixPipe.c to alter the definition of P_tmpdir (after all #includes
> have been done) to be the location that is permissible. (Really, that
> ought to be set to the correct place during the build process, but it
> sounds like it isn't for some reason.)
>
> And do file a bug on this. Too much duplication with things wrong in too
> many places.
I believe
>
> Ugh, the code in tclUnixFCmd.c and tclUnixPipe.c are different in what
> they respect. That's bad. The code in tclUnixPipe.c also includes
> near-duplications, which isn't good code-smell either.
>
> If you're up to recompiling in this particular situation, edit
> tclUnixPipe.c to alter the definition of P_tmpdir (after all #includes
> have been done) to be the location that is permissible. (Really, that
> ought to be set to the correct place during the build process, but it
> sounds like it isn't for some reason.)
>
> And do file a bug on this. Too much duplication with things wrong in too
> many places.
http://sourceforge.net/tracker/?func=detail&aid=2933003&group_id=10894&atid=110894
touches on this issue?
Donal K. Fellows
Nov 11, 2012, 4:50:41 AM11/11/12
to
Donal.
0 new messages