Nothing to add to this discussion, but please *please* realise how destructive these type of posts are. They significantly increase the noise and make us all look like muppets.
I respect most of the "usual suspects" in these threads, but please - let's keep this on topic. Alternatively maybe this mailing list should start moderating posts, which would be a real shame. On 21 August 2011 08:14, Alan D. Salewski <salew...@att.net> wrote: > 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 > -- 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
