On Sun, Aug 21, 2011 at 3:14 AM, Alan D. Salewski <salew...@att.net> wrote: > 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? -- 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
