Thanks for the reply, Bernhard. My understanding is that Tup will not export anything by default except PATH. Even so, I've tried the same tests with explicit command paths (like "/usr/bin/touch") with the same results. I wouldn't expect that coreutils like touch require any other environment variables, but it is at least something to investigate further.
I also forgot to mention that emacs itself *can* write to files. So org-export, which I guess does its file access directly (from the C functions) does work. It's only when launching a sub-process (as is needed for org babel) that I run into this problem. Thanks again, Gavin On Thursday, June 18, 2015 at 9:29:30 AM UTC-5, [email protected] wrote: > > Please keep in mind that tup will pass a rather clean environment to its > subprocesses. Maybe emacs misses something in its environment. You can > force tup to pass select variables with the "export" directive. > > Kind regards, Bernhard. > > > On 18 June 2015 15:52:38 CEST, Gavin Cannizzaro <[email protected] > <javascript:>> wrote: >> >> Further research shows that *all* commands (that I could think to try) >> return status 125 when called by emacs call-process via Tup. I'm assuming >> this has something to do with the fuse mount. >> >> Does anyone know what status 125 means? I haven't determined whether >> it's coming from the processes themselves, or from emacs, or fuse. >> >> Also, is there any way that I can debug this while the mount is active? >> By the time Tup is finished, the paths reported by commands no longer >> exist. >> >> Thanks, >> Gavin >> >> -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
