On Thu, Aug 18, 2011 at 01:39:21AM -0400, Ken Wesson spake thus:
> On Thu, Aug 18, 2011 at 12:32 AM, Alan D. Salewski <salew...@att.net> wrote:
> > On Wed, Aug 17, 2011 at 01:47:53PM -0400, Ken Wesson spake thus:
> >> On Wed, Aug 17, 2011 at 9:48 AM, Alan D. Salewski <salew...@att.net> wrote:
> >> > I approached the question from the perspective of one wanting to invoke
> >> > Clojure-CLR with the ability to manipulate the value of
> >> > 'clojure.class.path' "on-the-fly" in a way that is common and natural
> >> > for *nix folks.
> >>
> >> And with 'env' it clearly is possible to manipulate the value on the
> >> fly, as Stephen pointed out three hours before your post and as you
> >> yourself have demonstrated.
> >
> > Aside from the matter that using 'env' is clunky for common command line
> > usage, it is /not/ possible manipulate the value on the fly, generally.
>
> There is no in-principle difference between using 'set' and using
> 'env'. It's just a different three letters here and there in your
> script.
Sure there is. I use 'set' to show behavior related to querying the
environment of the current process. I use 'env' to show behavior related
to querying the environment of a child process (and separately as a tool
for setting up such environments, obviously):
$ echo $BASH_VERSION
4.1.5(1)-release
$ env -- dot.name=blah /bin/bash # create subshell
$ set | grep dot # query current env of "this"
subshell, using builtin 'set' command; no output, but it's there...
$ env | grep dot # query env of child of "this"
subshell; ah, there it is.
dot.name=blah
> > There are at least three common scenarios to consider:
> >
> > 1. Inovking the Clojure-CLR from bash w/o setting or modifying
> > 'clojure.load.path'.
>
> Just run it.
Yep, that's what I said.
> > 2. Invoking the Clojure-CLR from bash, supplying an explicit value
> > for 'clojure.run.path' not based on the existing value, if any.
> >
> > 3. Invoking the Clojure-CLR from bash, augmenting the existing value
> > of 'clojure.run.path' with an explicit value.
>
> Use a script that wraps the invocation in a save and set, then a
> restore, of clojure.run.path; or spawn a subsidiary shell with its own
> copy of the environment with a short script that sets the environment
> variable and then runs Clojure-CLR, "popping" the environment changes
> on exit.
>
> > Scenario 3 cannot be addressed by 'env' because it requires manipulation
> > of the existing value of the variable.
>
> You aren't honestly claiming that there is no way to extract the value
> into a bash shell variable, are you?
No, I claimed that you cannot access the envrionment variable by name in
the current process to extract it's value (for the purpose of augmenting
that value while setting up the environment of a subprocess, in the
example I used).
> Not after you yourself posted
> this snippet earlier:
>
> $ /usr/bin/env -- ALJUNK_CRAP1=junk1 ALJUNK.CRAP2=junk2 /bin/bash -c
> env | grep ALJU
> ALJUNK.CRAP2=junk2
> ALJUNK_CRAP1=junk1
>
> So, env | grep clojure.class.path | sed <sed code to extract what's
> after the = goes here> | whatever
>
> and you can grab the existing value and compute something from it.
>
> Couldn't be simpler.
That's ridiculous; there's nothing simple about it. It requires
launching a subprocess simply to query it's environment to extract a
value to use while setting up the environment of the subprocess that is
to receive the value:
$ /usr/bin/env -- "clojure.load.path=/my/new/value$(env|sed -n
'/^clojure\.load\.path=\(.*\)$/ s//:\1/p')" /bin/bash
It's exceedingly useful that such things can be scripted, but that's a
clunky way to accomplish something that is more directly and efficiently
accomplished in other well established ways. It violates the *nix user's
expectation about how such things can be accomplished, and prevents
folks from invoking Clojure-CLR in the way they invoke every other tool
they've launched from a *nix shell since the epoch. And it won't work
with all shells[0] because propagation down through subprocesses cannot
be relied upon. From the perspective of a *nix shell user, it's neither
simple nor elegant.
The OP didn't ask if it was possible to hack around use of an
environment variable whose name is not a valid POSIX shell identifier.
He asked, "How do we plan to support an alternative name..." I think
it's reasonable to think such a thing would be generally desirable, and
that it is also reasonable to expect that the solution would take a form
similar to existing tools.
With that said, I also think a valid answer is, "There are currently no
plans to support that use case, but if you'd like to see it happen,
patches are welcome. In the meantime, maybe you can use the hacks in
this thread to get by."
-Al
[0] ksh, for example:
$ /usr/bin/env -- "clojure.load.path=/the/os/default" /bin/ksh
$ /usr/bin/env | grep clojure.load.path # no output; var did not
propagate
--
-----------------------------------------------------------------
a l a n d. s a l e w s k i salew...@att.net
1024D/FA2C3588 EDFA 195F EDF1 0933 1002 6396 7C92 5CB3 FA2C 3588
-----------------------------------------------------------------
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
