Prev: How to transfer "trusted" environment into a safe slave interpreter?
Next: Reading binary file from channel on host computer
From: Mat on 15 Jan 2010 09:40 Hi, in a shared hosting environment, I don't have any access to /tmp which results in all my exec calls to return the error couldn't create error file for command: permission denied I've been assigned a "private" temp dir but am at a loss as to how to tell my script to use that directory instead.. Any ideas? Mat
From: Alexandre Ferrieux on 15 Jan 2010 11:01 On Jan 15, 3:40 pm, Mat <kill_s...(a)matware.net> wrote: > Hi, > > in a shared hosting environment, I don't have any access to > /tmp which results in all my exec calls to return the error > > couldn't create error file for command: permission denied > > I've been assigned a "private" temp dir but am at a loss as to how to > tell my script to use that directory instead.. > > Any ideas? > Mat The temporary file in [exec] serves only when no 2> or 2>@ redirection is given, because the child's stderr output in this case is accumulated to later generate the error message. Unfortunately, that code uses the old, rigid TclpCreateTempFile, which is not as customizable as the more modern TclpOpenTemporaryFile. So it uses a libc header macro P_tmpdir and no env variable :-( So, to work around this limitation, either add "2>@ stderr" so that the child's stderr will simply flow outside, or the -ignorestderr flag to swallow it silently, or explicitly use a file of yours (2>/path/to/ yourfile). -Alex
From: Mat on 15 Jan 2010 12:20 Alexandre Ferrieux wrote: > On Jan 15, 3:40 pm, Mat <kill_s...(a)matware.net> wrote: >> Hi, >> >> in a shared hosting environment, I don't have any access to >> /tmp which results in all my exec calls to return the error >> >> couldn't create error file for command: permission denied >> >> I've been assigned a "private" temp dir but am at a loss as to how to >> tell my script to use that directory instead.. >> >> Any ideas? >> Mat > > The temporary file in [exec] serves only when no 2> or 2>@ redirection > is given, because the child's stderr output in this case is > accumulated to later generate the error message. Unfortunately, that > code uses the old, rigid TclpCreateTempFile, which is not as > customizable as the more modern TclpOpenTemporaryFile. So it uses a > libc header macro P_tmpdir and no env variable :-( > > So, to work around this limitation, either add "2>@ stderr" so that > the child's stderr will simply flow outside, or the -ignorestderr flag > to swallow it silently, or explicitly use a file of yours (2>/path/to/ > yourfile). great! I was hoping, I just needed to change some sort global variable (like in perl or php), so it didn't even occur to me check exec's options :) Using my own file worked.. but then again, I need to add extra stuff (like reading the error file ;) ) to get the actual error message. thanks Mat
From: Mat on 15 Jan 2010 12:47 Mat wrote: > Alexandre Ferrieux wrote: >> On Jan 15, 3:40 pm, Mat <kill_s...(a)matware.net> wrote: >>> Hi, >>> >>> in a shared hosting environment, I don't have any access to >>> /tmp which results in all my exec calls to return the error >>> >>> couldn't create error file for command: permission denied >>> >>> I've been assigned a "private" temp dir but am at a loss as to how to >>> tell my script to use that directory instead.. >>> >>> Any ideas? >>> Mat >> >> The temporary file in [exec] serves only when no 2> or 2>@ redirection >> is given, because the child's stderr output in this case is >> accumulated to later generate the error message. Unfortunately, that >> code uses the old, rigid TclpCreateTempFile, which is not as >> customizable as the more modern TclpOpenTemporaryFile. So it uses a >> libc header macro P_tmpdir and no env variable :-( >> >> So, to work around this limitation, either add "2>@ stderr" so that >> the child's stderr will simply flow outside, or the -ignorestderr flag >> to swallow it silently, or explicitly use a file of yours (2>/path/to/ >> yourfile). > > great! I was hoping, I just needed to change some sort global variable > (like in perl or php), so it didn't even occur to me check exec's > options :) > > Using my own file worked.. but then again, I need to add extra stuff > (like reading the error file ;) ) to get the actual error message. > > > thanks > Mat alright, seems I've been blind while perusing the exec docs.. I'm now using if {[catch {set result [exec {*}$cmd 2>@1]} err]} { set html "ERROR: $err" } else { set html $result } puts $html to get my error message without the need for extra temporary files.. (and I even brought in a 8.5.8 tclkit for that expand goodness :)) Mat
From: Alexandre Ferrieux on 15 Jan 2010 12:48
On Jan 15, 6:20 pm, Mat <kill_s...(a)matware.net> wrote: > Alexandre Ferrieux wrote: > > On Jan 15, 3:40 pm, Mat <kill_s...(a)matware.net> wrote: > >> Hi, > > >> in a shared hosting environment, I don't have any access to > >> /tmp which results in all my exec calls to return the error > > >> couldn't create error file for command: permission denied > > >> I've been assigned a "private" temp dir but am at a loss as to how to > >> tell my script to use that directory instead.. > > >> Any ideas? > >> Mat > > > The temporary file in [exec] serves only when no 2> or 2>@ redirection > > is given, because the child's stderr output in this case is > > accumulated to later generate the error message. Unfortunately, that > > code uses the old, rigid TclpCreateTempFile, which is not as > > customizable as the more modern TclpOpenTemporaryFile. So it uses a > > libc header macro P_tmpdir and no env variable :-( > > > So, to work around this limitation, either add "2>@ stderr" so that > > the child's stderr will simply flow outside, or the -ignorestderr flag > > to swallow it silently, or explicitly use a file of yours (2>/path/to/ > > yourfile). > > great! I was hoping, I just needed to change some sort global variable > (like in perl or php), so it didn't even occur to me check exec's options :) > > Using my own file worked.. but then again, I need to add extra stuff > (like reading the error file ;) ) to get the actual error message. Note that most likely, the child process will have an exit status, like 0 if okay, nonzero if error. This is automatically checked by [exec]. So the only need for the user- provided 2>@ file is if you want the Tcl script to use what was written to stderr by the child. If all you want is for the human debugger to look at it in the logs, just use 2>@ stderr, and let the whole Tcl process's stderr be logged. But I agree this is not very nice from the [exec] code, making the assumption that "/tmp" is not writable. Just created a low-prio bug to track this one: https://sourceforge.net/tracker/?func=detail&aid=2933003&group_id=10894&atid=110894 Thanks for the heads-up ! -Alex |