Re: [O] remote execution in heterogeneous environment
On Fri, Nov 30, 2012 at 1:22 PM, Michael Albinus wrote: > Neil Best writes: > >> tramp-version >> "2.2.3-24.1" >> >> emacs-version >> "24.2.1" >> >> Looks like I should upgrade tramp. I will look into that. > > Emacs 24.3 is in pretest, it contains Tramp 2.2.6. This might be another > option. See <http://thread.gmane.org/gmane.emacs.devel/155058>. > >> I think if I restart emacs it will be upgraded to some minor, minor >> release, so maybe that took care of it already. Fat chance? > > Sorry, this I don't understand ... > I had just recently upgraded Emacs through Macports but had not since restarted it, that's all. No such luck on the Tramp upgrade. I will just wait for the next release to propagate through Macports unless some intolerable behavior crops up. I do have a shiny new version of Org to play with thanks to ELPA. :) > > PS: it's on my wishlist for a long time to learn org-mode. Maybe I have > a chance now. You won't regret it. Have fun. What's your use case? How did you happen to get on this thread? Was there a cross-post that I missed? Thanks for pitching in, everyone.
Re: [O] remote execution in heterogeneous environment
Thanks for taking a look, Michael. On Fri, Nov 30, 2012 at 1:37 AM, Michael Albinus wrote: > Neil Best writes: >> >> #+BEGIN_SRC sh :dir /midway:~ echo "Executed by `whoami` on `hostname` >> in `pwd`" #+END_SRC >> > > Which version of Tramp are you using? You find it by "C-h v tramp-version". > I remember a problem with remote temporary directories, fixed in Tramp 2.2.6. > tramp-version "2.2.3-24.1" emacs-version "24.2.1" Looks like I should upgrade tramp. I will look into that. I think if I restart emacs it will be upgraded to some minor, minor release, so maybe that took care of it already. Fat chance? > Btw, I don't use org. For local tests, what shall I apply in order to > execute the code in #+BEGIN_SRC ... #+END_SRC? I should mention that my source code block got mangled when I tried to post through Gmane. It should look like this: #+BEGIN_SRC sh :dir /midway:~ echo "Executed by `whoami` on `hostname` in `pwd`" #+END_SRC Just go into Org mode, move the point within the block, and hit C-c C-c.
Re: [O] remote execution in heterogeneous environment
On Thu, Nov 29, 2012 at 1:25 PM, Nick Dokos wrote: > >> But your earlier mail says that it is trying to create the temp file on the >> remote >> >> , >> | > Tramp: Decoding region into remote file >> | > >> /ssh:midway:/var/folders/2y/qrw3hhkx0dlb9sbl51mjy5wmgn/T/sh-510999vN...done >> | > byte-code: Couldn't write region to >> | > >> `/ssh:midway:/var/folders/2y/qrw3hhkx0dlb9sbl51mjy5wmgn/T/sh-510999vN' >> ` >> >> Not sure what causes tramp to use /var/folders/2y for remote temp files >> but that seems to be the main problem here. >> > > If you evaluate > >(tramp-compat-temporary-file-directory) > > on your local system, what do you get? > > tramp may be assuming that whatever temp directory you are using > on your local system should work on the remote as well, an > assumption that's not true in your case. You may have to provide > your own function to get around this - or use /tmp just like the > rest of the world. > It's exactly as you suspected, Nick. That crazy /var/folders/... value was apparently hard-coded in the value of temporary-file-directory out of the box. That must be something that happens in Macports. When I changed it to "/tmp" things appear to work better: #+BEGIN_SRC sh :dir /midway:~ echo "Executed by `whoami` on `hostname` in `pwd`" #+END_SRC #+RESULTS: : Executed by nbest on lep in /Users/nbest The temp file problem was preventing any results from appearing, but now we see that the code is being executed locally, as suspected. There is a work-around for this, however: M-x ssh. #+BEGIN_SRC sh :session *ssh-midway* echo "Executed by `whoami` on `hostname` in `pwd`" #+END_SRC #+RESULTS: : Executed by nbest on midway-login1 in /pwd/from/that/session This opens up some possibilities but probably does not address the shortcomings detailed in the thread that Nick points to. The elisp hacking going on there is over my head so I will play with this some more and watch for updates.
Re: [O] remote execution in heterogeneous environment
On Thu, Nov 29, 2012 at 11:16 AM, Nick Dokos wrote: > It looks as if you are creating temp files under /var/folders/2y on the > remote: are you sure that a) the structure exists and b) permissions are > set correctly? > > Do you have the /var/folders/2y structure on the local host or only on > the remote? If only on the remote and the source block is running > locally (because of the funcall bug), that would sort-of explain this > behavior. > /var/folders/2y is peculiar to the local host, my Mac. I am pretty sure that this is a Mac (BSD?) idiom for temp files. /var on the remote is for root only and I have no influence over its permissions. By the way I have also tried this with ":session *ssh-midway*" in the header pointing to a session started with M-x ssh -- same results. In case more precision about my (org-version) is helpful: Org-mode version 7.9.2 (7.9.2-82-g2aeb28-elpa @ /Users/nbest/.emacs.d/elpa/org-20121112/)
[O] remote execution in heterogeneous environment
I run Macport's Emacs and ELPA's Org on my Mac but my data lives in a Red Hat environment. I thought I could edit locally and compute remotely but there seems to be a problem with temp files for executing source blocks. #+BEGIN_SRC sh :dir /midway:~ echo "Executed by `whoami` on `hostname` in `pwd`" #+END_SRC Results are empty and in the message buffers appears this: executing Sh code block... Tramp: Opening connection for midway using ssh... Opening connection for midway using ssh... \ Tramp: Opening connection for midway using ssh...done Tramp: Encoding region using function `base64-encode-region'...done Tramp: Decoding region into remote file /ssh:midway:/var/folders/2y/qrw3hhkx0dlb9sbl51mjy5wmgn/T/sh-510999vN...done byte-code: Couldn't write region to `/ssh:midway:/var/folders/2y/qrw3hhkx0dlb9sbl51mjy5wmgn/T/sh-510999vN', decode using `base64 -d -i >%s' failed I suspect this has something to do with how Emacs asks OSX for temp file names. Can anyone confirm this? Is there a work-around? Ultimately I want to inspect the environment where the remote execution is happening. We use a system called Modules [1] to customize $PATH, etc. When I try this: #+BEGIN_SRC sh :dir /midway:~ module list #+END_SRC I get "sh: line 1: module: command not found" which makes me think that the command is running on the local system where Modules is not installed. How does this square with the discussion at [2]? [1] http://modules.sourceforge.net/ [2] http://lists.gnu.org/archive/html/emacs-orgmode/2010-03/msg00071.html
Re: [O] source code disappears
When I switch to the ELPA version ( "Org-mode version 7.9.2 (7.9.2-82-g2aeb28-elpa @ . . . )") this misbehavior is corrected. HTH.
[O] source code disappears
Is anyone having trouble with source code disappearing when returning from the edit buffer? The #+BEGIN_SRC block is simply empty as far as I can tell, regardless of language. If I add some code to the block in the Org buffer before C-c ' then it also eats the contents. I am running Org-mode version 7.9.2 (release_7.9.2-499-ga29de0) under Emacs 24.2.1. I will be happy to provide more debug/trace information, but I'm not sure how to do that.
Re: [O] source code disappears
Is anyone having trouble with source code disappearing when returning from the edit buffer? The #+BEGIN_SRC block is simply empty as far as I can tell, regardless of language. If I add some code to the block in the Org buffer before C-c ' then it also eats the contents. I am running Org-mode version 7.9.2 (release_7.9.2-499-ga29de0) under Emacs 24.2.1. I will be happy to provide more debug/trace information, but I'm not sure how to do that.
Re: [O] source code disappears
When I switch to the ELPA version ( "Org-mode version 7.9.2 (7.9.2-82-g2aeb28-elpa @ . . . )") this misbehavior is corrected. HTH.
Re: [O] do sh source blocks ignore args? [7.8.09]
Org-mode version 7.8.09
How could this be?
I ran it in a separate, minimally configured Emacs and got the good
behavior, so org-version must be lying somehow or else not all of the
functions were redefined when I upgraded. I thought a reload
uncompiled would take care of this. I'll restart emacs and try it
again. Thanks for the sanity check.
On Thu, Apr 26, 2012 at 1:59 PM, Eric Schulte wrote:
> Neil Best writes:
>
>> Can sh source block take arguments? I get nothing.
>>
>> #+NAME: test(foo="bar")
>> #+BEGIN_SRC sh :session :results output verbatim replace
>> echo "1. foo is $foo"
>> echo "2. foo is ${foo}"
>> #+END_SRC
>>
>> #+RESULTS:
>> : 1. foo is
>> : 2. foo is
>>
>>
>> . . . but this is fine:
>>
>> #+NAME: test2
>> #+BEGIN_SRC sh :var foo="bar" :session :results output verbatim
>> replace
>> echo "1. foo is $foo"
>> echo "2. foo is ${foo}"
>> #+END_SRC
>>
>> #+RESULTS:
>> : 1. foo is bar
>> : 2. foo is bar
>>
>> When I tried this:
>>
>> #+CALL: test("baz")
>>
>> I get "reference 'test' not found in this buffer" -- what does this
>> mean? I got a similar message when I tried to define a simple call
>> using an R fragment that has a session associated with it. Evaluating
>> the code block with the default argument works fine, but a #+CALL:
>> construct fails. Maybe this is a separate issue.
>>
>> I trolled the web for relevant examples or reports but found none. My
>> setup is pretty much out-of-the-box. I am on Ubuntu Oneiric so sh is
>> a symlink to dash. I was not aware of dash until now so I don't know
>> what the implications of that are.
>>
>> This example may be overly trivial. My ultimate goal is to generate
>> shell scripts as function of the argument and tangle them out
>> something like this:
>>
>> #+BEGIN_SRC sh :tangle someArg.sh
>> <>
>> #+END_SRC
>>
>> So the results of the "function" will be lines of script code with
>> variables already interpolated using echo and a heredoc. Note that
>> test2 will not allow me to paramterize this, AFAIK. I'll have to
>> write each tangle block by hand but there's a small number of them.
>> If there is a more clever way I am certainly interested, but it seems
>> irrelevant until I understand what is happening above. Thanks. I am
>> very intrigued by LP possibilities using Org after messing with Sweave
>> for a year+, so please bear with me as I cut my teeth.
>>
>
> Hi Neil,
>
> Are you using the latest version of Org-mode? I ask because all of your
> examples work as expected on my system, specifically I get the
> following...
>
> Best,
>
> #+NAME: test(foo="bar")
> #+BEGIN_SRC sh :session :results output verbatim replace
> echo "1. foo is $foo"
> echo "2. foo is ${foo}"
> #+END_SRC
>
> #+RESULTS: test
> : 1. foo is bar
> : 2. foo is bar
>
> . . . but this is fine:
>
> #+NAME: test2
> #+BEGIN_SRC sh :var foo="bar" :session :results output verbatim
> replace
> echo "1. foo is $foo"
> echo "2. foo is ${foo}"
> #+END_SRC
>
> #+RESULTS: test2
> : 1. foo is bar
> : 2. foo is bar
>
> #+RESULTS:
> : 1. foo is bar
> : 2. foo is bar
>
> When I tried this:
>
> #+CALL: test("baz")
>
> #+RESULTS: test("baz")
> : 1. foo is baz
> : 2. foo is baz
>
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
[O] do sh source blocks ignore args? [7.8.09]
Can sh source block take arguments? I get nothing.
#+NAME: test(foo="bar")
#+BEGIN_SRC sh :session :results output verbatim replace
echo "1. foo is $foo"
echo "2. foo is ${foo}"
#+END_SRC
#+RESULTS:
: 1. foo is
: 2. foo is
. . . but this is fine:
#+NAME: test2
#+BEGIN_SRC sh :var foo="bar" :session :results output verbatim
replace
echo "1. foo is $foo"
echo "2. foo is ${foo}"
#+END_SRC
#+RESULTS:
: 1. foo is bar
: 2. foo is bar
When I tried this:
#+CALL: test("baz")
I get "reference 'test' not found in this buffer" -- what does this
mean? I got a similar message when I tried to define a simple call
using an R fragment that has a session associated with it. Evaluating
the code block with the default argument works fine, but a #+CALL:
construct fails. Maybe this is a separate issue.
I trolled the web for relevant examples or reports but found none. My
setup is pretty much out-of-the-box. I am on Ubuntu Oneiric so sh is
a symlink to dash. I was not aware of dash until now so I don't know
what the implications of that are.
This example may be overly trivial. My ultimate goal is to generate
shell scripts as function of the argument and tangle them out
something like this:
#+BEGIN_SRC sh :tangle someArg.sh
<>
#+END_SRC
So the results of the "function" will be lines of script code with
variables already interpolated using echo and a heredoc. Note that
test2 will not allow me to paramterize this, AFAIK. I'll have to
write each tangle block by hand but there's a small number of them.
If there is a more clever way I am certainly interested, but it seems
irrelevant until I understand what is happening above. Thanks. I am
very intrigued by LP possibilities using Org after messing with Sweave
for a year+, so please bear with me as I cut my teeth.
