Re: [O] [BUG] remote execution in heterogeneous environment

2013-01-09 Thread Michael Albinus
Achim Gratz strom...@nexgo.de writes:

 Works a treat.  Please install!

I have no write access to the org repo. Maybe somebody else could install?

 Regards,
 Achim.

Best regards, Michael.



Re: [O] [BUG] remote execution in heterogeneous environment

2013-01-09 Thread Bastien
Hi Michael,

Michael Albinus michael.albi...@gmx.de writes:

 Achim Gratz strom...@nexgo.de writes:

 Works a treat.  Please install!

 I have no write access to the org repo. Maybe somebody else could
 install?

Please send me your public key so that I can give your write access.
Otherwise can you just resent the patch as a git patch with a commit
message have an Emacs-ready ChangeLog entry?

Thanks!

-- 
 Bastien



Re: [O] [BUG] remote execution in heterogeneous environment

2013-01-09 Thread Michael Albinus
Bastien b...@altern.org writes:

 Hi Michael,

Hi Bastien,

 Please send me your public key so that I can give your write access.
 Otherwise can you just resent the patch as a git patch with a commit
 message have an Emacs-ready ChangeLog entry?

I don't believe I need permanent write access. Patch appended.

 Thanks!

Best regards, Michael.

From a39b35c3967ac7c95e3442434a3ca44cba54fca5 Mon Sep 17 00:00:00 2001
From: Michael Albinus michael.albi...@gmx.de
Date: Wed, 9 Jan 2013 13:48:30 +0100
Subject: [PATCH] * ob-eval.el (org-babel-shell-command-on-region): Use
 `executable-find' for local `shell-file-name'

---
 lisp/ob-eval.el |   14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el
index 8764920..8018111 100644
--- a/lisp/ob-eval.el
+++ b/lisp/ob-eval.el
@@ -137,11 +137,17 @@ specifies the value of ERROR-BUFFER.
 		   t)))
   (let ((input-file (org-babel-temp-file input-))
 	(error-file (if error-buffer (org-babel-temp-file scor-) nil))
+	;; Unfortunately, `executable-find' does not support file name
+	;; handlers.  Therefore, we could use it in the local case
+	;; only.
 	(shell-file-name
-	 (if (file-executable-p
-	  (concat (file-remote-p default-directory) shell-file-name))
-	 shell-file-name
-	   /bin/sh))
+	 (cond ((and (not (file-remote-p default-directory))
+		 (executable-find shell-file-name))
+		shell-file-name)
+	   ((file-executable-p
+		 (concat (file-remote-p default-directory) shell-file-name))
+		shell-file-name)
+	   (/bin/sh)))
 	exit-status)
 ;; There is an error in `process-file' when `error-file' exists.
 ;; This is fixed in Emacs trunk as of 2012-12-21; let's use this
-- 
1.7.10.4



Re: [O] [BUG] remote execution in heterogeneous environment

2013-01-09 Thread Bastien
Hi Michael,

Michael Albinus michael.albi...@gmx.de writes:

 I don't believe I need permanent write access. Patch appended.

Applied, thanks!

Best,

-- 
 Bastien



Re: [O] [BUG] remote execution in heterogeneous environment

2013-01-08 Thread Michael Albinus
Achim Gratz strom...@nexgo.de writes:

 +  (let ((input-file (org-babel-temp-file input-))
 +(error-file (if error-buffer (org-babel-temp-file scor-) nil))
 +(shell-file-name
 + (if (file-executable-p
 +  (concat (file-remote-p default-directory) shell-file-name))
 + shell-file-name
 +   /bin/sh))

 The hard-coded /bin/sh breaks testing with NT-Emacs and using Cygwin as
 the backend because of the different path conventions in both
 environments.  This is a hack, but it works when setting SHELL=dash,
 note that there are no path components in there and even if your test
 would fail: NTEmacs knows nothing about Cygwin's path.  Can you please
 arrange that shell-file-name is used without alteration when the
 execution is local?  Even for remote execution hardcoding /bin/sh seems
 a bit heavy-handed to me…

What about this:

--8---cut here---start-8---
--- a/lisp/ob-eval.el
+++ b/lisp/ob-eval.el
@@ -137,11 +137,17 @@ specifies the value of ERROR-BUFFER.
   t)))
   (let ((input-file (org-babel-temp-file input-))
(error-file (if error-buffer (org-babel-temp-file scor-) nil))
+   ;; Unfortunately, `executable-find' does not support file name
+   ;; handlers.  Therefore, we could use it in the local case
+   ;; only.
(shell-file-name
-(if (file-executable-p
- (concat (file-remote-p default-directory) shell-file-name))
-shell-file-name
-  /bin/sh))
+(cond ((and (not (file-remote-p default-directory))
+(executable-find shell-file-name))
+   shell-file-name)
+  ((file-executable-p
+(concat (file-remote-p default-directory) shell-file-name))
+   shell-file-name)
+  (/bin/sh)))
exit-status)
 ;; There is an error in `process-file' when `error-file' exists.
 ;; This is fixed in Emacs trunk as of 2012-12-21; let's use this
--8---cut here---end---8---

The use of /bin/sh as fallback should be OK. In the local case, the
first cond clause shall be selected (otherwise there is something really
wrong). And for remote execution, /bin/sh should exist execept in case
of remote MS Windows or Android devices. Once you want run shells from
org there, we could even tweak this :-)

 Regards,
 Achim.

Best regards, Michael.



Re: [O] [BUG] remote execution in heterogeneous environment

2013-01-08 Thread Achim Gratz
Michael Albinus writes:
 What about this:
[...]

Looks good, I can test it tomorrow.

 The use of /bin/sh as fallback should be OK. In the local case, the
 first cond clause shall be selected (otherwise there is something really
 wrong).

Yes.  But on Windows there is always something wrong… :-)

 And for remote execution, /bin/sh should exist execept in case
 of remote MS Windows or Android devices. Once you want run shells from
 org there, we could even tweak this :-)

I was thinking towards being able to use a restricted shell.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] [BUG] remote execution in heterogeneous environment

2013-01-08 Thread Eric Schulte
Achim Gratz strom...@nexgo.de writes:

 Michael Albinus writes:
 What about this:
 [...]

 Looks good, I can test it tomorrow.

 The use of /bin/sh as fallback should be OK. In the local case, the
 first cond clause shall be selected (otherwise there is something really
 wrong).

 Yes.  But on Windows there is always something wrong… :-)

 And for remote execution, /bin/sh should exist execept in case
 of remote MS Windows or Android devices. Once you want run shells from
 org there, we could even tweak this :-)

 I was thinking towards being able to use a restricted shell.


I'm jumping in late here a without context, so forgive me if this
suggestion is not useful.

Do either the `org-babel-sh-command' or the :shebang header argument
affect this behavior?  If not should they, or should we add a new header
argument (say :remote-shell) to allow for customization of the choice of
shell for remote execution?

-- 
Eric Schulte
http://cs.unm.edu/~eschulte



Re: [O] [BUG] remote execution in heterogeneous environment

2013-01-08 Thread Michael Albinus
Achim Gratz strom...@nexgo.de writes:

 The use of /bin/sh as fallback should be OK. In the local case, the
 first cond clause shall be selected (otherwise there is something really
 wrong).

 Yes.  But on Windows there is always something wrong… :-)

Again: under Windows, on the local host, `shell-file-name' should do. For
the remote case you are right, but I doubt that any org user has ever
tried to run a remote Windows shell via Tramp.

 And for remote execution, /bin/sh should exist execept in case
 of remote MS Windows or Android devices. Once you want run shells from
 org there, we could even tweak this :-)

 I was thinking towards being able to use a restricted shell.

`shell-file-name' is your friend. /bin/sh is just the last resort. If
you dislike it, you could raise an error instead :-)

 Regards,
 Achim.

Best regards, Michael.



Re: [O] [BUG] remote execution in heterogeneous environment

2013-01-08 Thread Achim Gratz
Michael Albinus michael.albinus at gmx.de writes:
 What about this:

Works a treat.  Please install!


Regards,
Achim.






Re: [O] [BUG] remote execution in heterogeneous environment

2013-01-07 Thread Achim Gratz
Michael Albinus writes:
 +  (let ((input-file (org-babel-temp-file input-))
 + (error-file (if error-buffer (org-babel-temp-file scor-) nil))
 + (shell-file-name
 +  (if (file-executable-p
 +   (concat (file-remote-p default-directory) shell-file-name))
 +  shell-file-name
 +/bin/sh))

The hard-coded /bin/sh breaks testing with NT-Emacs and using Cygwin as
the backend because of the different path conventions in both
environments.  This is a hack, but it works when setting SHELL=dash,
note that there are no path components in there and even if your test
would fail: NTEmacs knows nothing about Cygwin's path.  Can you please
arrange that shell-file-name is used without alteration when the
execution is local?  Even for remote execution hardcoding /bin/sh seems
a bit heavy-handed to me…


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada