On Thu, Aug 18, 2011 at 06:40:50PM -0400, Ken Wesson spake thus:
> 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 <kwess...@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 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
