From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Loris Bennett" Subject: Re: Erroneous "No such file or directory" with babel and remote dir Date: Wed, 14 Nov 2012 08:48:58 +0100 Message-ID: <87pq3gipzp.fsf@slate.zedat.fu-berlin.de> References: <87y5kiq71h.fsf@slate.zedat.fu-berlin.de> <87vcfapgfy.fsf@bzg.ath.cx> <87a9wd56i6.fsf@slate.zedat.fu-berlin.de> <878vbwhczx.fsf@Rainer.invalid> <87a9wc1uki.fsf@slate.zedat.fu-berlin.de> <87vcf0ft1s.fsf@Rainer.invalid> <87mx0chswg.fsf@slate.zedat.fu-berlin.de> <87r4pnpehe.fsf@Rainer.invalid> <87fw4dlei8.fsf@slate.zedat.fu-berlin.de> <7557.1352869451@alphaville> <9608.1352874199@alphaville> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:43546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYXik-0002dm-Gn for emacs-orgmode@gnu.org; Wed, 14 Nov 2012 02:49:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYXih-0004va-Cj for emacs-orgmode@gnu.org; Wed, 14 Nov 2012 02:49:14 -0500 Received: from plane.gmane.org ([80.91.229.3]:49839) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYXih-0004vO-28 for emacs-orgmode@gnu.org; Wed, 14 Nov 2012 02:49:11 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TYXio-0000U1-3Q for emacs-orgmode@gnu.org; Wed, 14 Nov 2012 08:49:18 +0100 Received: from slate.zedat.fu-berlin.de ([160.45.11.34]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2012 08:49:18 +0100 Received: from loris.bennett by slate.zedat.fu-berlin.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2012 08:49:18 +0100 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: emacs-orgmode@gnu.org Nick Dokos writes: > Nick Dokos wrote: > >> > Back in the days of release_7.01h, the following used to work: >> > >> > ,------------------------------------------ >> > | #+begin_src sh :dir /loris@othercomputer: >> > | hostname >> > | #+end_src >> > `------------------------------------------ >> > >> > Currently it produces the error: >> > >> > ,--------------------------------------------------- >> > | apply: Wrong type argument: number-or-marker-p, "" >> > `--------------------------------------------------- >> > > > BTW, I get no error with the (more or less) current version of > org I'm using: > > Org-mode version 7.9.2 (release_7.9.2-582-g6d099e @ /home/nick/elisp/org-mode/lisp/) > > I just get the wrong answer: instead of evaluating on the remote, babel > evaluates it locallly. I also get this using 7.9.2-78-gf48a8b-elpa and Emacs 24.2.50.1. However, I then tested this on Emacs 23.1.1 with the following minimal .emacs: ,------------------------------------------------- | (add-to-list 'load-path "~/elisp/org-mode/lisp") | (require 'org-install) | | (org-babel-do-load-languages | 'org-babel-load-languages | '((emacs-lisp . nil) | (R . t) | (sh . t))) `------------------------------------------------- and got: ,-------------------------------------------------------------------------- | OVERVIEW | release_7.02 | Org-mode version 7.02 (release_7.02) | Quit | byte-code: Beginning of buffer [2 times] | Loading tramp...done | executing Sh code block... | Wrote /tmp/tramp.6477nIt | Tramp: Opening connection for loris@othercomputer using scp... | Tramp: Waiting 60s for local shell to come up... | Tramp: Sending command `ssh node003 -l loris -q -e none && exit || exit' | Tramp: Waiting for prompts from remote shell | Tramp: Found remote shell prompt on `node003' | Wrote /scp:loris@othercomputer:/tmp/tramp.64770Sz | Wrote /tmp/tramp.6477N7U.6477AxO | Wrote /tmp/scor6477a-m | apply: Wrong type argument: number-or-marker-p, "" `-------------------------------------------------------------------------- So there seem to be two problems, namely 1. Wrong type argument: number-or-marker-p, "", which only occurs in my minimal set-up post release_7.01h 2. No error, but local execution in the current version of Org. So before I can get started looking at 2, I need to sort out 1 The way I am testing is ,------------------------------------------------------------------ | git checkout release_7.02 | cd $HOME/elisp/org-mode && make clean | cd $HOME/elisp/org-mode && make | emacs -q -l /home/loris/.emacs_minimal /home/loris/tmp/test.org & `------------------------------------------------------------------ Is there something wrong with this? Cheers, Loris >> > I have had another go at bisecting this problem and came up with this: >> > >> > ,------------------------------------------------------------------------------------------------------------- >> > | 9c878a8290c071fbe5e97bc33c300ef2f07d6153 is the first bad commit >> > | commit 9c878a8290c071fbe5e97bc33c300ef2f07d6153 >> > | Author: Dan Davison >> > | Date: Mon Aug 30 09:34:05 2010 -0700 >> > | >> > | babel: Fix temporary file processing in the remote execution case. >> > | >> > | * ob.el (org-babel-temp-file): Don't use babel temporary >> > | directory in remote case; use make-temp-file with remote file >> > | name so that temp file is guaranteed not to exist previously >> > | on remote machine. >> > | (org-babel-tramp-localname): New function to return local name >> > | portion of possibly remote file specification >> > | >> > | * ob-R.el (org-babel-R-evaluate-external-process): Respond to >> > | changes in `org-babel-temp-file'; pass local file name to >> > | remote R process. >> > | (org-babel-R-evaluate-session) Respond to >> > | changes in `org-babel-temp-file'; pass local file name to >> > | remote R process. >> > | >> > | :040000 040000 b31e072cf6b2951e95b7956d907303e7a04a8cfd 5f794ada52cceb0614fe7962a399f7e549759003 M lisp >> > `------------------------------------------------------------------------------------------------------------- >> > >> > Does that help anyone any further? >> > >> >> I don't think so: afaict, both 7.01h (which did not contain this patch) >> and 7.02 (which did) do the right thing (at least with your simple >> script above). Something else broke it. >> > > I checked successive versions from 7.01h onwards and found breakage > between release_7.8 and release_7.9. So I bisected and came up > with this as the bad commit: > > ,---- > | commit 5cb80c7e5b9bcae180b799d2a49c78d529e029f0 > | Author: Eric Schulte > | Date: Mon Mar 12 13:23:53 2012 -0400 > | > | apply :shebang and :padline to shell script execution > | > | * lisp/ob-sh.el (org-babel-execute:sh): Pass all params to subroutine. > | (org-babel-sh-evaluate): Apply :shebang and :padline to shell script > | execution. > `---- > > Reverting it caused a merge conflict that I didn't have the patience to > resolve. But I made branches, one with this commit as its tip and one > with its predecessor: > > git checkout -b foo 5cb80c7 > git checkout -b bar de09874 > > Testing on foo gives me an error, testing on bar gives the correct > result. So I'm pretty sure this commit introduced the problem. Eric has > applied a partial fix since then which gets rid of the error but still > gives the wrong answer (not Eric's fault: he followed my suggestion, but > I was treating the symptom, not the disease). > > But I think this commit is the place that deserves more scrutiny. > > HTH, > Nick -- no sig is good sig