On Tue, Aug 16, 2011 at 01:23:23PM -0400, Ken Wesson spake thus:
> On Tue, Aug 16, 2011 at 1:20 AM, Alan D. Salewski <salew...@att.net> wrote:
> > On Tue, Aug 16, 2011 at 12:34:39AM -0400, Ken Wesson spake thus:
> >> On Mon, Aug 15, 2011 at 11:13 AM, mrwizard82d1 <mrwizard8...@gmail.com>
> >> wrote:
> >> > I understand that the 1.3 beta plans to add an environment variable
> >> > named clojure.load.path to provide a "CLASSPATH" mechanism for Clojure
> >> > on the CLR.
> >> >
> >> > Although I use Windows, I have installed cygwin because I prefer the
> >> > Unix tool set to that provided by Windows. Although a Windows console
> >> > allows one to set environment variables like "clojure.load.path," the
> >> > bash shell does not.
> >>
> >> Are you sure there isn't some form of quoting or escaping that will
> >> make that name acceptable to bash?
> >
> > Identifiers in bash may contain only alphanumeric characters and
> > underscores, and must start with an alphabetic character or underscore;
> > there's no way to get around that with escaping or quoting.
>
> Pardon me, but that seems to be missing the point.
Your point, to which I was responding, was that there might be "some
form of quoting or esacaping" that would make the environment variable
with the name 'clojure.load.path' "acceptable to bash". My point,
offered only to help avoid wasting time going down that path of
investigation, is that there is not, with the implied reason that
environment variable manipulation in bash can only be performed on
environment variables that are valid bash identifiers.
Based on your addions below, it is now clear that you are only talking
about the ability of bash to "pass through" to its children an
environment variable that it was provided by it's parent process. I
would describe that level of capability as "tolerance", not "acceptance".
It is the default behavior of bash 4.1 and newer for environment
variables received from the parent process that are not valid bash
identifiers: they are "passed through" to the environment of child
processes, despite the fact that they have not been (and cannot be)
explicitly exported. Tolerance.
Acceptance, in my view, would include the ability to query the current
environment for the value, and the ability to manipulate the value seen
by subprocesses using the common approach on a per-invocation basis:
$ SOMEVAR=SOMEVAL /path/to/command [arg[ arg...]]
without resorting to 'env' or other hacks, which is not the case:
$ ALJUNK_CRAP=junk /bin/bash -c set | grep ALJU
ALJUNK_CRAP=junk
$ ALJUNK.CRAP=junk /bin/bash -c set | grep ALJU
bash: ALJUNK.CRAP=junk: command not found
$ /usr/bin/env -- ALJUNK_CRAP1=junk1 ALJUNK.CRAP2=junk2 /bin/bash -c env |
grep ALJU
ALJUNK.CRAP2=junk2
ALJUNK_CRAP1=junk1
$ /usr/bin/env -- ALJUNK_CRAP1=junk1 ALJUNK.CRAP2=junk2 /bin/bash -c set |
grep ALJU
ALJUNK_CRAP1=junk1
> You don't need a
> bash-language variable named "clojure.load.path", you just need to set
> a Windows environment variable named "clojure.load.path", and the
> rules for what characters are allowed in the names of Windows
> environment variables will still be those set by Windows, which
> apparently permit periods. As far as your bash script is concerned,
> "clojure.load.path" probably needn't be anything more than an opaque
> string passed to the host operating system via a call of some kind --
> though that string could conceivably require quoting or escaping where
> it's embedded as a literal in the script.
>
> If bash has its own environment variable system, then that could be
> confusing you,
The only confusion is that you and I read differently mrwizard82d1's
question, which set the tone for the thread:
"How do we plan to support an alternative name that can be used by
people running Clojure-CLR from within cygwin?"
You approached the question from the perspective of one just wanting to
launch Clojure-CLR with a 'clojure.class.path' value inherited from the
host OS, however that can be made to work.
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.
The answer at the moment (as with many things related to cygwin) seems
to be that basic usage will "just work"; other usage will be possible
but more cumbersome.
-Al
%!PS Unix and Linux allow periods to be used in environment variable
names, too. Whether it's a good idea to actually use a variable
name that cannot be manipulated as a valid POSIX shell identifier
is a matter for a debate I do not wish to get into.
> but then even if you succeeded it wouldn't work; the
> Clojure tools won't see bash's internal system, only the host OS's, so
> it's the host OS environment variables you need to get at regardless.
--
-----------------------------------------------------------------
a l a n d. s a l e w s k i salew...@worldnet.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
