David Bjergaard <david.b@duke.edu> writes:

> I know this is working "against the grain" of the literate programming
> paradigm where the document and the source code are coupled, and
> tangling the document produces a program that can be executed.  I'm just
> wondering if its possible.  If not that's fine.  Really I'm just trying
> to save myself a copy-paste (and the associated issues with it getting
> recorded in my .bash_history).

I usually come at it from the "reproducible research" angle which maybe
is more relaxed than literate programming.  In any case, I find it hard
to capture all the info needed to reproduce something and so I settle
for capturing as much as easily achievable - that is when I try at all
as capturing it in an RR org doc greatly increases the time I need to do
something.

Many of the software stacks I use also take significant time to
configure the end-user environment.  10 seconds is not unheard of and it
can be minutes if the stack lives on slow network disk.

I think the approach I suggested of caching the environment should work
for you.  Unfortunately, I do not know of a trivial, general way to do
this.  The "env" program comes close but does not spit out a format that
is immediately consumable by the shell.  In particular, spaces in
variable values confound it.  It also lacks the "export" keyword.  And,
in any case is only close to sh syntax.  Any exported functions also
have to be handled properly

In your shoes, I'd probably write a small Python script that dumps the
"os.environ" dictionary holding the environment of the caller into a
form suitable for consumption by your shell.  You can call this dumper
in a shell code block at the top of your org file and source the result
as the first line in each subsequent shell code block.

A starting point would be something like the following, but this does
not properly handle and sh functions defined.

#!/usr/bin/env python
import os
for k,v in os.environ.items():
    print 'export %s="%s"' % (k,v)



Good luck!
-Brett.