Hi,

First off, my =org-mode= is up-to-date - just did a =git pull && make clean
&& make=.  Needless to say, the following were an issue before then...

* Question 1:
Is there a way to force, upon export, an =emacs-lisp= session to be run
within the current buffer?  For instance, the following code

===============================================================
#+begin_src emacs-lisp :exports
both
 (buffer-file-name)

#+end_src
===============================================================

exports to LaTeX as

===============================================================
\begin{verbatim}

(buffer-file-name)

\end{verbatim}




===============================================================

In other words, as far as I can tell, the code is passed to the interpreter,
which does not know about the current buffer information, and therefore the
result of the =emacs-lisp= code is an empty string.  By contrast, if I use
=C-c C-c= to evaluate the code block, then I get the proper result printed
in the =.org= buffer:

===============================================================
#+results:

: /home/cmalone/org_tests/python_class_lstings.org
===============================================================

Ultimately, I'd like to, upon export, have a =emacs-lisp= code block that
does a regexp search on the file and returns a list of matches, which can
then be placed in a =latex= code block.  This sort of action suffers from
the same issue as the =(buffer-file-name)= code - in essence this is a
minimal (non)working example.

* Question 2:
Why does the following code, upon export, ask if I want to evaluate the
=emacs-lisp= code *TWICE* and then give a /Invalid read syntax: "#"/ error
in the message window?:

===============================================================
#+begin_src emacs-lisp :exports
both
 (buffer-file-name)

#+end_src



#+begin_src sh :exports
both
  ls
-l
#+end_src
===============================================================

Note that this works fine as long as the =:exports= tag for the =emacs-lisp=
code block is *NOT* =both= or =results=.  Also note that the value of the
=:exports= tag on the =sh= code block is irelevant for this error to
appear.  Also, it doesn't have to be this particular combination of
=emacs-lisp= and =sh= blocks; for instance it fails with an =emacs-lisp= and
a =python= source block.

Is this a bug?

Chris