From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: Invalid function: with-parsed-tramp-file-name with Perl Date: Thu, 20 Sep 2012 12:29:50 -0600 Message-ID: <87k3vo35up.fsf@gmx.com> References: <87hau4ubgp.fsf@slate.zedat.fu-berlin.de> <7708.1340286834@alphaville> <87a9zwvhtp.fsf@slate.zedat.fu-berlin.de> <8083.1340291591@alphaville> <87395jub00.fsf@slate.zedat.fu-berlin.de> <877grro2av.fsf@slate.zedat.fu-berlin.de> <87haqupgfx.fsf@bzg.ath.cx> <87k3vqfjkd.fsf@slate.zedat.fu-berlin.de> <87wqzql4e6.fsf@bzg.ath.cx> <87boh2fgqu.fsf@slate.zedat.fu-berlin.de> <6364.1348062546@alphaville> <878vc5n8uu.fsf@Rainer.invalid> <9580.1348084284@alphaville.americas.hpqcorp.net> <87a9wkwzpa.fsf@slate.zedat.fu-berlin.de> <10076.1348153868@alphaville> <11268.1348155026@alphaville> <13825.1348161712@alphaville> <14004.1348162579@alphaville> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:53807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TElgD-0005Ho-W0 for emacs-orgmode@gnu.org; Thu, 20 Sep 2012 14:40:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TElgC-0005Pf-HE for emacs-orgmode@gnu.org; Thu, 20 Sep 2012 14:40:53 -0400 Received: from mailout-eu.gmx.com ([213.165.64.43]:60325) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1TElgC-0005PZ-81 for emacs-orgmode@gnu.org; Thu, 20 Sep 2012 14:40:52 -0400 In-Reply-To: <14004.1348162579@alphaville> (Nick Dokos's message of "Thu, 20 Sep 2012 13:36:19 -0400") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: nicholas.dokos@hp.com Cc: Loris Bennett , emacs-orgmode@gnu.org Nick Dokos writes: > Nick Dokos wrote: > >> I haven't chased it all the way down because the reverts are >> making my head spin, but it may be that somehow the above commit >> got lost somewhere - or it got fixed and then the big revert lost >> the fix. Maybe Eric or Bastien remembers what happened. >> > > This doesn't make sense (I blame the head-spinning reverts :-) ), so let > me try again: Eric's commit broke it between 7.8.03 and 7.8.04. It got > fixed somehow, either because of a revert or because some fix was > actually applied, I don't know which. It was working until 7.8.10 and > then Bastien's commit reverted to (broken) 7.8.04, so from 7.8.11- on > the breakage exists. > > So if there was a fix, we need to find it and reapply. If not, someone > (presumably Eric) will need to take a look and possibly develop a fix. > I've spent some time looking at this. A couple of things are happening. Back in the time of 7.8.03 and 7.8.04, the org-babel-execute:sh call happened in such a context that all external function calls would take place on the remote machine if the :dir header specified a tramp path to a remote machine. This is true both before and after my 5cb80c7e5b9bca commit. However this has changed between then and now, meaning that reverting the 5cb80c7e5b9bca commit now will not solve this problem. In the current branch there is no change of context s.t. external calls made by the org-babel-execute:* functions happen by default on the remote machine. I think this is the real problem. Perhaps it would be possible to git bisect with another language like perl? Sorry I'm not more help here, the remote-execution magic was mainly implemented by Dan Davison. Best, > > Nick > > > -- Eric Schulte http://cs.unm.edu/~eschulte