Alan,
Thanks for fighting for *nix folks.
Although I can solve my singular problem using the solution posted by
Stephen, you reminded me of another reason I wrote my question as I
did.
Although I'm not involved, I understand that people continue to work
on the Mono project which provides the CLR for *nix environments. I
know that the IronPython community has worked to ensure that its
products work not only on a native Windows environment, but also in a
Mono environment.
On Aug 17, 8:48 am, Alan D. Salewski salew...@att.net wrote:
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
