#215 Retitled: Two apparent garbage enviroment vars
I am reposting this ticket. It was peremptorily closed, for no good reason, as I will explain below.
----- Begin original post:
In MSYS window. I get the following lines as part of printenv output:
!::=::\ !C:=C:\Windows\System32
Here is more complete listing.
$ echo $MSYSTEM MSYS $ printenv | sort | head !::=::\ !C:=C:\Windows\System32 _=/usr/bin/printenv ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\dgoldman\AppData\Roaming CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files COMMONPROGRAMFILES=C:\Program Files\Common Files CommonProgramW6432=C:\Program Files\Common Files COMPUTERNAME=LEMUR COMSPEC=C:\Windows\system32\cmd.exe
I posted this to discussion more than a week ago. One user responded, verified that the problem also occurred on their msys2 installation. Nobody offered an explanation. So I'm reporting this as a bug.
Thanks,
Daniel
-------- End original post
The response from David Macek, including deleting the ticket, was:
This is not a bug AFAICT. These variables are part of the environment block and represent current working directories on each drive. I'm not sure what the !:: one does, so if you figure that out, let us know.
If you still think it's a bug, raise an issue with the Cygwin project and post a link to it here.
status: open --> wontfix
My response is that of course I know what environmental variables are. I only complained about two of the lines from the printenv output. David misread my post to think I was complaining about environmental variables in general. Of course the rest of the lines represent working directories and other valid environment variables. David just did not read my post carefully enough, basically assumed I was an idiot who did not understand environmental variables.
David says "I'm not sure what the !:: one does, so if you figure that out, let us know.". Well, that proves my point. The line David mentions is exactly one of the two I complained about. AFAICT, It's an obvious error. If you don't think it's a big error, OK. But you can't just blow it off and ask me to go figure it out. I've already done plenty by reporting the error.
I know shell backwards and forwards. I've never seen that kind of format with those two lines before. I can't prove it's garbage. But if nobody knows what it means, it probably is garbage. The only way we will find out is by asking. Just ignoring apparent errors is a really bad practice, software ends up full of garbage and loose ends.
msys2 is great. I appreciate the hard work the maintainers do. But you seem somewhat clueless about taking input from users who see obvious glitches. You seem quick to discount a valid error report, and assume that the poster doesn't even know what an environmental variable is. If you apparently can't read and understand the English language, to understand that I was reporting two lines as errors, there is a real problem. Next time, you would be MUCH better served by asking for a clarification before peremptorily closing a ticket without even giving the poster a chance to respond, and hence wasting lots of time for me.
To be 100% clear, only the two lines are reported as bugs. Thanks
First, the ticket is closed, not deleted. It doesn't mean that it can't be further discussed. (I don't know if SourceForge disallows posting replies to closed tickets. I didn't think it did. If it does, I'm sorry that I destroyed the option to discuss the matter further.)
I'm sorry you perceived my response as inept and I hope to convince you this is just a misunderstanding. I'd be glad if you re-read my response again thoroughly with your mind clear of the assumption that I'm an idiot. Anyway, there are two links conveniently missing from your citation of my response. If you look at #214 and look at and read the linked pages, it should become clear that I knew what you were talking about and I was answering to the point.
The part of my response saying that this feature/bug comes from Cygwin (upon which MSYS2 is based) is still valid. If there's a bug in Cygwin, it's more productive to ask for help there (even if the fix would come from us in the end), as there's more people using it.
I'll leave this ticket open, but if you're interested in a (meta-)discussion about the quality of our support, you can also come to #msys2 on OFTC and talk to us in real time.
Last edit: David Macek 2015-11-17
The first link you offered (blogs.msdn.com) concerned “strange =C: environment variables” as part of the cmd.exe processor. Both errant output lines I presented started with ‘!’ and were different from the =C: environment variables as in the msdn article. Maybe there is some connection between the oddities I observed and the hidden “=C” variables. But maybe no connection. Even you admit you have no idea what the first line does.
The second link you offered (ss64.com) is a basic primer on windows environment variables. This link is totally not relevant, since it just describes normal environment variables.
Does msys2 use the two lines I highlighted? If yes, how are they used? Apparently nobody knows. So it seemed peremptory to close an issue regarding odd syntax that nobody knows exactly where they come from or what they do. If the response is “Looks like a glitch, we'll put it in the list, but we’re too busy, and this doesn’t seem to cause any harm, so we are not going to do anything.”, that’s OK with me. But the response was to peremptorily close the ticket, and declare “not a bug”.
What about doing a simple test on your PC and reporting some data, like Matt did in the discussion thread? Seems a reasonable step to me.
I'm sorry, I am not going to post on the cygwin discussion group. I know cygwin and msys2 are closely related. However, I don’t use cygwin, and am not going to install cygwin to test this oddity, when you and others already have cygwin installed and can do a quick test. It would certainly be a bad idea to post to the cygwin group without verifying and testing on cygwin. They would probably say "Looks like an msys2 problem. Post there".
I am not going to complain about quality of a response on a meta-discussion. I appreciate you and others volunteer, I’m sure you are doing the best you can, and something is going right, because msys2 is very good. I appreciate you took time to look around for those links. I also took time to report a glitch, when I could have just shrugged my shoulders. Thank you for reopening the ticket.
Daniel
Both links mention the
=C:,=D:etc. variables, that was their point. In my original response, I included a short description of them. ("These variables are part of the environment block and represent current working directories on each drive.") I didn't explicitly say that!C:is equivalent to=C:, but I thought I implied it.I don't think MSYS2 (and Cygwin---it has them as well) uses them for anything else than for passing them down to child processes. I did some tests to support these claims even before posting my original response, but I guess it didn't occur to me to mention it unless someone reports different results.
I'll try to find out if there's some mention of the
!::variable in Cygwin source code if I find some time today. I have an idea, but I'd like to confirm it first.That's reasonable and it's okay as an answer to my "report it to Cygwin". We do report and discuss stuff with Cygwin people, but it's good to off-load less urgent questions to curious users, like you seem to be.
Thank you for taking the time in the first place, and for coming back to explain what was wrong with my response. I'll try to improve based on your feedback.
I was and still am pretty sure about what the variables do (less sure about
!::).It was never my goal to cut the discussion short. Can you confirm that by closing the ticket I disallowed you from adding responses to it? I need to adjust my process if that's true.
Cheers.
I agree the =c: variable is similar to !C:=C:\Windows\System32 line, so it's a good clue. But it is a different syntax, so we still don't really know. We both seem to agree !::=::\ line is even more of a mystery.
Thanks for checking that those lines are passed down to child process. However, I'm not sure that proves anything. It may be "garbage in, garbage out". The question is - Do the child processes use those lines? I don't know. Apparently, nobody else knows.
Thanks for looking through the source code. I'm sure you already know - grepping for ":=" and a few other variations might help.
It's very reasonable of you to ask me to report to cygwin group, to offload reponsibilities. If I had cygwin installed, I would do it. But I don't even know if this shows up under cygwin.
No, I cannot confirm that by closing the ticket you disallowed me from adding responses to it. But it sure looked like it. How was I to know? You said "If you still think it's a bug, raise an issue with the Cygwin project and post a link to it here." It didn't say anything about adding responses to the closed ticket.
I admit some "bug reports" might be just be dead wrong, so close the ticket and that's it. However, this bug report is not dead wrong, since we don't know what those two lines do.
I have no complaints at this point. I appreciate the work you do, msys2 is a great system, and I hope I can help a little by asking and answering questions.
Daniel