Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
mrwizard82d1
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.
How do we plan to support an alternative name that can be used by
people running Clojure-CLR from within cygwin?
Thanks.
Have a great day!
Ken Wesson
> 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?
Failing that, can you invoke Windows's setenv from within bash? If
it's a .com or .exe it should be possible but if it's a cmd.exe
builtin command like dir you'd probably be SOL. (You can invoke
cmd.exe with a command to execute, but I expect if that command is
setenv the environment change will be popped when cmd.exe exits.)
Failing that, too, you could resort to cobbling together your own
setenv.exe using Windows APIs and gcc to invoke from your launch
script.
--
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.
Alan D. Salewski
> On Mon, Aug 15, 2011 at 11:13 AM, mrwizard82d1 <mrwiza...@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.
-Al
--
-----------------------------------------------------------------
a l a n d. s a l e w s k i sale...@att.net
1024D/FA2C3588 EDFA 195F EDF1 0933 1002 6396 7C92 5CB3 FA2C 3588
-----------------------------------------------------------------
Ken Wesson
> On Tue, Aug 16, 2011 at 12:34:39AM -0400, Ken Wesson spake thus:
>> On Mon, Aug 15, 2011 at 11:13 AM, mrwizard82d1 <mrwiza...@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. 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, 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.
Stephen Compall
$ clojure.load.path=whatever command
Some error message I forget
$ env clojure.load.path=whatever command
Sets env var while running command
You should already have env installed. It's pretty useful if you like working in sh; check out its manpage for more.
Alan D. Salewski
> On Tue, Aug 16, 2011 at 1:20 AM, Alan D. Salewski <sale...@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 <mrwiza...@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 sale...@worldnet.att.net
mrwizard82d1
Although I was aware of the env command, I had never needed it before.
I believe this solution will allow me to solve my immediate problem
(running Clojure-CLR with the classpath configured for a specific
project as I do in Java).
mrwizard82d1
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:
Ken Wesson
> $ /usr/bin/env -- ALJUNK_CRAP1=junk1 ALJUNK.CRAP2=junk2 /bin/bash -c env | grep ALJU
> ALJUNK.CRAP2=junk2
> ALJUNK_CRAP1=junk1
>
> 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.
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.
The OP's problem has been solved; let's move on.
Alan D. Salewski
> On Wed, Aug 17, 2011 at 9:48 AM, Alan D. Salewski <sale...@att.net> wrote:
> > � �$ /usr/bin/env -- ALJUNK_CRAP1=junk1 ALJUNK.CRAP2=junk2 /bin/bash -c env | grep ALJU
> > � �ALJUNK.CRAP2=junk2
> > � �ALJUNK_CRAP1=junk1
> >
> > 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.
>
> 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 are at least three common scenarios to consider:
1. Inovking the Clojure-CLR from bash w/o setting or modifying
'clojure.load.path'.
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.
Scenario 1 is the simplest case. As we've said, it can be addressed by
using a new enough version of bash; it will "just work", and there is no
need to use 'env' or anything else. (This does not address the issue for
users who use shells other than bash on cygwin or its ilk, but let's
ignore that for now.)
Scenario 2 can be addressed by 'env' (as we've seen) or similar.
Scenario 3 cannot be addressed by 'env' because it requires manipulation
of the existing value of the variable. Consider:
$ unset PATH
/usr/bin/env -- "PATH=/my/new/value${PATH+:}${PATH}" /bin/bash -c /usr/bin/env | /usr/bin/grep '^PATH='
/my/new/value
$ export PATH=/usr/bin
/usr/bin/env -- "PATH=/my/new/value${PATH+:}${PATH}" /bin/bash -c /usr/bin/env | /usr/bin/grep '^PATH='
PATH=/my/new/value:/usr/bin
Compare that with:
$ /usr/bin/env -- "clojure.load.path=/the/os/default" /bin/bash
$ /usr/bin/env | grep clojure
clojure.load.path=/the/os/default
$ /usr/bin/env -- "clojure.load.path=/my/new/value${clojure.load.path+:}${clojure.load.path}" /bin/bash
bash: clojure.load.path=/my/new/value${clojure.load.path+:}${clojure.load.path}: bad substitution
Can that be addressed by supplying a special purpose tool to accomplish
the task? Sure.
Is there a good reason to require such a thing? Maybe; I don't pretend to
know.
> The OP's problem has been solved;
...as he pointed out, for a limited definition of "solved".
> let's move on.
Agreed.
Respectfully,
-Al
--
-----------------------------------------------------------------
a l a n d. s a l e w s k i sale...@att.net
Ken Wesson
> 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 <sale...@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.
> 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.
> 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? 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.
Alan D. Salewski
> On Thu, Aug 18, 2011 at 12:32 AM, Alan D. Salewski <sale...@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 <sale...@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
Dimitre Liotev
>> 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.
>
> The OP's problem has been solved; let's move on.
In my opinion using a variable name that is not supported in Bash would
create some problems:
- most Linux (and probably Mac) users use the Bash shell. The 'env'
command can pass a variable that is not Bash compliant to a
process, but you can not set and query such a variable in a Bash
script. This is very likely to cause some frustration and time
wasting for people using Clojure and Bash together.
- A name like clojure.load.path breaks a widely accepted convention:
environment variable names usually consist of capital letters and
underscores. So we have MAVEN_HOME, JAVA_HOME, ANT_HOME, etc. When
I see a name like clojure.load.path my first thought would be that
this is a Java system property, not an environment variable.
I think that it would be wise to stick to the convention and use
variable names that are Bash compliant. I would use CLOJURE_LOAD_PATH
for an environment variable name and clojure.load.path for a Java system
property name.
--
Dimitre Liotev
Ken Wesson
> you can not set and query such a variable in a Bash script.
Code has already been posted to this thread that does exactly that.
D L
>
> On Wed, Aug 17, 2011 at 4:25 PM, Dimitre Liotev <lio...@gmail.com> wrote:
> > you can not set and query such a variable in a Bash script.
>
> Code has already been posted to this thread that does exactly that.
Let me rephrase this for you: you can not set and query such a
variable in the standard,
conventional, predictable Bash way. This is what matters. No point in
devising ways to
torture users by forcing them to use ugly hacks for something as basic
and simple as
setting a variable.
--
Dimitre Liotev
Ken Wesson
But the standard way of "setting a variable" in bash would presumably
not, in a Windows port of bash, affect the environment as seen by
native programs anyway, since clearly bash has a different idea of
what an environment variable is, how it can be named, and so on than
Windows does, and so seems to necessarily have a different environment
than Windows's.
Then, no matter what it's named, if a Windows application uses a
Windows environment variable it will be more awkward to manipulate
from a Windows port of bash than an emulated native unix environment
variable, and likewise more awkward than a true native unix
environment variable manipulated on a unix machine and used by a
native unix application.
But this is all entirely beside the point:
1. The OP just wanted to *set* the variable and call Clojure-CLR. That
problem is solved. A claim was mooted that it was unsolvable without
renaming the variable, and that claim was decisively proved wrong.
2. Subsequently, a claim was mooted that though it was admittedly
possible to *set* the variable it would not be *possible* to read it,
and thus to set it to a function of its prior value -- and THAT claim
was decisively proved wrong.
3. So now you admit that it IS possible, but instead of leaving it at
that, you just change your objection -- AGAIN -- this time to say that
it's *too inconvenient*.
4. On top of all of this goalpost-moving by what seems to be either a
Sybil attack or a tag-team of opponents ganging up on me, there's the
minor little matter of the fundamentally questionable assumption they
(you) are making, which is that developers of native Windows
applications should be adhering to Unix naming conventions for the
convenience of that tiny fraction of Windows users that use a port of
bash to Windows as their command shell instead of using native tools
such as cmd and Explorer! Taken to its logical extreme, such a
position is probably untenable, as it's likely that if you intersected
the subsets of names and other practices that would be allowed and
convenient for all operating systems you'd wind up with the empty set
and become paralyzed into inaction. :) "You can't please all of the
people all of the time", and apparently the same goes for operating
systems. It's generally regarded as acceptable for Windows-native
applications to adhere to Windows conventions, unix-native ones to
unix conventions, and so forth; and here we have a Windows-native
application with an environment variable name that lies within the
realm Windows allows to manipulate conveniently, but happens to be
awkward to deal with in unix. I'd say that that's too bad for the unix
user affected by it, but not a foul by the Windows community, and it's
not even the biggest unix/Windows impedance mismatch out there -- how
about cr/lf vs. lf? Space-ridden case-insensitive file names that need
to be quoted to move to unix, and cause collisions sometimes moving
the other way? Name collisions are certainly a larger inconvenience
than having to -- my God! -- use sed a little bit. :)
dmiller
(a) 'clojure.load.path' is not new in 1.3. It's been in the code
since at least May, 2009.
(b) Regarding Dimitre's comment below, I probably did have Java system
properties on my mind at the time. I guarantee that I was not
thinking of picking Bash-compliant names. I doubt that I gave it much
thought at all.
(c) It could be changed to something like CLOJURE_LOAD_PATH instead.
Would that cause a problem for anyone?
-David
Ken Wesson
> Several comments:
>
> (a) 'clojure.load.path' is not new in 1.3. It's been in the code
> since at least May, 2009.
> (b) Regarding Dimitre's comment below, I probably did have Java system
> properties on my mind at the time. I guarantee that I was not
> thinking of picking Bash-compliant names. I doubt that I gave it much
> thought at all.
> (c) It could be changed to something like CLOJURE_LOAD_PATH instead.
> Would that cause a problem for anyone?
Just the ones that want to have something to gripe about. :)
And, maybe, the ones who have to go and reconfigure everything when
they upgrade ...
dmiller
existence.
Alan D. Salewski
> Several comments:
>
> (c) It could be changed to something like CLOJURE_LOAD_PATH instead.
> Would that cause a problem for anyone?
>
> -David
+1
-Al
--
-----------------------------------------------------------------
a l a n d. s a l e w s k i sale...@att.net
Alan D. Salewski
> I would be concerned about this group, if there was any evidence of
> existence.
Same here, but even with such evidence I would not be so concerned that
I would not make the change.
This calls to mind Stuart Feldman's explanation as to the reason
Makefile syntax today still requires leading <TAB> characters in
recipies, as documented by Eric Raymond in
_The_Art_of_Unix_Programming_, Section 15.4.1[0]:
<quote>
No discussion of make(1) would be complete without an
acknowledgement that it includes one of the worst design botches in
the history of Unix. The use of tab characters as a required leader
for command lines associated with a production means that the
interpretation of a makefile can change drastically on the basis of
invisible differences in whitespace.
Why the tab in column 1? Yacc was new, Lex was brand new. I
hadn't tried either, so I figured this would be a good excuse to
learn. After getting myself snarled up with my first stab at
Lex, I just did something simple with the pattern newline-tab.
It worked, it stayed. And then a few weeks later I had a user
population of about a dozen, most of them friends, and I didn't
want to screw up my embedded base. The rest, sadly, is history.
-- Stuart Feldman
</quote>
[0] http://www.faqs.org/docs/artu/ch15s04.html
That's on page 358 of my dead tree edition.
ISBN: 0-13-142901-9
--
-----------------------------------------------------------------
a l a n d. s a l e w s k i sale...@att.net
Alan D. Salewski
> On Thu, Aug 18, 2011 at 4:56 PM, D L <lio...@gmail.com> wrote:
> > On Thu, Aug 18, 2011 at 7:34 PM, Ken Wesson <kwes...@gmail.com> wrote:
> >>
> >> On Wed, Aug 17, 2011 at 4:25 PM, Dimitre Liotev <lio...@gmail.com> wrote:
> >> > � � �you can not set and query such a variable in a Bash�script.
> >>
> >> Code has already been posted to this thread that does exactly that.
> >
> > Let me rephrase this for you: you can not set and query such a
> > variable in the standard,
> > conventional, predictable Bash way. This is what matters. No point in
> > devising ways to
> > torture users by forcing them to use ugly hacks for something as basic
> > and simple as
> > setting a variable.
>
> But the standard way of "setting a variable" in bash would presumably
> not, in a Windows port of bash, affect the environment as seen by
> native programs anyway,
That presumption is at least partially incorrect. Native apps (cmd.exe,
for instance) launched from a cygwin bash command prompt can "see"
environment variables exported by the parent bash process.
/cygdrive/c$ type -a cmd.exe
cmd.exe is /cygdrive/c/Windows/system32/cmd.exe
/cygdrive/c$ unset CRAP
/cygdrive/c$ CRAP=junk cmd.exe
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\>set CRAP
set CRAP
CRAP=junk
C:\>exit
exit
/cygdrive/c$
> since clearly bash has a different idea of
> what an environment variable is,
Nope; they're just key/value pairs available to the process.
> how it can be named,
Yep, if it is to be manipulated directly (queried, set, or exported in
the current process).
> and so on than
> Windows does, and so seems to necessarily have a different environment
> than Windows's.
Each bash process, in fact, will have it's own environment, which will
have been provided by its parent process. Any Unix look-a-like thing
running on Windows will need to present a view of a process-specific
environment to the *nix-style tools in a way they are prepared to handle
(PATH values will be translated, and similar), and the environment
constructed for native Windows programs launched by those *nix-style
tools should ideally see the values in a way they would expect (at least
for important, well-known vars, such as PATH). And this is how things do
work with cygwin, from the vantage point of the apps.
> Then,
(building on sand...)
> no matter what it's named, if a Windows application uses a
> Windows environment variable it will be more awkward to manipulate
> from a Windows port of bash than an emulated native unix environment
> variable, and likewise more awkward than a true native unix
> environment variable manipulated on a unix machine and used by a
> native unix application.
Not necessarily true. I noted earlier that Unix and Linux are both
permissive in the names allowed for environment variables; nevertheless,
in *nix there's a tradition of following established conventions unless
there is a good reason not to. Naming environment variables such that
they can be manipulated as POSIX shell identifiers is just one example
of following a useful convention:
/cygdrive/c$ PATH=/cygdrive/c/tmp /cygdrive/c/Windows/system32/cmd.exe
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\>set PATH
PATH=C:\tmp
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
C:\>exit
exit
/cygdrive/c$
No good reasons have yet been posited on this thread to use an
environment variable named to be incompatible with that established
convention, regardless of what is permissible by the host OS.
> But this is all entirely beside the point:
Hey, we agree on something!
:-)
> 1. The OP just wanted to *set* the variable and call Clojure-CLR. That
> problem is solved.
That's not an accurate representation of what the OP wanted, as
clarification by him on this thread beyond the original post makes
clear. Perhaps it was understandable why you might have thought that
based on the original post, but not at this point in the thread. If that
were satisfactory to the OP and other folks who have chimed in since,
then we could have dropped this whole thing a while ago.
> A claim was mooted that it was unsolvable without
> renaming the variable, and that claim was decisively proved wrong.
That's not true, either; if you think that it is, please go back and
re-read the thread. Claims were made that the environment variable would
not be accessed and manipulated in the current bash process, and that
claim was decisively proved true[0].
That is an argument in favor of renaming the variable, but it is not the
same as saying that that limited problem (of explicitly setting a value
for 'clojure.load.path' for a subprocess) is unsolvable without renaming
the variable.
The possibility of using 'env' for setting up an environment for
Clojure-CLR subprocesses has never been in dispute on this thread.
Folks have been chiming in to point out that it is not a good idea to
require users to create a subprocess, query the environment of that
subprocess for the value of an environment variable that can be neither
seen nor referenced in the current bash process, and then augment the
value found to set up the environment for a separate subprocess. That is
what you were arguing for when defending the 'env'-based approach.
> 2. Subsequently, a claim was mooted that though it was admittedly
> possible to *set* the variable it would not be *possible* to read it,
> and thus to set it to a function of its prior value -- and THAT claim
> was decisively proved wrong.
False again; please re-read the thread. It was proved decisively that
one cannot set the variable in the current process, nor reference the
variable from the current process. If you believe that the 'env'
examples demonstrate otherwise, then you are insufficiently informed
about the service that 'env' provides when invoked without any command
line options.
> 3. So now you admit that it IS possible,
(By "you", I'm presuming you mean something like "you guys", and are
therefore treating all arguments contradicting your own as a whole; or
you really believe that nonsense below about a Sybil attack. For the
moment, I choose to believe the former.)
Nope; wrong again. Only the following two things have been demonstrated
to be possible in regard to setting 'clojure.load.path' in the
environment of the Clojure-CLR subprocess:
1. Explicitly setting the value using 'env' with a value not
directly derived from the value of the environment variable of
the same name in the current bash process. Again, nobody has
disputed that this would work; indeed, this was the workaround
suggested early on by Stephen Compall that solved mrwizard82d1's
/immediate/ problem.
2. Explicitly setting the value using 'env' with a value derived
from the value of the envionment variable of the same name in a
subprocess 'env' process, to be provided (perhaps augmented) in
a separate subprocess of the bash shell. This is where the
dispute lies: you argued that this is sufficient to solve the
problem; nobody on this thread has yet agreed.
> but instead of leaving it at
> that, you just change your objection -- AGAIN --
That, too, is not true.
The differences between the way you and I approached the OP's question
were crystalized early on -- with you concerned only with the limited
problem, and myself concerned with that plus the wider usability issues
suggested by the OP; contributions since then by myself and others have
provided clarifications to help you see what you refused to see. If you
think new objections were introduced later in the thread, it is only
because you chose not to recognize them at that early stage.
To the extent to which you put forth multiple specific ideas with which
to object, you ought not be surprised that you received multiple
objections.
> this time to say that
> it's *too inconvenient*.
*yawn*
Please re-read my "acceptance" vs. "tolerance" post (my second in this
thread). No objections have been introduced since that clarification
between your approach and everyone who has objected to your approach.
> 4. On top of all of this goalpost-moving
That simply has not happened.
> by what seems to be either a
> Sybil attack or a tag-team of opponents ganging up on me,
It's gotta be one or the other; both are more likely than the
possibility that more than a single person on the Internet would
honestly disagree with something you said.
Please.
> there's the
> minor little matter of the fundamentally questionable assumption they
> (you)
Ha!
> are making, which is that developers of native Windows
> applications should be adhering to Unix naming conventions
> for the > convenience of that tiny fraction of Windows users that use a port of
> bash to Windows as their command shell instead of using native tools
> such as cmd and Explorer!
In the absense of widely used conventions in the host environment, it is
not a bad practice to adhere to well established conventions established
elsewhere, if only in recognition that those conventions came about
because they were useful in some way, and provided benefits to the
community that established them. If there's a competing convention on
Windows (or any other OS), I'm not aware of it, and it certainly hasn't
been mentioned here.
In the absence of a competing convention and an entrenched user base,
arguing to /not/ change 'clojure.load.path' to something that can be
manipulated as a valid POSIX shell identifier (without compensating
rationale) is arguing for a point of arbitrary incompatibility.
> Taken to its logical extreme, such a
> position is probably untenable, as it's likely that if you intersected
> the subsets of names and other practices that would be allowed and
> convenient for all operating systems you'd wind up with the empty set
> and become paralyzed into inaction. :)
Nah, you'd end up with something that looks like Java, with some systems
programming bits thrown in.
> "You can't please all of the
> people all of the time", and apparently the same goes for operating
> systems. It's generally regarded as acceptable for Windows-native
> applications to adhere to Windows conventions, unix-native ones to
> unix conventions, and so forth;
I don't disagree with that, generally. But the fact of the matter is
that *nix has more established conventions, and in those places where
such conventions are absent in Windows (or any other platform) it would
be instructive to understand the conventions of the *nix folks and the
underlying rationales. Even if the *nix conventions are not used, they
should be departed from for reasons better than laziness or arbitrary
incompatibility.
> and here we have a Windows-native
> application
CLR is not the same as Windows-native...
> with an environment variable name that lies within the
> realm Windows allows to manipulate conveniently, but happens to be
> awkward to deal with in unix.
...and even if it were, multiple folks have expressed an interest in
using it in cygwin or similar. "Happens to be" in this case is
equivalent with "inadvertently, but correctable", as David has indicated
that the name can be changed.
> I'd say that that's too bad for the unix
> user affected by it,
Why?
For the foreseeable future, there will be portability issues between
different programs on different OS's, and on different runtimes on a
single OS. If the incompatibility is not arbitrary, then so be it; but
what does anybody gain by arbitrary incompatibility?
> but not a foul by the Windows community,
Nobody suggested that; there has simply been no rationale provided why
the existing name of 'clojure.load.path' is better than a name that is a
valid POSIX shell identifier.
> and it's
> not even the biggest unix/Windows impedance mismatch out there
No, but it was arbitrary. And demonstrably problematic. And easily
fixable.
> -- how
> about cr/lf vs. lf? Space-ridden case-insensitive file names that need
> to be quoted to move to unix, and cause collisions sometimes moving
> the other way?
No need to get into all of that...
> Name collisions are certainly a larger inconvenience
> than having to -- my God! -- use sed a little bit. :)
Like many *nix folks, I happen to be a sed junky. Every third command I
type, it seems, involves sed (at least once). But the full scope of the
environment variable manipulation cannot be addressed by sed, and we
should not (without good reason) be looking for a non-standard way to do
perform standard tasks. sed is not the answer here.
-Al
[0] A caveat was made by me for exceptions of unspecified instances of a
"special purpose tool" (such as a bash loadable module (the type of
thing loaded by 'enable -f foo.so') to provide a command (or
whatever) for such a thing), but not elaborated on because I
consider such approaches stupid when it is so simple to just follow
the existing convention and not require the use of such a tool.
--
-----------------------------------------------------------------
a l a n d. s a l e w s k i sale...@att.net
Colin Yates
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Ken Wesson
> That presumption is at least partially incorrect. Native apps (cmd.exe,
> for instance) launched from a cygwin bash command prompt can "see"
> environment variables exported by the parent bash process.
I never claimed there wasn't a way to *export* them. Indeed, if one
can read bash environment variables and set Windows environment
variables then one obviously can export them.
>> since clearly bash has a different idea of
>> what an environment variable is,
>
> Nope;
Yep; bash has, in particular, a different idea of what names are
allowed. If it just used an underlying host OS facility one would
expect that it would impose no requirements of its own, so a name
acceptable by the host would be acceptable by bash given whatever
syntactic disambiguation (e.g. quoting or escaping) might be required
in some cases to make sure bash recognized the name as being a
variable and not something else.
> Each bash process, in fact, will have it's own environment, which will
> have been provided by its parent process. Any Unix look-a-like thing
> running on Windows will need to present a view of a process-specific
> environment to the *nix-style tools in a way they are prepared to handle
> (PATH values will be translated, and similar), and the environment
> constructed for native Windows programs launched by those *nix-style
> tools should ideally see the values in a way they would expect (at least
> for important, well-known vars, such as PATH). And this is how things do
> work with cygwin, from the vantage point of the apps.
That's basically what I was saying. There's a translation layer in
there, rather than the host environment variables and bash's being
identical.
>> Then,
>
> (building on sand...)
Wrong, and I'll thank you to stop publicly insulting me for no good
reason, AND to stop monkeying with the reply-to in an apparent effort
to make my posts get sent to the list in two copies.
>> no matter what it's named, if a Windows application uses a
>> Windows environment variable it will be more awkward to manipulate
>> from a Windows port of bash than an emulated native unix environment
>> variable, and likewise more awkward than a true native unix
>> environment variable manipulated on a unix machine and used by a
>> native unix application.
>
> Not necessarily true.
Yes necessarily true; it's simple logic. Either bash uses the host
OS's environment variables or it doesn't. If it doesn't, then using
the host's (when separate) is more awkward than using bash's internal
ones (and you yourself have complained that it's more awkward). If it
does, then most of what you and others said in this thread was wrong,
and what I said is moot because it was based on a presumption of some
of your claims in that regard having been correct.
> I noted earlier that Unix and Linux are both
> permissive in the names allowed for environment variables; nevertheless,
> in *nix there's a tradition of following established conventions unless
> there is a good reason not to. Naming environment variables such that
> they can be manipulated as POSIX shell identifiers is just one example
> of following a useful convention:
And here you again admit a distinction between environment variables
and shell variables, this time indicating that they don't even
coincide on unix, let alone on Windows. That distinction undermines
pretty much everything else you've said, however, and in particular
all the gratuitous insults you've lobbed at me on a public mailing
list.
> No good reasons have yet been posited on this thread to use an
> environment variable named to be incompatible with that established
> convention, regardless of what is permissible by the host OS.
The "established convention" in question is a UNIX convention and the
software you're complaining violates it is WINDOWS software. There IS
no Windows convention on naming environment variables compatibly with
"shell identifiers" because there ARE no "shell identifiers" on
Windows, at least not in the same sense as in unix. Windows, and
Clojure-CLR, were not written with the convenience of bash users in
mind. If there's an impedance mismatch with bash users the problem is
with bash being NONnative on Windows, not with the native Windows apps
the bash users are finding it awkward to use from in bash! And lest
you consider this to be unix-bashing or Windows-promoting, it'd be as
invalid, for identical reasons, to complain that a unix tools have an
impedance mismatch with a unix-ported Windows tool and blame the unix
tools.
>> 1. The OP just wanted to *set* the variable and call Clojure-CLR. That
>> problem is solved.
>
> That's not an accurate representation of what the OP wanted,
It is an accurate representation of what the original post said, and
I'll thank you to stop falsely accusing me of inaccuracy!
> If that were satisfactory to the OP and other folks who have chimed in since,
> then we could have dropped this whole thing a while ago.
I thought we HAD dropped this, but then today I came here to find you
had written a long, insult-laced diatribe for no good reason.
Apparently you are unwilling to let this go, for whatever reason.
>> A claim was mooted that it was unsolvable without
>> renaming the variable, and that claim was decisively proved wrong.
>
> That's not true, either
YES, IT IS.
I AM NOT A LIAR. But, unfortunately, I'm starting to suspect that the
same can't be said about you.
>> 2. Subsequently, a claim was mooted that though it was admittedly
>> possible to *set* the variable it would not be *possible* to read it,
>> and thus to set it to a function of its prior value -- and THAT claim
>> was decisively proved wrong.
>
> False again;
Stop lying about me. Nothing that I have written has been false. On
the other hand, nearly everything that you have written, and every
SINGLE thing that you have said about me, has been false.
> please re-read the thread.
Please learn some manners. Calling other people names is rude.
Implying that other people are lying is rude. Implying that other
people have not read the thread, when they have, is rude. And if that
makes my post rude as well, so be it. You've certainly given me
sufficient provocation.
>> 3. So now you admit that it IS possible,
>
> (By "you", I'm presuming you mean something like "you guys", and are
> therefore treating all arguments contradicting your own as a whole;
I believe I clarified that later in my post. Suffering from reading
comprehension problems?
> Nope; wrong again.
Yes, you are wrong again.
>> but instead of leaving it at
>> that, you just change your objection -- AGAIN --
>
> That, too, is not true.
It is, in fact, 100% true. Once again: Stop lying about me.
It is clear that you have nothing constructive to add to this thread
at this point. The sole function of your latest post is Wesson-bashing
rather than actually solving any problems or even providing reasoned
arguments of any sort. You're just repeating what was said earlier in
the thread, and then pretending it says something completely different
from what it says.
1. It is possible to launch Clojure CLR from bash with a specific
value of the variable.
2. It is possible to launch Clojure CLR from bash with a value of the
variable that is a specific function of the preexisting value of the
variable.
Both of those are established FACT. Your objection was first to
suggest that 1 was impossible, then to suggest that 2 was impossible,
then to admit that while 2 is possible it's "inconvenient" because the
syntax differs from how you'd normally do it on a unix machine.
That's both moving the goal posts -- repeatedly -- AND missing the
important point that THE OP ISN'T USING A UNIX MACHINE, and anyone
expecting things to work the same as if he was is simply being
unrealistic. If the OP wants completely normal Unix behavior without
any trouble at all caused by using Windows instead of Unix then he is
advised to a) get Unix, b) get a JVM for it, and c) use Clojure-JVM on
that, or maybe d) try his luck with Clojure-CLR on Mono.
> the wider usability issues
Here again is the complaint that it's not *impossible* but merely
*annoying*, in disguise. And the OP hasn't since weighed in to suggest
the amended approach is even annoying. Only you have claimed that.
What makes you think you can speak for the OP on this matter?
> provided clarifications to help you see what you refused to see.
Erroneously presupposes that a) you're correct and b) I refused to see
anything. I think it's quite the reverse; solutions were posted, but
YOU refuse to recognize them as such, because doing so would deprive
you of your grievance, and apparently your grievance is more important
to you than the OP actually getting things done. (What grievance is
that, anyway? Generalized dislike of Windows? Specific dislike of CLR,
.NET, or Clojure-CLR even?)
>> this time to say that
>> it's *too inconvenient*.
>
> *yawn*
>
> Please re-read
*yawn*
Please re-read where I said not to accuse me of a) lying or b) failing
to read things in this thread.
>> 4. On top of all of this goalpost-moving
>
> That simply has not happened.
Liar; see above.
>> by what seems to be either a
>> Sybil attack or a tag-team of opponents ganging up on me,
>
> It's gotta be one or the other; both are more likely than the
> possibility that more than a single person on the Internet would
> honestly disagree with something you said.
Oh, you could be honestly disagreeing; in fact, you probably are
simply wrong and honestly disagreeing on the original point, though it
seems that you have stooped to lying about your opponent in the debate
in order to either lash out at him or try to damage his credibility,
I'm not sure which. It's rather unfortunate, either way.
>> are making, which is that developers of native Windows
>> applications should be adhering to Unix naming conventions
>> for the > convenience of that tiny fraction of Windows users that use a port of
>> bash to Windows as their command shell instead of using native tools
>> such as cmd and Explorer!
>
> In the absense of widely used conventions in the host environment, it is
> not a bad practice to adhere to well established conventions established
> elsewhere,
Erroneously presupposes a) a lack of widely used conventions in the
Windows environment and b) that Windows ever had any reason to
consider conventions "established elsewhere", by which you seem to
mean unix, as in any way important. The fact is Windows evolved as a
desktop OS first and only later moved into the server space, and unix
never had much market share as a desktop OS, so the two didn't even
collide much until after the Internet was invented. There was NO
REASON for them to use even REMOTELY similar conventions for e.g.
environment variables. So you have no justification in lambasting
Windows for not having used Unix conventions in the time before its
own became well-established, and certainly none if you're suggesting
that it should change things up now that they HAVE become
well-established.
> if only in recognition that those conventions came about
> because they were useful in some way, and provided benefits to the
> community that established them.
The conventions on environment variable naming are like which side of
the road you drive on: everyone on the same road network should use
one side consistently, but there is NOTHING WRONG with a different
network doing it differently.
So, your complaint that Windows allows dots in environment variable
names that unix forbids is exactly like complaining that Brits drive
on the "wrong" side of the road, and your complaint is simply invalid.
And your pleas on behalf of the OP are like demanding that everyone in
New York start driving on the opposite side of the road because a Brit
is visiting New York for a while, and his British car (bash) has the
steering wheel on the other side from all the New York cars.
Do you realize, now, how silly you've been sounding?
The OP can either borrow a New York car (use cmd.exe and batch files),
live with being seated farther from the center line of the road while
driving in New York (do the env thing, or some other not yet specified
workaround that is also perhaps inconvenient), or go back to Britain
(use unix and, probably, Clojure-JVM, rather than use Windows).
Expecting everyone in New York to change their behavior (and replace
all their cars!) instead is simply not realistic.
> If there's a competing convention on Windows (or any other OS), I'm not
> aware of it, and it certainly hasn't been mentioned here.
Perhaps the Windows convention is simply strictly more permissive,
allowing a broader range of characters in environment variable names?
(Then the argument becomes more like someone complaining about people
turning right on a red, after moving to where that's allowed from
somewhere that forbids it but also drives on the right.)
> In the absence of a competing convention and an entrenched user base,
You have GOT to be kidding me. Are you really suggesting that Windows,
with its juggernaut market share, lacks "an entrenched user base"?
Hell, by now even Clojure-CLR probably has "an entrenched user base"
that would be inconvenienced if the next version renamed things.
> arguing to /not/ change 'clojure.load.path' to something that can be
> manipulated as a valid POSIX shell identifier (without compensating
> rationale) is arguing for a point of arbitrary incompatibility.
If Clojure-CLR was designed to be run on Unix you might have a point
there, but it's not, and the dots in clojure.load.path are quite
easily the LEAST of the Unix incompatibilities in Clojure-CLR. If we
were discussing Clojure-JVM, whose host is intended to be
cross-platform, you'd have a point, and as far as I'm aware things
like JAVA_HOME are intentionally least-common-denominator
(case-insensitive, alphabetics and underscores only) as one might
expect. But the Common Language Runtime is from Microsoft. It's
intended for Windows. Things like Mono are not supported by Microsoft;
things like bash ported to Windows are also in "you're on your own"
territory, for obvious reasons. It's a stroke of luck for the OP that
bash can even be ported to Windows at all, or Clojure-CLR launched
from it with a modified environment variable at all, really. Expecting
anything to do with the Common Language Runtime to go out of its way
to cater to unix users and users of ported unix tools is just silly.
>> Taken to its logical extreme, such a
>> position is probably untenable, as it's likely that if you intersected
>> the subsets of names and other practices that would be allowed and
>> convenient for all operating systems you'd wind up with the empty set
>> and become paralyzed into inaction. :)
>
> Nah, you'd end up with something that looks like Java, with some systems
> programming bits thrown in.
And you've stepped right into the trap. Good.
If the OP wants something that looks like Java and is designed to
work, as well as possible, across platforms, then the OP should be
using Java! Which means Clojure-JVM instead of Clojure-CLR.
But I respect the OP's right to use Clojure-CLR instead if that's
their wish, for whatever reason. But then, impedance mismatches can be
expected when trying to use it in combination with unix tools not
designed for a Windows environment, and demanding Clojure-CLR change
to suit such unusual users seems arrogant and silly.
> I don't disagree with that, generally. But the fact of the matter is
> that *nix has more established conventions,
And here we get to the quux of the matter: you're a unix partisan and
a Windows-hater. According to the Gospel of Unix Weenies, Unix is the
One True OS and thou shalt worship none other before Him. Unix
conventions are the One True Conventions and those who stray from them
are heretics and unbelievers. The savage infidels of BeOS and NeXT
must be converted, and the foul followers of evil Windows must be
destroyed!
Well, if you want an OS war, you're not getting one from me. Just my
opinion that such attitudes -- in EITHER direction -- are stupid and
counterproductive.
> Even if the *nix conventions are not used, they
> should be departed from for reasons better than laziness or arbitrary
> incompatibility.
"The platform we're programming for is not unix" seems like such a
reason to me -- indeed, I must wonder what your reason is for
expecting Windows developers writing for a (to a first order)
Windows-only platform (the Common Language Runtime) to pay ANY
attention AT ALL to what's going on in unixland! I very much doubt
anyone deliberately flouted a unix convention in naming that variable.
Whoever named it was probably just paying zero attention to whether or
not it adhered to unix conventions because a) it didn't flout Windows
conventions and b) it never even occurred to him that anyone would try
to run Clojure-CLR on unix, or launch it from a unix shell on any OS.
>> and here we have a Windows-native
>> application
>
> CLR is not the same as Windows-native...
Sure it is. The existence of Mono doesn't change that -- if it did,
the existence of Wine would mean that there WAS no such thing as a
Windows-native application (and, apparently, the existence of Cygwin
that there was no such thing as a unix-native application), making the
whole notion of "native" meaningless.
But it's a useful term that makes a useful distinction between
"designed to run on platform X" and "may turn out to be possible to
port to platform X, but may flout platform X conventions, including UI
and other conventions, and may be awkward to use on platform X as a
result".
(In this case, the non-native application that's proving to be awkward
to use on platform X is bash being used on Windows -- not Clojure-CLR,
even though that's what's being blamed and accused of being awkward by
some other posters in this thread.)
> ...and even if it were, multiple folks have expressed an interest in
> using it in cygwin or similar.
What is your evidence for your claim that it's "multiple folks"? The
OP is just one, and the only one so far to directly state such an
interest. And even if there are more, how numerous are they? Three?
Five? Maybe even a dozen? Compared to how many CLR users that don't
even know what Cygwin is? Thousands? Tens of thousands?
>> I'd say that that's too bad for the unix
>> user affected by it,
>
> Why?
Because he's using bash on Windows, which is not bash's native
platform, and therefore can not in all reason expect everything to
"just work" without running into the occasional hitch, that's why.
Again, it's really a stroke of luck that it can be made to work at
all.
> For the foreseeable future, there will be portability issues between
> different programs on different OS's, and on different runtimes on a
> single OS. If the incompatibility is not arbitrary, then so be it; but
> what does anybody gain by arbitrary incompatibility?
This erroneously presupposes that anyone intended any incompatibility,
and furthermore that there weren't already a lot more and more-serious
incompatibilities. CLR was not designed to interoperate with Unix and
Unix tools, save via network protocols, period.
>> but not a foul by the Windows community,
>
> Nobody suggested that;
Your actions speak louder than your words. Windows program difficult
to use from bash -> you say the Windows program should be changed to
accommodate bash users. Someone steps up to point out the trouble with
your position, and the existence of workarounds -> you not only argue
vehemently, you stoop to flaming him and even publicly telling lies
about him by cowardly insinuations of dishonesty and reading
comprehension problems on his part (while ironically displaying some
similar problems in the process). It sure SEEMS like you consider the
naming of that variable to be a foul by the Windows community, whether
you admit to feeling that way about it or not!
> there has simply been no rationale provided why
> the existing name of 'clojure.load.path' is better than a name that is a
> valid POSIX shell identifier.
The erroneous presumption this time is that the developers of a
CLR-based system are obligated to even have such a rationale in the
first place. In any event, now that the name's been in use for some
time there IS a rationale: changing it in the next version would upset
the applecart for the existing user-base, which is probably larger
than the tiny number of new users that would like it to be more
convenient to launch from within bash.
>> and it's
>> not even the biggest unix/Windows impedance mismatch out there
>
> No, but it was arbitrary.
All conventions have some element of arbitrariness to them.
> And demonstrably problematic.
To, so far as is known, 1 user.
> And easily fixable.
Depends what you mean by "easily". Changing it now will inconvenience
the existing N users of Clojure-CLR to please a number of other users
M not thus far proven to exceed 1. It's likely that N is much larger
than M and a virtual certainty that it's at least somewhat larger,
particularly if M is in fact 1.
>> about cr/lf vs. lf? Space-ridden case-insensitive file names that need
>> to be quoted to move to unix, and cause collisions sometimes moving
>> the other way?
>
> No need to get into all of that...
I thought it might give you a dose of perspective. When a long time
went by without you posting any more on the topic I thought maybe it
had worked, but it looks now like you were just taking some time to
build up a head of steam before dredging this old thread up and giving
it both barrels. :P
>> Name collisions are certainly a larger inconvenience
>> than having to -- my God! -- use sed a little bit. :)
>
> Like many *nix folks, I happen to be a sed junky. Every third command I
> type, it seems, involves sed (at least once). But the full scope of the
> environment variable manipulation cannot be addressed by sed,
So you claim. But even if that's true it's still beside the point. The
variable value can be read and extracted with sed. Once extracted, it
can be put in a shell variable. Once there, any manipulation can be
performed on it that bash can perform, and not just the subset that
sed can perform. And then it can be used as the value of the
environment variable in launching a Clojure-CLR process. The extended
version of the OP's problem is therefore solvable. It takes a few more
steps perhaps than if the variable value could be directly manipulated
by bash in-place. I'm not denying that it might be less convenient.
What I am denying is a) that it's not even *possible* and b) that the
inconvenience means everyone in New York should drive on the other
side of the road for as long as a visiting Briton is in town, instead
of the Briton accepting a little inconvenience for the duration of
their visit to the Big Apple.
> and we should not (without good reason) be looking for a non-standard
> way to do perform standard tasks. sed is not the answer here.
There IS no "standard" way to perform this task, because the task in
question is RUNNING A WINDOWS-NATIVE LANGUAGE RUNTIME FROM A UNIX
SHELL! There can not be anything at all standard about it! Geez! So
what you say about "standard tasks", while true, is simply not
relevant here!
> [0] A caveat was made by me for exceptions of unspecified instances of a
> "special purpose tool" (such as a bash loadable module (the type of
> thing loaded by 'enable -f foo.so') to provide a command (or
> whatever) for such a thing), but not elaborated on because I
> consider such approaches stupid when it is so simple to just follow
> the existing convention and not require the use of such a tool.
This, of course, is equivalent to saying "someone might have made a
kit for temporarily moving the steering wheel and pedals to the other
side of a British car, but I consider such approaches stupid when it
is so simple to just follow the 'existing convention' and drive on the
left side of the roads in your country".
Feeling silly yet?