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, 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. :) -- 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. -- 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
