Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

[Vince Rice]

> On Aug 27, 2019, at 11:28 AM, Houder wrote:
> 
> On Tue, 27 Aug 2019 17:25:49, Corinna Vinschen  wrote:
>> …
>> mkdir(2) has some special code from 2009 which drops trailing
>> {back}slashes to perform a bordercase in mkdir Linux-compatible.
>> This code snippet doesn't exist in rmdir(2).
> 
> .. uhm, I must be speaking to the alter ego of Corinna V,. because
> as far as I know, Corinna has given herself some time off ...
> 
> Perhaps you could make an entry in her "TODO list" that the 3 lines
> above requires some more explanation for pour souls like me.

I am not Corinna, but I read that as…
The mkdir command works because it has special code added to it to make
it work. The rmdir command doesn't work because it doesn't have the same
code in it.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Empty file without "x" permission is successfully executable on Cygwin

[Vince Rice]

> On Aug 6, 2019, at 4:16 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> 
>> Which is why, as Ken said, the size is irrelevant.
> 
> Which makes your comment irrelevant as well.  Read the thread what I was 
> responding and to whom before trolling.

I did read the thread. And Ken's comment was exactly correct, which you 
confirmed after the fact.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Empty file without "x" permission is successfully executable on Cygwin

[Vince Rice]

> On Aug 6, 2019, at 3:39 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via wrote:
> 
>> But what's your basis for saying that an empty script shouldn't be 
>> executable?
> 
> I meant it only in the context of the script file lacking the proper "x" 
> permission.
> Of course an empty script _with_ such permissions allowed must be executable, 
> and it will always complete with exit code 0.

Which is why, as Ken said, the size is irrelevant. What's relevant is that it 
shouldn't be executing
anything that doesn't have the executable bit set. Which is what Corinna fixed.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Perl Illegal Instruction

[Vince Rice]

> On Jul 15, 2019, at 3:36 PM, Chris Wagner  wrote:
> 
> On 2019-07-15 3:46 pm, Achim Gratz wrote:
>> Terribly out of date and no longer safe to use on a networked system.
> 
> Of course it's up to date…

There is no "of course" in troubleshooting. As Achim noted and you didn't quote,
whether a "Windows 7 SP1" system is up-to-date depends on what has been
laid on top of Windows 7 SP1. Since, as Achim also noted, MS refused to use
SP2 to refer to the huge sets of patches following SP1, then SP1 by itself is
insufficient information.

>>> So I turn to strace and it states Illegal Instruction.  Any ideas?
>> BLODA or worse, assuming that _you_ didn't change anything recently.
> 
> That is not BLODA.  That's the standard list of libraries.  

What's not BLODA? You don't specify what you're referring to here. What Achim is
referring to is https://cygwin.com/acronyms/#BLODA and the list of applications 
found on the link there. 

> I changed nothing; it worked yesterday; today it didn't.  Every other Cygwin 
> executable
> I've tried works without problem.  I even tried reextracting the files from 
> perl_base.

Is this a computer under your control or a corporate computer? You changed 
nothing,
do you know nothing was changed? (Those two are often not the same in a 
corporate
environment. And even on a computer where, e.g., updates are applied 
automatically.)
Regardless, that's how BLODA often manifests itself—things that worked perfectly
an hour ago now don't.

>>> $ uname -a
>>> CYGWIN_NT-6.1 applejack 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin
>> A current Cygwin...
>>> $ cygcheck -c perl perl_base
>>> Cygwin Package Information
>>> Package  VersionStatus
>>> perl 5.22.4-1   OK
>>> perl_base5.22.4-1   OK
>> combined with an outdated Perl (Cygwin is at 5.26.3 now).  What are you
>> trying to achieve?  Please fully update Cygwin after checking your
>> system.  Also, you might want to clean up your PATH a bit.
> 
> I'm not going to recompile all my modules and rework the new lib paths until 
> I have
> a really good reason to.

You have a good reason to. Your perl isn't working, and the person trying to 
help you
troubleshoot your problem suggested it as the next step.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: How to start and verify cron?

[Vince Rice]

> On Jul 11, 2019, at 4:18 PM, David Karr wrote:
> 
> I typically try to avoid top-posting, but I'm pretty sure I won't be able
> to do anything about the mailer configuration.

Then you'll need to fix it manually, like I just did on yours. Whichever it is, 
please
stop including email addresses in your replies.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: How to start and verify cron?

[Vince Rice]

> On Jul 11, 2019, at 3:12 PM, Vince Rice wrote:
> 
>> On Jul 11, 2019, at 2:56 PM, David Karr wrote:
>> 
>> It's curious that when I bring up the default "Packages" view, filtering
>> for "syslog-ng" doesn't find anything.  I had to switch to the Categories
>> view, and then filtering for that found it.
> 
> Not that curious. Setup's search is searching packages contained within
> the current view. "Packages" is not one of the drop-down options for View.
> The default view is, I believe, Pending, or at least that's what always opens 
> for me. And it wouldn't show up in Pending for you since it's not installed on
> your PC and therefore can't be pending. Categories (and Full) both show all
> packages, and therefore it would be found in those views.
> 
> Also, please don't top post. https://cygwin.com/acronyms/#TOFU

And https://cygwin.com/acronyms/#PCYMTNQREAIYR. (Sorry, missed that
the first time.)
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: How to start and verify cron?

[Vince Rice]

> On Jul 11, 2019, at 2:56 PM, David Karr wrote:
> 
> It's curious that when I bring up the default "Packages" view, filtering
> for "syslog-ng" doesn't find anything.  I had to switch to the Categories
> view, and then filtering for that found it.

Not that curious. Setup's search is searching packages contained within
the current view. "Packages" is not one of the drop-down options for View.
The default view is, I believe, Pending, or at least that's what always opens 
for me. And it wouldn't show up in Pending for you since it's not installed on
your PC and therefore can't be pending. Categories (and Full) both show all
packages, and therefore it would be found in those views.

Also, please don't top post. https://cygwin.com/acronyms/#TOFU
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Vince Rice]

> On Jun 4, 2019, at 5:55 PM, Steven Penny wrote:
> 
> Easy compared to what, assembly?

Easy compared to hard.

> He shows some domain knowledge of OpenSSL, but where are you getting that he
> knows about compiling C? 

It's cygport, he doesn't have to know about compiling C. He has to know about
running a one-line cygport command.

>> Please refrain from your own inappropriate assumptions and meta-commentary
>> based on that, as this is not a social media platform.
> 
> No, but it is a public forum. and I will call out nonsense if I see it. As 
> your
> type of comments are off putting to new users.

Brian offered the user help. Brian is one of the most helpful people on this 
list. You
offered the user nothing, and berated Brian for offering help. The only 
nonsense on
offer here is from you. And the only one off-putting in this conversation is 
you.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Vince Rice]

> On Mar 28, 2019, at 1:33 PM, Thomas Wolff wrote:
> 
> Am 28.03.2019 um 19:16 schrieb Vince Rice:
>>> On Mar 28, 2019, at 1:09 PM, Thomas Wolff wrote:
>>> 
>>>> A potential solution is, add another user to your system named cygwin.
>>>> When you build you packages use the cygwin user. The debug information
>>>> will reference your cygwin user, and not your real user account.
>>> Thanks for the suggestion, but there are other solutions meanwhile. Also, 
>>> you would have
>>> to remember to switch user everytime, which may take a while, and it's not 
>>> even possible
>>> to create user accounts on everybody's machine.
>> You're the only one that needs to remember, and it's only your machine that 
>> would need the
>> the user account. Other people building the package don't have the same … 
>> requirements …
>> you do. They're not distributing what they build. They would just use the 
>> cygport and be done
>> with it.
>> 
>> (Not selling the solution as I have no opinion on it, just pointing out that 
>> neither of those
>> objections are really a problem.)
> What I wanted to point out with my last objection is that some people may not 
> be able to create an account as they like, in an enterprise environment.

And what I was pointing out is that nobody but you needs to. This whole thread 
is about trying
to solve *your* problem, not someone else's. As I said, if I built mintty, I 
would just use cygport
and be done with it. I don't care about user information, because I'm not 
distributing the package.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Vince Rice]

> On Mar 28, 2019, at 1:09 PM, Thomas Wolff wrote:
> 
>> A potential solution is, add another user to your system named cygwin.
>> When you build you packages use the cygwin user. The debug information
>> will reference your cygwin user, and not your real user account.
> Thanks for the suggestion, but there are other solutions meanwhile. Also, you 
> would have
> to remember to switch user everytime, which may take a while, and it's not 
> even possible
> to create user accounts on everybody's machine.

You're the only one that needs to remember, and it's only your machine that 
would need the
the user account. Other people building the package don't have the same … 
requirements …
you do. They're not distributing what they build. They would just use the 
cygport and be done
with it.

(Not selling the solution as I have no opinion on it, just pointing out that 
neither of those
objections are really a problem.)
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: util-linux package missing usr/bin/script between 2.25 and 2.32

[Vince Rice]

> On Mar 3, 2019, at 3:38 PM, Mason Giles wrote:
> 
> Hi,
> 
> The /usr/bin/script program seems to have gone missing from the util-linux 
> package somewhere between the 2.25 and 2.32 timeframe.
> 
> As far as I can tell this program is still included upstream (and the 
> util-linux package still contains its /usr/bin/scriptreplay counterpart).
> 
> Any ideas what happened here? Is it possible to have this program reinstated?

A search of the mailing list archives would have found the answer.

https://cygwin.com/ml/cygwin/2019-02/msg00366.html
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin 3.0.1-1 Breaks ALL cygwin applications on Windows 7 x64

[Vince Rice]

> On Feb 26, 2019, at 8:55 PM, Jerry Baker wrote:
> 
> I don't work for free,
This is open source. Given that the people here do, that's not a very good 
argument.

> especially for hostile people with over inflated egos and crippling social 
> disorders.
Don't feed it by arguing.

> The onus is on whoever is interested in having cygwin work in this particular 
> configuration.
Again, this is open source; there is no onus.

Win7x64 is a very common cygwin installation (including one of my VM's, which 
has
no issues with 3.x). You're the only one reporting the problem. If this were a 
general
Win7x64 problem, the list would have exploded by now. You're the only who has
access to your system. Consequently, you're the only one that's going to be 
able to
debug it. There's nothing obvious (to me, anyway) in your cygcheck.out. If you 
don't
care enough to debug it, that's not a problem; just live with 2.x for as long 
as 2.x will
continue to work.

You might try strace'ing a cygwin program and see if anything obvious shows up 
in
the output. Look for Windows errors, permission errors, etc. (Don't send it 
here unless
someone asks for it). See the User's Guide 
(https://cygwin.com/cygwin-ug-net.html)
for info on strace.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin 3.0.1-1 Breaks ALL cygwin applications on Windows 7 x64

[Vince Rice]

> On Feb 26, 2019, at 2:00 PM, Jerry Baker wrote:
> 
> I just installed from scratch in a new directory. Same issue. Nothing runs.

If cygcheck doesn't run, then it would appear there's (at least) something 
non-cygwin-related
 going on. cygcheck isn't a cygwin program, i.e. it doesn't link to or depend 
on cygwin1.dll.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin 3.0.1-1 Breaks ALL cygwin applications on Windows 7 x64

[Vince Rice]

> On Feb 26, 2019, at 12:37 PM, Jerry Baker wrote:
> 
> That's why you're reading about it "on the appropriate list," as described on 
> that page. It's a take it or leave it thing. I report it, and the cygwin 
> community can do whatever they like with it - ignore it, investigate it, 
> shoot the messenger. It's their project.

What is also described on the page are the reporting guidelines. Please read 
them again, paying special
attention to the bolded part.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Get Cygwin home directory path for current user

[Vince Rice]

> On Feb 14, 2019, at 5:41 PM, Bill Stewart wrote:
> 
> On Thu, Feb 14, 2019 at 4:32 PM Vince Rice wrote:
> 
>> I didn't suggest everyone did. But people who want tilde expansion do, 
>> because it's
>> the shell that is responsible for tilde expansion.
>> ...
>> No, it isn't "oddly" absent. As has been said repeatedly in this thread, 
>> tilde expansion
>> is the responsibility of the shell. Cygwin has nothing to do with it. The 
>> *shell* does
>> it.
>> ...
>> Because, repeat after me, IT'S THE SHELL THAT DOES THE EXPANSION!
> 
> (?) I understand that the shell does ~ expansion. I am asking for a
> way to get that particular path (forget about the ~ character for the
> time being) without needing to invoke a Cygwin shell in the first
> place. (That was the whole point of the request.)

It would not appear that you do. You asked why a Cygwin shell would be a 
prerequisite.
That's exactly why a Cygwin shell is a prerequisite—*because it's the Cygwin 
shell that
does the expansion.* The only way to get the expansion is through a Cygwin 
shell.

Here, you say "forget about the ~ character." We can't "forget" about the 
tilde. This whole
conversation is about the tilde, specifically tilde expansion.

You're not going to get tilde expansion outside of a Cygwin shell.
*Because it's the Cygwin shell that does the expansion.*
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Get Cygwin home directory path for current user

[Vince Rice]

> On Feb 14, 2019, at 4:52 PM, Bill Stewart  wrote:
> 
> On Thu, Feb 14, 2019 at 3:14 PM Vince Rice wrote:
> 
>> There is -- use a cygwin shell. As Eric has already explained, expansion is 
>> the
>> shell's responsibility. Powershell doesn't do it. If you want expansion, use 
>> one
>> that does.
> 
> So let's consider, for a bit, that not everybody uses a Cygwin shell.
> (Hard to believe, perhaps, but PowerShell is really quite good.)
I didn't suggest everyone did. But people who want tilde expansion do, because 
it's
the shell that is responsible for tilde expansion.

> For interoperability's sake, it is useful to get this path from the
> Windows side, and this seems oddly absent.
No, it isn't "oddly" absent. As has been said repeatedly in this thread, tilde 
expansion
is the responsibility of the shell. Cygwin has nothing to do with it. The 
*shell* does
it.

> Cygpath already has a set of flags for returning system information
> directories, such as -H, which returns the path to the user profile
> directory. (As I noted previously, this is not always the same as ~
> when expanded in a Cygwin shell.)
Those "system information directories" are *Windows* directories. Completely 
different
thing.

> As I noted previously, yes, the below works:
> 
> dash -c '/bin/cygpath -aw ~'
> 
> However, this seems awkward and requires a Cygwin shell (why should
> that be a prerequisite?).
Because, repeat after me, IT'S THE SHELL THAT DOES THE EXPANSION!
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Get Cygwin home directory path for current user

[Vince Rice]

> On Feb 14, 2019, at 3:51 PM, Bill Stewart wrote:
> 
> Seems like there must be a better way...

There is — use a cygwin shell. As Eric has already explained, expansion is the
shell's responsibility. Powershell doesn't do it. If you want expansion, use one
that does.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Getting error message when launching X-Window apps in Cygwin

[Vince Rice]

> On Feb 9, 2019, at 6:01 PM, L A Walsh wrote:
> 
> On 2/9/2019 11:06 AM, Vince Rice wrote:
>>> On Feb 9, 2019, at 8:46 AM, L A Walsh wrote:
> 
>> What you think about this is irrelevant.
> 
>Not really.
Yes, really.

> 
>> What I think about this is
>> irrelevant. The only thoughts that matter are the ones of those who
>> manage the list,
> 
>   But they only claim to represent the readership.
Nope.

>> and they have said this is a "do not top post" list.
> ---
>   Oh?...I've talked to legal where this list is hosted, and
> they know nothing about this being an official policy.
I'm not sure who "legal" is or what you think legal has to do with the
running of the list.


>> Others who say "do not top post here" aren't (necessarily) arguing
>> about which is better, they are stating list policy.
> ---
>   They are repeating what they've heard from
> others who told them who told them who did the same.
No, they're stating list policy. That you want to argue that means you don't
know the list policy.

>> This list is a "do not top post" list. If 
>> you want to post here, then don't top post.  
> 
> I don't top or bottom post, as I trim my quotes.  That's what
> people are supposed to do -- but no one does it, so they tell
> them to be bottom-posters.

Trimming quotes has nothing to do with top or bottom posting.

>   If you didn't like my post, …
Whether I like it or not is also irrelevant.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Getting error message when launching X-Window apps in Cygwin

[Vince Rice]

> On Feb 9, 2019, at 8:46 AM, L A Walsh  wrote:
> 
> …
> 
> For me, …

What you think about this is irrelevant. What I think about this is
irrelevant. The only thoughts that matter are the ones of those who
manage the list, and they have said this is a "do not top post" list.
Others who say "do not top post here" aren't (necessarily) arguing
about which is better, they are stating list policy. Arguing with them
is pointless, because they didn't set the policy.

This list is a "do not top post" list. If you want to post here, then don't 
top post.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: iperf 2.0.13 available

[Vince Rice]

> On Jan 23, 2019, at 5:54 PM, Bob McMahon wrote:
> 
> Hi,
> 
> We've done a lot of work to make iperf 2.0.13 work well on cygwin.  There
> are also a lot of new features relevant to the WiFi testing community.  Is
> there a contact on how to get this distributed via cgywin apps?

https://cygwin.com/cygwin-pkg-maint shows that iperf has a maintainer. It is up 
to the maintainers
when updates to their respective packages are built and released.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin Statistics and curiosity

[Vince Rice]

> On Jan 11, 2019, at 10:43 AM, Corinna Vinschen wrote:
> 
> On Jan 11 16:40, Lemke, Michael  ST/HZA-ZIC2 wrote:
>> On Friday, January 11, 2019 5:30 PM Corinna Vinschen wrote:
>>> On Jan 11 16:15, Lemke, Michael  ST/HZA-ZIC2 wrote:
 On Friday, January 11, 2019 3:50 PM David Dombrowsky wrote:
> On 1/11/19 8:40 AM, E. Madison Bray wrote:
>> I have often wondered why apt-cyg [1] hasn't been adopted fully by
>> Cygwin as one of the default packages (in fact I'm not sure if there
>> even is an actual cygwin package for apt-cyg), aside from the fact
>> that it's not formally maintained as part of the cygwin ecosystem.
>> Maybe it should be.
> 
> YES PLEASE!  Cygwin is awesome and this would put it firmly into the
> first class of required windows programs/systems.
 
 It's dead:
 
 https://github.com/transcode-open/apt-cyg/blob/master/status.md
>>> 
>>> If somebody is willing to maintain apt-get as package in the Cygwin
>>> distro, which includes keeping it running if setup.exe changes, fixing
>>> bugs as required(*), by all means,  go ahead.
>>> 
>>> Are you volunteering, by any chance?
>> 
>> My reply was only meant as a hint, I have no interest in the package,
>> but someone (who is on this list I believe) already did:
>> 
>> https://github.com/cup/sage/issues/20
> 
> Nice.

No, actually, it's not nice at all. See 
https://github.com/transcode-open/apt-cyg/issues/73 and read down to 
alphapapa's comment. A little googling will show the comment is accurate.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin Git with Windows paths

[Vince Rice]

> On Nov 27, 2018, at 8:09 AM, Steven Penny wrote:
> 
> On Mon, 26 Nov 2018 22:54:14, Adam Dinwoodie wrote:
>> Personally, I don't see this as a bug; AIUI using Windows style paths
>> isn't something that is supported in general in Cygwin, even if it's
>> something that works in some circumstances.
> 
> It is a bug. Even when you use Unix paths, Cygwin is doing path conversions:

It's not a bug. Cygwin has been on record for a very long time that Windows 
paths might work, but since it's emulating Linux, they are not guaranteed to 
work. If they work, great. If they don't work, too bad. Some maintainers try to 
keep them working in their respective programs, but that is a courtesy, not 
fixing a bug.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: urgent help for tool

[Vince Rice]

> On Oct 24, 2018, at 4:05 PM, Hans-Bernhard Bröker wrote:
> 
> A less disruptive approach would be just a) switch this list from
> anybody-can-post to subscribers-only, at least for the time being, and
> then b) put the FAQ pointers about FAST_CWD prominently into the
> auto-reply for non-subscribed users.  At the very least this would have
> the benefit of not breaking the continuity of the mailing list archives.

An even less disruptive approach would be to just auto-reply to the original
FAST_CWD message, which is what Corinna has already indicated in this
thread that she look into as she has time.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: urgent help for tool

[Vince Rice]

> On Oct 22, 2018, at 5:27 PM, Thomas Wolff wrote:
> 
> Lots of people wrote:
> 1 [main] bash 9316 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
> pointer.
> Please report this problem to
> the public mailing list cygwin@cygwin.com
> ...
> 
 https://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings
> Can we change that error hint so that it points to a suitable help page 
> rather than the mailing list which is getting spammed by lots of people who 
> don't even have an idea how to put a meaningful title on their report?

Already been done (well, something similar). Read the FAQ entry.

It doesn't help for the old versions of cygwin that are being reported. That's 
why they're getting that message—because it's an old version.
They're not spamming, they're doing exactly what the message told them to do. 
The message was unfortunate from the get-go.

Now that has come up yet again, I do wonder if the mailing list software could 
somehow trap an unquoted FAST_CWD message and just reply with a message that 
includes a link to the FAQ entry, rather than send the message onto the list. 
Probably more trouble than it's worth.




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygserver - /usr/sbin vs /usr/bin

[Vince Rice]

> On Aug 14, 2018, at 3:05 PM, cyg Simple wrote:
> 
> On 8/13/2018 10:41 AM, Corinna Vinschen wrote:
>> …
>> 
>> cyglsa.dll requires an install script that would have to be change as
>> well.  In contrast, you'd have to make sure your new solution still
>> works for existing installations.  What's the gain?  Does it *hurt* to
>> have the stuff in /usr/bin like everything else?
>> 
> 
> No but then why have cygserver.exe in /usr/sbin?  Either there should be
> a separation because of required administrative rights or there
> shouldn't be at all.  Having it both ways is just confusing even if the
> confusion isn't apparent to you.

And just because it's confusing to you doesn't mean it's confusing to everyone
else. I for one have never been confused.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: My delayed complaint about spam on this list

[Vince Rice]

> On Jun 4, 2018, at 2:30 PM, Frank Farance wrote:
> 
> I've seen a bunch of spam, and it's continued for a while (beyond my 
> expectation that it would have already ended). 

Fortunately, no one's here to meet your expectations.

If you have issues with the lists, you should take to the right place. Hint: it 
isn't here.

See https://cygwin.com/lists.html, the bottom of the page.

> If you would like to reply to me, please send your response to me directly, 
> DO NOT SEND TO THE LIST.

For someone who's "administered E-mail lists for two-plus decades," you don't 
seem to understand how they work.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Circular dependency with mingw64-x86_64-runtime

[Vince Rice]

> On May 2, 2018, at 10:22 AM, Mikhail Usenko wrote:
> 
> On Sun, 29 Apr 2018 19:16:17 -0700 (PDT)
> Steven Penny <...> wrote:
>> so "mingw64-x86_64-gcc-core" and "mingw64-x86_64-runtime" require each other
> 
> By the way this is not the only package group with circular dependencies.
> There are more in Cygwin distribution, that can be observed with cygcheck-dep:
> …


> On May 2, 2018, at 5:46 AM, JonY <10wa...@gmail.com> wrote:
> 
> …
> 
> That is not a problem affecting Cygwin.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: "setup-x86 --quiet-mode" problems

[Vince Rice]

> On Apr 19, 2018, at 11:31 AM, Ulli Horlacher wrote:
> 
> I have an update script which calls "setup-x86 --quiet-mode".
> So far, this works great, but now it tries to install a new mintty.exe,
> but one mintty still running (where I started setup-x86), so setup-x86
> kills this process... and setup-x86.exe is killed, too, which resulted in
> a damaged cygwin installation :-(
> 
> I was able to fix it by running setup-x86.exe via Windows Explorer (pu!).
> 
> How can I avoid this kind of problem in the future?
> 
> I tried it with:
> 
> setup-x86 --quiet-mode &
> sleep 1
> kill -9 $PPID
> 
> But setup-x86 was killed again, too.

The way you fixed it already — don't run setup under mintty (or dash or …).
Setup is not a cygwin program (it's not linked to cygwin1.dll).
It's safest to have all of your cygwin processes stopped when you run setup,
anyway, to prevent problems just like this.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Report

[Vince Rice]

> On Mar 29, 2018, at 5:36 PM, Erik Soderquist wrote:
> 
> On Thu, Mar 29, 2018 at 5:33 PM, Evil World  wrote:
>> 3 [main] john 7512 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
>> pointer.  Please report this problem
> 
> 
> We need more detail to be able to do anything... please refer to the
> instuctions at https://cygwin.com/problems.html


In that particular case, we don't. To the OP: see the FAQ.

(I'm dying to know why we're having a rash of these the last few months.)

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: GitForWindows vs. Cygwin

[Vince Rice]

> On Mar 21, 2018, at 3:49 AM, Thomas Wolff wrote:
> 
> On 21.03.2018 05:02, Vince Rice wrote:
>>> On Mar 20, 2018, at 7:24 PM, Tony Kelman wrote:
>>>>> Can anyone enlighten me about the relationship of "Git for Windows" to 
>>>>> Cygwin?
>>>> They are not related.
>>> Yes, they are.
>> No they're not.
> Tony explained well how they are related; Git for Windows is compiled in and 
> packaged with MSYS2 which is forked from Cygwin.

No, Tony explained how it's related to MSYS2. This isn't a MSYS2 mailing list.

>> It doesn't use cygwin, therefore it's not related. Since this is a cygwin 
>> mailing list,
>> that means the first two replies were correct — this isn't the place to 
>> discuss it.

Which means this still applies.

(And I just realized I quoted an email address last time. My apologies.)
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: GitForWindows vs. Cygwin

[Vince Rice]

> On Mar 20, 2018, at 7:24 PM, Tony Kelman  wrote:
> 
>>> Can anyone enlighten me about the relationship of "Git for Windows" to
>>> Cygwin?
>> 
>> They are not related.
> 
> Yes, they are.

No they're not.

It doesn't use cygwin, therefore it's not related. Since this is a cygwin 
mailing list,
that means the first two replies were correct — this isn't the place to discuss 
it.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: vi/vim editors stopped working after upgrade

[Vince Rice]

> On Mar 13, 2018, at 9:49 AM, d.kertz wrote:
> 
> After applying pending updates and adding the make package, the vi/vim 
> editors stopped working.  Running either vi or vim with or without the 
> hard-coded path just returns exit code 127:
> 
> …
> --
> Problem reports:   http://cygwin.com/problems.html
 ^^^
Start here, i.e. follow the directions on the problems page. That will give 
everyone needed information about your cygwin configuration.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [bug-gawk] gawk Regression: CR characters are not stripped on Windows

[Vince Rice]

> On Mar 5, 2018, at 2:58 PM, Andrey Repin wrote:
> 
> Greetings, 
> 
>> Corinna Vinschen wrote:
>> 
>>> Hi Arnold,
>>> 
>>> On Mar  5 06:36, arn...@skeeve.com wrote:
 Is there a way to distinguish cygwin from msys at compile time?
 I would not object to restoring the behavior for msys only.
>>> 
>>> __MSYS__ vs. __CYGWIN__
>>> 
>>> 
>>> Corinna
>> 
>> Excellent. I will probably do that, soon.
> 
> Keep in mind that you should avoid relying on __CYGWIN__ if possible.
> Only if certain POSIX mandated functionality could not be implemented at all
> using WinAPI you may go for this macro to work around compatibility issues.

https://cygwin.com/acronyms/#PCYMTNQREAIYR (see  above, which
wasn’t redacted in your reply).
(And Arnold, you did the same thing with Corinna’s email address.)

Keep in mind that it was Corinna answering the question. Given the subject of 
this
discussion, and that Corinna gave the answer, he doesn’t really need to “avoid
relying on __CYGWIN__”.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Setting a bash variable from backtick operator fails

[Vince Rice]

> On Feb 27, 2018, at 2:29 PM, Kaz Kylheku <920-082-4...@kylheku.com> wrote:
> 
> On 2018-02-27 09:10, Numien wrote:
>> Jürgen Wagner nailed it; it was my antivirus, and disabling the
>> shellcode injection check fixed it.
> 
> However, this time-wasting pattern of dealing with the issue by end users
> is not a good way.
> 
> A better approach would be to identify some common paterns of BLODA 
> interference
> and code a test which can detect the interference. This should be executed at
> startup by the Cygwin shell so that a diagnostic can be displayed to the user.
> 
>  WARNING: Cygwin detected interference from a "dodgy" application
>  such as anti-virus software. Your Cygwin installation may malfunction.
>  See http://

We await your patch, but you might want to search the archives first.
https://cygwin.com/acronyms/#SHTDI
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Future of 32-bit distro (was: rebase-4.4.3-1 regression: Too many DLLs for available address space)

[Vince Rice]

> On Jan 12, 2018, at 12:11 PM, Yaakov Selkowitz wrote:
> 
> On 2018-01-12 03:13, Corinna Vinschen wrote:
>> On Jan 11 22:52, Denis Excoffier wrote:
>>> The full list contains 8006 lines, i have the complete Cygwin 32bit 
>>> installation
>> 
>> The bottom line of this is, and it has been said before and I can't
>> stress this enough, we can't support this scenario at all, for the
>> simple fact that we have more DLLs than fit into the 32 bit address
>> space.  It's not much of a problem on 64 bit, but on 32 bit it's just
>> not feasible anymore.
>> 
>> Ultimately, You should (must) not install all of Cygwin on 32 bit, only
>> the set of stuff you need on top of the base category.  Or install 64
>> bit Cygwin.
> 
> If it is not possible for the entire 32-bit distribution to function as
> a whole, is it time to reconsider how much we provide for 32-bit?  And
> when can we just drop 32-bit entirely?

I have no dog in this hunt: I'm currently 64-bit (Windows and Cygwin). Having 
said that…

I think this is an extreme reaction. 32-bit Windows isn't going away anytime 
soon (as in not in the next five and probably more like ten years). There's 
nothing wrong with Cygwin-32. No one* needs to install all of Cygwin (And for 
those running 32-bit Cygwin on a 64-bit Windows, a giant rhetorical WHY?!?!). 
For many (most?) of us who use a relatively small part of Cygwin, there is no 
issue with the 32-bit address space. (I never had a problem when I ran 32-bit, 
which I did through last year (on a 32-bit Windows.)

For those that install everything out of laziness, well, that's not going to 
work anymore (and, from reports, hasn't worked very well for quite some time). 
But that's no reason to punish everyone else. There's also no reason to stop 
creating 32-bit packages. 32-bit Windows has limited address space. This isn't 
new, and it isn't news. If you run out of space, you run out of space. Switch 
to 64-bit or do without something. But it's not a reason to force everyone (on 
32-bit windows) to do without everything.


*Within three decimal points.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: setup's response to a "corrupt local copy"

[Vince Rice]

> On Dec 16, 2017, at 11:00 AM, Steven Penny wrote:
> 
> On Fri, 15 Dec 2017 09:50:44, Vince Rice wrote:
>> It's my computer. I don't want setup (or anything else) replacing files on it
>> it doesn't know about without at least asking whether that's what I want it 
>> to
>> do. Setup's current behavior is exactly what it should be, IMO. If, as has
>> been mentioned, someone wants to offer an *option* to replace, either with or
>> without a question, then great. But the default should be to leave something
>> it doesn't know about alone.
> 
> Thankfully we dont need your opinion on this matter, as we can simply fall 
> back
> to facts, as I will now do. Let us bring some sanity to this thread, shall we?

No, you never need any opinion that is in conflict with yours. I'm not going to
argue with you for a variety of reasons, not least because the decision is not
yours. You have shown you don't care what anyone else thinks on this or any
other issue, and believe me, the feeling is reciprocated. I offered my thoughts
for the people whose decision this really is, and I leave it with them.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: setup's response to a "corrupt local copy"

[Vince Rice]

> On Dec 15, 2017, at 7:33 AM, Steven Penny wrote:
> 
> On Thu, 14 Dec 2017 14:57:14, Ken Brown wrote:
>> And, as I said, it happens when setup is *preparing* to download files and
>> finds a corrupt copy already present in the local cache. In that context,
>> setup has no idea where the file came from.
> 
> the point is, *it doesnt matter*. it is not and shouldnt be setup.exe job to
> worry about the origin of files in the Local Package Directory.
> 
> Officially this directory, and the files below, are only created by setup.exe
> itself. If people are creating their own custom archives, then putting them in
> the Local Package Directory, *then* expecting them to work without a modified
> setup.ini, that is an error in judgment on their part.
> 
> my original point, and one that i stand by as ive seen no reasonable counter
> yet, is that setup.exe should assume control of the entire Local Package
> Directory and its contents. this includes removing rogue files that are in
> conflict with the current setup.ini. As Hans said:
> 
> http://cygwin.com/ml/cygwin/2017-12/msg00126.html
> 
> my viewpoint would be in concert with a typical "Git" workflow:
> 
> 1. make changes to working directory
> 2. add those changes to the index
> 
> with step 2 being the analogue to creating a custom setup.ini. setup.ini 
> should
> always have the final say on what a correct file is; so if you want a custom
> archive then you better tell setup.ini about it or otherwise risk it being
> nuked.

No, the point is it doesn't matter *to you*. As always, what you want doesn't 
necessarily reflect
what everyone else wants, no matter how often you repeat yourself or try to 
deflect others'
opinions as not being a "reasonable counter".

It's my computer. I don't want setup (or anything else) replacing files on it 
it doesn't know about
without at least asking whether that's what I want it to do. Setup's current 
behavior is exactly
what it should be, IMO. If, as has been mentioned, someone wants to offer an 
*option* to replace,
either with or without a question, then great. But the default should be to 
leave something it
doesn't know about alone.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: setup 2.883 release candidate - please test

[Vince Rice]

> On Dec 12, 2017, at 6:12 PM, Steven Penny wrote:
> 
> On Tue, 12 Dec 2017 08:04:09, Ken Brown wrote:
>> How can setup possibly automate this?  It doesn't know where the corrupt 
>> local tarball came from.  For example, suppose you sometimes build packages 
>> yourself for testing or debugging.  You keep them in your local repository, 
>> and you also upload them to a private repository on the internet so that you 
>> can easily install them on a different computer. You make a change and 
>> rebuild the package, but you forget to replace all copies of it.  setup 
>> can't know which version is the correct one.  And it certainly shouldn't be 
>> deleting your files because it thinks they're corrupt.
> 
> No, this is not right. If you are building packages yourself, then you should
> have a custom setup.ini to match, example:
> 
> http://matzeri.altervista.org/x86_64
> 
> so that in any case, setup.ini has the final say of what a correct archive is,
> via the SHA512. If a file in the local repo doesnt match either because:
> 
> - file size 0
> - file size less than proper size because of interrupted download
> - SHA mismatch because of custom build
> 
> said file should be removed and redownloaded by setup.exe. if you are building
> custom archives, then you should also be making custom setup.ini.

Where is that stated as a requirement? I don't see it anywhere, and I don't 
agree that it should be one. Ken is correct on this, IMO.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Requested report

[Vince Rice]

> On Dec 1, 2017, at 9:31 PM, cyg Simple wrote:
> 
> On 12/1/2017 10:35 AM, Vince Rice wrote:
>>> On Dec 1, 2017, at 8:55 AM, cyg Simple wrote:
>>> 
>>> On 11/30/2017 11:41 PM, Richard Mateosian wrote:
>>>> Thanks. I wasn't actually using Cygwin, but Ruby apparently does so under
>>>> the covers. Or maybe my path leads it astray, because I used to use Cygwin
>>>> -- a long time ago.   ...RM
>>>> 
>>> 
>>> You should not put Cygwin in your Windows PATH environment at the system
>>> level or user levels.  If you need it during a command shell session,
>>> add it after you start the command shell.  I've never heard that Ruby
>>> intentionally uses Cygwin.
>> 
>> What? I've had cygwin in my path since the B19 days (that's right, even 
>> *before* the infamous B20).
>> I regularly (and almost exclusively) use cygwin tools in the command 
>> processor; I have a mintty
>> session open, but only use it when I need to do shell-related things.
>> 
> 
> So?  You've just been lucky to not have had an issue.  Adding Cygwin to
> the Windows PATH has been ill advised since the B19 days.  Other tools
> are bound to distribute Cygwin and interfere with what you have
> installed.  It happens all the time.  Not putting Cygwin's path directly
> in the Windows PATH helps resolve some of the issues caused by multiple
> installs of Cygwin.  However, it doesn't eliminate all of the issue.

No, I haven’t been “lucky” and no, nothing is “bound to”. I’ve never installed 
a single tool that
distributes cygwin.

>> There's no reason not to have Cygwin in the Windows path, and lots of 
>> reasons to do so
>> (grep, cat, tail, head, etc., etc.).
> 
> There's lots of reasons to not do so as I've mentioned above.  Yes, it's
> nice to have these in a Windows command session.  You could start a
> command window via a .bat file whose purpose is to set PATH before
> starting cmd.exe.  This keeps other tools from seeing it.

You didn’t mention “lots of reasons”. You mentioned one reason — multiple 
installs of cygwin.
And you admitted that not having cygwin in the path doesn’t even solve all of 
the problems
that might arise from that issue.

If you have multiple cygwin installations, then solve that problem. There’s no 
reason to punish
yourself for something that *might* happen (and which has no reason to happen). 
And, as I
mentioned (with examples), there *are* lots of reasons TO put it in your path.

So, again, there is nothing wrong with having cygwin in the Windows path. It is 
silly to install
cygwin and then not be able to use the tools in day-to-day life in the command 
processor.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Requested report

[Vince Rice]

> On Dec 1, 2017, at 8:55 AM, cyg Simple wrote:
> 
> On 11/30/2017 11:41 PM, Richard Mateosian wrote:
>> Thanks. I wasn't actually using Cygwin, but Ruby apparently does so under
>> the covers. Or maybe my path leads it astray, because I used to use Cygwin
>> -- a long time ago.   ...RM
>> 
> 
> You should not put Cygwin in your Windows PATH environment at the system
> level or user levels.  If you need it during a command shell session,
> add it after you start the command shell.  I've never heard that Ruby
> intentionally uses Cygwin.

What? I've had cygwin in my path since the B19 days (that's right, even 
*before* the infamous B20). I regularly (and almost exclusively) use cygwin 
tools in the command processor; I have a mintty session open, but only use it 
when I need to do shell-related things.

There's no reason not to have Cygwin in the Windows path, and lots of reasons 
to do so (grep, cat, tail, head, etc., etc.).


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: setup.ini has multiple "prev" entries ... Why?

[Vince Rice]

> On Nov 5, 2017, at 6:48 AM, Houder wrote:
> 
> Hi John (Turney),
> 
> After I had downloaded and exercised setup version 2.882, I noticed
> that setup.ini has multiple (2?) "prev" entries per package ...
> 
> Why? Did I miss one of your announcements mentioning this change?
> 
> Regards,
> 
> Henri
> 
> Announcements (setup):
> 
> - https://cygwin.com/ml/cygwin/2017-05/msg00313.html -- 2.879
> - https://cygwin.com/ml/cygwin/2017-06/msg00166.html -- 2.880
> - https://cygwin.com/ml/cygwin/2017-07/msg00072.html -- 2.881
> - https://cygwin.com/ml/cygwin/2017-10/msg00285.html -- 2.882
> 
> Description (specification?) of setup.ini:
> 
> - https://sourceware.org/cygwin-apps/setup.ini.html

It's Jon, and yes, you did. I'm on the way out the door, but you can search the 
archives. The discussion was on apps, IIRC, and was in the last month or two.

Not Jon
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin on Win10 much slower than Win7

[Vince Rice]

> On Nov 2, 2017, at 12:15 PM, Nellis, Kenneth  
> wrote:
> …
> I first noticed the problem with cygpath:
> On Win 7:
> 
> $ time cygpath abc
> abc
> 
> real0m0.016s
> user0m0.000s
> sys 0m0.015s
> $
> 
> On Win 10:
> 
> $ time cygpath abc
> abc
> 
> real0m0.105s
> user0m0.000s
> sys 0m0.062s

I have Win7x64 and Win10x64 VM's on the same physical Mac, both configured 
identically WRT disk, memory, etc. Both were just updated from setup, so are 
running same version of cygwin. Both were on newly started mintty's, and, in 
the case of Win7, just-started VM. (My Win10 VM has been up for a day or so.)

I ran cygpath 100 times in a loop (for i in {1..100} …), using the loop 
variable as the parameter to cygpath. I ran each loop three times, then 
averaged the times. Thus the times below are for 100 cygpaths.

On Win7, times were .790/.145/.396.
On Win10, times were 1.340/.350/.650.

Not enough for me to worry about, but it might be for you.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Which is it -pc- or -unknown-

[Vince Rice]

> On Oct 19, 2017, at 3:21 PM, cyg Simple <cygsim...@gmail.com> wrote:
> 
> On 10/19/2017 4:02 PM, Vince Rice wrote:
>>> On Oct 19, 2017, at 2:08 PM, cyg Simple <cygsim...@gmail.com> wrote:
>>> 
>>> On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote:
>>>> 
>>>> When you *really* need to use --build and/or --host, then you need to
>>>> use x86_64-pc-cygwin, as that is our chosen name.
>>> 
>>> Then config.guess needs to change to match the chosen name!!
>>> 
>>> Why confuse everyone?  Make up your mind and choose one.  I can submit
>>> the patches to the config maintainer.
>> 
>> It's not confusing everyone. You're the only one jumping up and down, you 
>> have refused to provide information needed to help you, and in spite of 
>> that, Yaakov has given you a reasonable guess at a solution.
>> 
> 
> I'm not providing the name of the package because I don't need help
> configuring it and I don't want the discussion to become how to do that.
> 
>> I can only conclude you just like to hear yourself scream. If only we were 
>> in space…
> 
> I would float near you and SCREAM in your ear.  At least I have Brian
> thinking that config.guess needs to change so it has helped some.
> 
> So, Vince, what is the triplet you like for x86_64 Cygwin?

You missed the point of the joke, just like you've missed the point of this 
entire conversation. I'll leave you to Yaakov.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Which is it -pc- or -unknown-

[Vince Rice]

> On Oct 19, 2017, at 2:08 PM, cyg Simple  wrote:
> 
> On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote:
>> 
>> When you *really* need to use --build and/or --host, then you need to
>> use x86_64-pc-cygwin, as that is our chosen name.
> 
> Then config.guess needs to change to match the chosen name!!
> 
> Why confuse everyone?  Make up your mind and choose one.  I can submit
> the patches to the config maintainer.

It's not confusing everyone. You're the only one jumping up and down, you have 
refused to provide information needed to help you, and in spite of that, Yaakov 
has given you a reasonable guess at a solution.

I can only conclude you just like to hear yourself scream. If only we were in 
space…
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Mercurial update needed for security fixes

[Vince Rice]

> On Sep 25, 2017, at 12:31 PM, Andy Moreton  wrote:
> 
> On Mon 18 Sep 2017, Ken Brown wrote:
> 
>> On 9/18/2017 11:27 AM, Andy Moreton wrote:
>>> On Thu 17 Aug 2017, Andy Moreton wrote:
>>> 
>>> Ping?
>>> 
 Hi,
 
 Can the mercurial maintainer please update to upstream Hg 4.3.1, to get
 the fixes for CVE-2017-1000115 and CVE-2017-1000116.
>> 
>> I don't know if he reads the list.  I'm adding him to the Cc.
>> 
>> Ken
> 
> Still no response. If the maintiner does not read the project list or
> respond to email, then all of his packages are effectively abandoned.
> 
> Can we please have a *security update* for mercurial ?

And if "effectively abandoned," then there's no one to update them. Are you 
volunteering?
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Compile/run problems on cygwin not solved by going to cygwin64

[Vince Rice]

> On 28 June 2017 at 22:02, Vince Rice wrote:
>>> On Jun 28, 2017, at 3:00 PM, Wouter van Doorn wrote:
>>> …
>>> I can't give the strace output, as 'strace ./hello.exe' causes an
>>> immediate segmentation fault. No idea why, but not something I'm going
>>> to put energy into right now.
>> 
>> You should. If strace won't run, you have a problem, and I would bet the 
>> odds of the problems being related (or the same) is pretty high.
> 
> On Jun 28, 2017, at 4:25 PM, Wouter van Doorn wrote:
> 
> Hi Vince,
> 
> If they are related, then solving the problem that's my real current
> issue will make the strace one go away. If they are not, then I am
> about to start a second wild goose chase. Sticking with the problem
> that I am immersed in now in the hope to get that resolved seems to be
> my best bet.
> 
> I would like the strace issue to go away, of course, and if someone
> has the magic bullet for it I am only too happy to get that issue out
> of the way!

Please don't https://cygwin.com/acronyms/#TOFU. And 
https://cygwin.com/acronyms/#PCYMTNQREAIYR.

My guess is it would be easier to figure out a segmentation fault than the 
other. Up to you. 


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Compile/run problems on cygwin not solved by going to cygwin64

[Vince Rice]

> On Jun 28, 2017, at 3:00 PM, Wouter van Doorn wrote:
> …
> I can't give the strace output, as 'strace ./hello.exe' causes an
> immediate segmentation fault. No idea why, but not something I'm going
> to put energy into right now.

You should. If strace won't run, you have a problem, and I would bet the odds 
of the problems being related (or the same) is pretty high.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts

[Vince Rice]

> On Jun 8, 2017, at 3:50 AM, Soegtrop, Michael wrote:
> 
> Dear Eric,
> 
>> No, the documented behavior is that CR-LF is converted to LF only for text-
>> mounted files; but pipelines are default binary-mounted.  If you want to 
>> strip
>> CR from a pipeline, then make it explicit.
>> 
>>> var=$( prog | sed .)
>> 
>> Rewrite that to var=$( prog | tr -d '\r' | sed .)
> 
> I have two problems with this:
> 
> 1.) I build many (~ 50) unix libs and tools MinGW cross on cygwin from 
> sources and this breaks many of the configure and other scripts. Feeding back 
> the fixes to the individual lib/tool maintainers will take quite some time 
> and also results in lengthy discussion why they should care about crappy DOS 
> artefacts at all. A compatibility option via environment variable would have 
> been nice.
> 
> 2.) It is very hard to interpret the documentation in this way. I am citing 
> from https://www.gnu.org/software/sed/manual/sed.html:
> 
> -b --binary  
> This option is available on every platform, but is only effective where the 
> operating system makes a distinction between text files and binary files. 
> When such a distinction is made—as is the case for MS-DOS, Windows, 
> Cygwin—text files are composed of lines separated by a carriage return and a 
> line feed character, and sed does not see the ending CR. When this option is 
> specified, sed will open input files in binary mode, thus not requesting this 
> special processing and considering lines to end at a line feed.
> 
> This doesn't say what is treated as a text file and what is treated as a 
> binary file and one can reasonably assume that a text tool like sed opens 
> everything not explicitly declared as binary as text, if a documented option 
> like -b exists.
> 
> This cygwin sed behavior is documented in 
> https://cygwin.com/cygwin-ug-net/using-textbinary.html but I wouldn't expect 
> people using sed on cygwin will find this.
> 
> In summary I would say that the behavior of sed in cygwin is documented in 
> the cygwin documentation, but it is contradicting the documentation of sed 
> itself, and possibly the intended function of sed as a text processing tool.
> 
> I must admit that building Linux stuff for MinGW cross on cygwin works 
> substantially better than doing this on MSys/MSys2. The number of patches I 
> need is small, so the decisions the cygwin team took seem to be the right 
> ones. But this change adds at least one order of magnitude in my "number of 
> patches required" statistics. 

Use binary mounts. The root of the problem is using text mounts in the first 
place.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ATTN: Yaakov Selkowitz / PHP maintainer] Re: Composer segfault on multiple configurations

[Vince Rice]

>> On May 30, 2017, at 11:47 AM, Richard H Lee wrote:
>> 
>> Yaakov,
>> 
>> I probably should have copied you in on the last message to get your 
>> attention.
>> 
>> It's just a simple patch to fix this page size issue with php on Cygwin. 
>> Would be grateful if you could review and possibly accept this patch, as it 
>> has been confirmed and does affect several people.

> On May 30, 2017, at 1:59 PM, Vince Rice <vr...@solidrocksystems.com> wrote:
> 
> I'm sure he will tell you himself soon enough, but no you shouldn't have. 
> Emails re packages should go to the list, not to the package maintainers 
> directly. If you want to ping a previous message, ping the list, not the 
> person.

And of course I realized too late I TOFU'd… Sorry about that.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ATTN: Yaakov Selkowitz / PHP maintainer] Re: Composer segfault on multiple configurations

[Vince Rice]

I'm sure he will tell you himself soon enough, but no you shouldn't have. 
Emails re packages should go to the list, not to the package maintainers 
directly. If you want to ping a previous message, ping the list, not the person.


> On May 30, 2017, at 11:47 AM, Richard H Lee wrote:
> 
> Yaakov,
> 
> I probably should have copied you in on the last message to get your 
> attention.
> 
> It's just a simple patch to fix this page size issue with php on Cygwin. 
> Would be grateful if you could review and possibly accept this patch, as it 
> has been confirmed and does affect several people.
> 
> Richard
> 


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Moving forward from cygwinports

[Vince Rice]

>> On Tue, Apr 4, 2017 at 12:08 PM, Yaakov Selkowitz wrote:
>>> On 2017-04-04 05:38, Chris Davies wrote:
 
 As an example, my use case is Perl-DBD-Sybase from about three weeks
 ago, which works beautifully but is not in the main repository. Short of
 moving to a Linux-based platform I'm now not sure how to proceed. Could
 someone enlighten me, please?
>>> 
>>> 
>>> You could try building it yourself:
>>> 
>>> https://github.com/cygwinports-extras/perl-DBD-Sybase
>>> 
>>> You'll need cygport, perl, and libsybdb-devel.  If it weren't for that
>>> patch, you could also just install it from cpan.
>> 
>> On Apr 4, 2017, at 12:58 PM, Wayne Barron wrote:
>> 
>> @Chris,
>> I know that Cygwin and Cygport are not the same.
>> I was asking if you could perhaps share information on how to properly
>> install Cygport.
>> 
>> I downloaded it from here.
>> https://github.com/cygwinports/cygport
>> 
>> In the Cygwin, it had a Windows 32 or 64-bit installer.
>> This does not come with such.

First, please don't https://cygwin.com/acronyms/#TOFU.
Second, https://cygwin.com/acronyms/#PCYMTNQREAIYR.

You didn't have to download it from anywhere. Cygport is a Cygwin package, it 
can/should be installed from Cygwin's setup.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin - Install Liquidsoap for Shoutcast or Icecast

[Vince Rice]

>>> On Mon, Mar 27, 2017 at 10:31 AM, Andrew Schulman
>>> You should start at https://cygwin.com/cgi-bin2/package-grep.cgi to see if
>>> someone has already packaged it for Cygwin.
>>> 
>>> If no one has, then you can either build and install it yourself, or try to
>>> convince someone else to do it.  Since you're the one who wants it, you're
>>> most likely to get it done by doing it yourself.  If you succeed,
>>> considering offering it as a new package (https://cygwin.com/setup.html).
>>> 
>>> Andrew
>> 
>> On Mon, Mar 27, 2017 at 12:35 PM, Wayne Barron wrote:
>> Hey, Andrew.
>> I did a search on the site, and nothing came up with it.
>> So, it looks like I will be on my own.
>> 
>> I love new challenges, so I will probably look in on it a little more
>> throughout the week.
>> 
> On Mar 27, 2017, at 11:44 AM, Wayne Barron wrote:
> 
> OK, I found out that I needed to get cygport
> http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/media/liquidsoap/
> I downloaded the file and looked it over.
> I will try to install it later on, today, and see if I can get it to,
> at least. Install.

Excellent. But please don't https://cygwin.com/acronyms/#TOFU here. (And please 
watch the https://cygwin.com/acronyms/#PCYMNTNQREAIY as well, even when it's 
your own.)


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

[Vince Rice]

> On Mar 1, 2017, at 11:27 PM, Steven Penny wrote:
> 
> On Wed, 1 Mar 2017 21:46:38, Vince Rice wrote:
>> There are valid reasons (which several others have made) not to force others
>> to use it.
> 
> Have they though? I have not seen anyone save Eric (including you) make a 
> valid
> argument beyond "I like it the old way".

Then you haven't been paying attention.
And I didn't even attempt to make an argument one way or the other, 
except to say stop arguing. The horse is dead.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

[Vince Rice]

> On Mar 1, 2017, at 6:22 PM, Steven Penny  wrote:
> 
> On Wed, 1 Mar 2017 09:42:27, cyg Simple wrote:
>> Oh but it is.  We're discussing the bike shed named /bin/sh.
>> One of the color names is bash the other is dash; it's still the same
>> bike shed.
> 
> I see, when you realize your argument does not hold water, you resort to name
> calling. Here are concrete arguments:
> 
> 1. Debian uses Dash as /bin/sh
> 2. Ubuntu uses Dash as /bin/sh
> 3. The POSIX standard defines sh, and by definition Dash is closer to this 
> than
>  Bash
> 4. Dash is 3-5 times faster than Bash
> 5. While it might be upsetting to some users, _they_ have made an error in
>  assuming Bash is /bin/sh, it would not be our error in switching to a shell
>  that is closer to POSIX sh
> 
> Now, perhaps you can add a constructive post, or do you want to start with 
> some
> "yo momma" jokes?

He didn't call anyone names. He said that was a bike shed argument. Which is 
getting more accurate the longer this "discussion" goes on.

You've argued your point. If you like dash, then use it. There are valid 
reasons (which several others have made) not to force others to use it.

The decision isn't yours. Or mine. And the ones whose decision it is will 
switch or they won't.

Let's move on.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

[Vince Rice]

> On Feb 23, 2017, at 5:04 PM, Eliot Moss  wrote:
> 
> On 2/23/2017 6:01 PM, Tony Kelman wrote:
>>> The big question remains, where this speed boost coming from?
>>> Is this a startup time? Or some internal slowness?
>>> Because in latter case, given your STC, this is a bash issue and should be
>>> reported upstream.
>> 
>> Dunno what you meant by STC,
> 
> Indeed, this gives around 20 possibilities, none of which seem to fit:
> 
> http://www.acronymfinder.com/Slang/STC.html

If it's used here, then the first place to look is on the Cygwin acronym page.

https://cygwin.com/acronyms/#STC
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Console buffer width always 1 column less than setting

[Vince Rice]

> On Feb 6, 2017, at 11:43 AM, Lee Dilkie wrote:
> 
> On 2/5/2017 3:59 PM, Steven Penny wrote:
>> On Sun, 5 Feb 2017 14:12:04, Vince Rice wrote:
>>>> On Feb 5, 2017, at 1:53 PM, Steven Penny  wrote:
>> 
>> Please fix your email client. You should not be quoting people’s email 
>> directly.
>> 
> 
> that's just silly. Anyone with access to this public list has your email 
> address when you posted.
> 
> The guy was just trying to help you with your issue, and you come across as a 
> dork.

The rules on this list are to not quote email addresses, I just missed it when 
I posted.
Anyone subscribed to the list may have it, but we don't want them the archives 
for a bot to go through and harvest.
Which may or may not affect your opinion…
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Console buffer width always 1 column less than setting

[Vince Rice]

> On Feb 5, 2017, at 1:53 PM, Steven Penny  wrote:
> 
> This issue has bothered me for some time, but I never got around to reporting
> it. The issue is that the Cygwin buffer via Cygwin.bat is always 1 less than
> what is set.
> 
> For example, the default buffer is 80 columns, same as the window size. Cygwin
> window size is correct, but that last column can never be accessed, it always
> stays blank and the text wraps on column 79. Here is a test:
> 
> 1. Enter spaces until you reach next line, this way the prompt is not adding 
> to
>   our count
> 
> 2. Enter:
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> 
> Now with cmd.exe, you get all 80 characters on the same line, but with Cygwin 
> it
> always wraps 1 character before. I don’t remember this always being the case, 
> I
> believe it used to work correct 1-2 years ago.

I'm on Win7 64-bit with 64-bit Cygwin 2.6.0(0.304/5/3).

To clarify, the above occurs with bash 4.3.46(7) in a Windows console, and I 
see the behavior there as well.
This does not happen with the same bash in mintty 2.7, so it appears to be 
specific to the combination of bash and the Windows console.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.1-1, libreadline-devel-7.0.1-1, bash-4.4.5-1

[Vince Rice]

> On Jan 14, 2017, at 6:27 PM, Steven Penny  wrote:
> 
> On Sat, 14 Jan 2017 15:47:57, Eric Blake wrote:
>> Okay, so you've isolated the problem to readline.  In all likelihood, it
>> is an unintentional upstream regression; now we need to figure out what
>> is causing the change in behavior.
> 
> I would like to make it very clear that I will not be digging around in the
> readline source code to fix this. I think I have gone above and beyond in
> diagnosing this for you, so if you can take over it would be much appreciated.

It's times like this I wish CGF were still here…
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin 1.7.0.58 with Windows 2012

[Vince Rice]

Please do not https://cygwin.com/acronyms/#TOFU.

> On Tue, Jan 3, 2017 at 9:29 PM, Andrey Repin  wrote:
>> Greetings, Rashi Singhal!
>> 
>>> Will Cygwin version 1.7.0.58 will be supported in Windows 2012?
>> 
>> 1.7 is not supported. At all.
>> 
>>> Or where i can get information regarding Cygwin version as Windows OS 
>>> support
>> 
>> Right on the cygwin.com website.
>> Short version is that all currently supported Windows versions are supported.

> On Jan 4, 2017, at 9:16 AM, Rashi Singhal  wrote:
> 
> Thanks for reply.
> 
> I did not got list of supported version in cygwin.com website.

>From the very first sentence on the main page, after the "What it is/isn't" 
>section…
> The Cygwin DLL currently works with all recent, commercially released x86 32 
> bit and 64 bit versions of Windows, starting with Windows Vista.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN_NOWINPATH (was Re: /etc/profile: avoid multiple /usr/bin in PATH)

[Vince Rice]

> On Nov 17, 2016, at 12:04 PM, Francis Litterio  wrote:
> 
> On 9/8/2016 8:07 AM, Corinna Vinschen wrote:
>> On Sep  5 10:36, Doug Henderson wrote:
> 
>>> I set CYGWIN_NOWINPATH=1 in my user environment variables, i.e. in
>>> registry, not in a cmd shell. I expect it needs to be seen when the
>>> first cygwin1.dll instance starts, so you would need to stop all
>>> cygwin processes and servers, just like you do when you run the cygwin
>>> setup, for this to be effective.
>> 
>> Ouch, no!  Environment variables are handed down from parent to child
>> process.  On all systems, be it Windows, Cygwin, Linux or whatever.
>> There's *no* other magic involved.  It's just a bunch of strings
>> inherited from the parent process.
> 
> Yes, but Explorer induces confusion as follows (seen on Windows 7):
> 
> 1. Open a Command Prompt from the Start Menu (so cmd.exe is a child of 
> explorer.exe), and enter "echo %foobar%".  See output "%foobar%". Environment 
> variable foobar is not set.
> 
> 2. Enter "setx foobar 99" to add foobar to the persistent environment 
> variables in the Registry.
> 
> 3. Enter "echo %foobar%" again in the same Command Prompt.  Still see 
> "%foobar%".  No change in that process's environment, as expected.
> 
> 4. Launch a new Command Prompt from the Start Menu.  Enter "echo %foobar%".  
> See "99".  Clearly, Explorer updated it's environment from the Registry and 
> passed the change to the new child process.
> 
> This leads people to think that environment variables stored in the Registry 
> are special, when in fact it's Explorer's doing.

None of which has anything to do with needing to re-start cygwin, which was 
Corinna's point.
And, for the record, Explorer doesn't induce any confusion at all. A new 
process gets its environment when it starts. Pretty simple to understand.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: CancelSynchronousIo could not be located in the dynamic link library KERNEL32.dll

[Vince Rice]

> On Oct 24, 2016, at 10:28 AM, Keith Williams  wrote:
> 
> I've read the FAQ. I feel the matter isn't resolved and I haven't been able 
> to use Cywin/XP for a while/
> 
> Has anyone tried installing Cygwin on Windows XP? The installation doesn't 
> work because the applications seem to be linked with newer Windows run-time 
> libs. Bash and dash do not work for example, they're looking for the missing 
> kernel call, CancelSynchronousIo.
> 
> I don't seem able to go back to a working system from the upgrade, and a new 
> installation doesn't work.
> 
> Given that 32bit Windows 7 and Vista have been around for years, why was it 
> decided to drop support for Windows XP?  Presumably, there's nothing much to 
> be gained by doing this.

XP support was dropped in 2.6. If you upgraded to 2.6.x on XP, you didn’t read 
the release notes very well.

> I uploaded a new Cygwin release 2.6.0-1.
> 
> Please note that this release won't work on Windows XP and Windows
> Server 2003 or 2003 R2.  At least Windows Vista or Windows Server 2008
> are required.


Google “cygwin time machine”; it may get you what you need.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Native symlinks and setup.exe

[Vince Rice]

Please don’t https://cygwin.com/acronyms/#TOFU.

> On 4 October 2016 at 17:56, Gerrit Haase  wrote:
>> Hello Gene,
>> 
>> in my opinion, it is not a setup.exe or tar problem, but I think
>> packages should not include symlinks at all. All can be created
>> postinstallation by the postinstall script, inside Cygwin and the
>> users environment it is running on.
>> 
>> Obviously, a political discussion is required, to decide whether it is
>> ok, as is, or if a change in package logic would have benefits.
> 
> On Oct 4, 2016, at 3:41 PM, Gene Pavlovsky  wrote:
> 
> That is a good point as well, however I'm not sure what are the
> opinions of Cygwin's "elders".
> Would everyone vote for creating a policy like that and pushing it to
> the package maintainers?
> A political discussion is what I'm trying to start here :)

I am not a “Cygwin elder,” nor do I play one on TV.

Packages are going to include simlinks because packages have simlinks in them.
The goal of Cygwin is to minimize the work that has to be done to port a 
package.
For example, the gawk package includes a link to awk. And so forth.

I don’t see that changing. And, as already noted, setup isn’t a Cygwin program,
so it knows (and cares) nothing about cygwin environment variables.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: setup.exe (Release 2.876)

[Vince Rice]

> On Sep 10, 2016, at 12:07 PM, Thomas Wolff  wrote:
> 
> Am 10.09.2016 um 07:57 schrieb Wayne Davison:
>> On Fri, Sep 9, 2016 at 2:35 AM, Yaakov Selkowitz  
>> wrote:
>>> A new version of Setup, release 2.876, has been uploaded to [...]
>> The change from a button to a dropdown list for the View seems like a
>> nice usability improvement,
> I disagree with that, because what I want to check first is the Pending view, 
> to see what's supposed to be updated anyway. This is more fiddly now than it 
> was. Perhaps separate buttons (radio buttons) for the views would be best.

I disagree with that. A dropdown list is exactly the right treatment for a list 
o’ things.
But, and I realize SHTDI, and that someone is not me, perhaps a “for the 
future” item would be a way to specify which view to start on, either through a 
command line option or through a kept choice.

I also agree with OP’s request for a hotkey on View, although standard behavior 
of such a hotkey would be to position the cursor in the dropdown and open it, 
not automatically choose the “next” item in the dropdown. I can see the benefit 
of the latter, though.

But, more importantly (for me, anyway), can we please put the dropdown in the 
tab list? Tabbing out of the pick list goes to the Search text box, as it 
should. Shift-tabbing from the Search text box to go back to the Dropdown, 
however, instead goes to the Cancel button at the bottom of the page. If we can 
tab out of it, we should be able to tab (or shift-tab) back into it.

Finally, a question — what is “Picked”? It wasn’t one of the previous choices, 
and I can’t figure out what it’s supposed to represent.
I have seven items on that page, all of which say “Keep”, and which in no way 
represents all of what I’ve installed. I have nothing on Pending, having 
updated in my previous session. (Even then, I only had one thing to update, but 
still had the same seven items on “Picked”.) I thought it might be things that 
setup “picked” for me based on the choices I’ve made, but that doesn’t appear 
to be true, either, based on the above — not only am I not installing anything, 
but all of the items say “Keep”.

On the pedantic side, why is “Category” the starting view, but the last item in 
the dropdown?

Thanks for tackling setup, Jon. From all reports here it’s something of a 
nightmare. :)
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: /etc/profile: avoid multiple /usr/bin in PATH

[Vince Rice]

>> Note that CYGWIN_NOWINPATH is still undocumented, except in the email
>> archives. See, e.g.
>> 
>>https://www.google.ca/search?q=CYGWIN_NOWINPATH+site:cygwin.com
>> 
>> CYGWIN_USEWINPATH is also undocumented, except in a non-cygwin.com
>> email archive.
> 
> It's documented right in /etc/profile for the moment.

Well, “documented” is a little strong. “Used” is more accurate. There are no 
comments as to what it is or what it’s used for, at least in my /etc/profile 
(last updated in June).


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: Cygwin 2.6.0-1

[Vince Rice]

> As the 84 year old guy who helps my 70 year old dad …

H. Is one of you Benjamin Button? :)


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

[Vince Rice]

> 
> On Aug 9, 2016, at 3:41 PM, Warren Young  wrote:
> 
> On Aug 9, 2016, at 2:07 AM, Herbert Stocker  wrote:
>> 
>> On 8/9/2016 2:45 AM, Michel LaBarre wrote:
>>> It could very well be that, as one response to me on this thread
>>> alluded, CYGWIN's role is to provide the equivalent of an isolated
>>> POSIX VM under Windows without the VM.
>> 
>> ...CYGWIN is *not* an isolated POSIX environment. It brings
>> POSIX to the OS named "Windows”…
> 
> In addition to Herbert’s points, I also want to point out that bidirectional 
> Windows interoperability is a key differentiator for Cygwin vs. “Bash on 
> Windows,” a.k.a. WSL:
> 
>  https://msdn.microsoft.com/commandline/wsl/
> 
> I’ve seen several of these isolationist moves over the years I’ve been using 
> Cygwin, and I think they are essentially harmful to Cygwin.  The more you 
> promote Cygwin as being its own little world, the easier it is to replace it 
> with something that truly is isolated: WSL, a Linux VM, or even a Mac.
> 
> (If you’re wondering why Macs belong on that list, consider that if you’ve 
> been using Cygwin on Windows because you don’t find the Linux desktop 
> compelling, when it comes time to buy your next desktop, why not choose a 
> first-class desktop computing platform where the Unix command line is not an 
> afterthought, kept isolated as much as possible?)
> 
> I do not mean, by this comment, to endorse this idea of implementing PATHEXT 
> in Cygwin.  In fact, I’ve made profitable use of the current situation by 
> creating foo.bat and a shell script called foo, which gives me a single 
> command that does the same task under cmd.exe and Cygwin’s shell, using 
> mechanisms native to each.  I would not particularly want that ability to 
> disappear.
> 
> This is not a simple question of “should Cygwin integrate with Windows?”  
> Your change implies a broad impact which should be carefully considered.
> 
> It sounds like you just want Cygwin to work like MKS, Michael, which isn’t 
> going to happen.  Cygwin has ~20 years of independent development, all of 
> which were in parallel with MKS.  If the developers of Cygwin had wanted to 
> clone MKS, they would have done so long before now.

I have a Mac. I have to run a Windows VM on it due to work software 
requirements. (Among other things, there’s still not a really good SSMS 
replacement.) Cygwin is still the first thing I install on a VM.

AFAIC, Cygwin is the perfect blend. I can run Cygwin programs in bash, or I can 
run Cygwin programs in my Windows command shell choice. That isn’t true of WSL, 
a Linux VM, or my terminal shell in OSX.
And, as I said earlier in this thread, in a dozen years of using Cygwin, I’ve 
never once missed not having PATHEXT in bash. _In bash_, I think PATHEXT would 
cause far (FAR) more harm than good.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

[Vince Rice]

The choice to use slashes as qualifers instead of dashes was “just to be 
different” as well.

This was ’78-81. VMS wasn’t in Gates’ mind at the time.


> On Aug 5, 2016, at 1:14 PM, Nellis, Kenneth  wrote:
> 
> From: Erik Soderquist
>> ... DOS did a lot of things
>> against already established conventions, such as using a backslash
>> instead of a forward slash as the directory separator, just "to be
>> different".
> 
> Not just to be different, but to distinguish from slashes used as 
> command qualifiers (a la VMS), don't you think?
> 
> --Ken Nellis


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

[Vince Rice]

> On Aug 3, 2016, at 8:43 PM, Michel LaBarre wrote:
> 
> The CYGWIN site makes it quite difficult to discern how somebody can report
> an issue or comment.

If you think a plainly labeled “Reporting Problems” and “Mailing Lists” in the 
prominent sidebar is difficult, then I’m afraid it’s only going to get worse 
from here.

> Problem 1:  Cygwin does not support PATHEXT and really should.
> 
> Fundamental reason:  from the Cygwin FAQ - What is it?  "Cygwin is a
> distribution of popular GNU and other Open Source tools running on Microsoft
> Windows.”

> PATHEXT is as fundamental component of Windows program execution as PATH.

“To you.” Almost every sentence in that paragraph should have “to you” at the 
end. I’ve used Cygwin for over a dozen years, and I have never once missed 
having PATHEXT in mintty/bash.
You can continue to use PATHEXT to your heart’s content in CMD.
Bash isn’t CMD.

> The published solutions in the various FAQs are not satisfactory.

“To you."

> Problem 2:  Cygwin does not support CR-LF delimiters.

Yes it does, although it is heartily suggested they be left behind (pretty much 
any Windows program can handle Unix line endings but Notepad, and anyone using 
Notepad has bigger issues than line endings).
Text mounts can be created in Cygwin (although, again, not suggested). There 
are also a few (non-standard) things in Cygwin’s bash to try to handle CRLF 
scripts. You can search the archives for more information.

> CYGWIN could be a very smart supplement to that requirement.
> …
> If CYGWIN  could mitigate some of the recurring impediments new users trip 
> over, (as evidenced by the many web-references to both my problems) it would 
> facilitate its adoption by both Unix and non-Unix types.  

No, Cygwin _is_ a very smart supplement to that requirement. You talk as if 
Cygwin just showed up last week. It’s been around for almost twenty years, is 
widely used and widely respected.

> I disagree completely.  If you are in an interactive bash, running on a 
> Windows computer, you sure as hell expect to be able to run "foo.bat" by 
> typing "foo”.

No, _you_ expect to. I don’t. I know that Bash isn’t CMD.

Cygwin is providing a Posix environment on Windows. If you want a Windows 
environment on Windows, then use CMD. Almost all of Cygwin’s supplied programs 
work perfectly well in CMD, as long as you remember they’re providing a Posix 
environment and therefore need Unix paths, etc.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: CVS version 32 vs 64-bit

[Vince Rice]

On Jul 11, 2016, at 2:24 PM, Vince Rice <vr...@solidrocksystems.com> wrote:

> On Jul 11, 2016, at 1:17 PM, Marco Atzeri <marco.atz...@gmail.com> wrote:
> 
> On 11/07/2016 18:40, Vince Rice wrote:
>> Is there a reason there’s a different version of cvs in 32-bit vs 64-bit 
>> Cygwin?
>> 
>> 32-bit shows 1.12.13-10.
>> 64-bit shows 1.11.23.
>> 
>> (Yes, I know, git forever, but not everyone got the memo.)
>> --
> 
> https://www.cygwin.com/ml/cygwin-announce/2015-07/msg00054.html
> 
> 1.11.23-2 is the last version for both arch
> 
> Regards
> Marco

Hmmm. Then I wonder how this is true.

From my 32-bit VM:
C:\>cygcheck -c cvs
Cygwin Package Information
Package  VersionStatus
cvs  1.12.13-10 OK

From my 64-bit VM:
C:\>cygcheck -c cvs
Cygwin Package Information
Package  VersionStatus
cvs  1.11.23-2  OK

Since it’s already installed on 32-bit, I had to run the 32-bit setup in my 
64-bit VM to see what the choices were. (The 1.12.13-10 shows up as the “Keep” 
version on my 32-bit VM’s 32-bit setup.) The one I have doesn’t appear on the 
spinner, but the package I have installed is clearly valid, and I only get 
packages from Cygwin (no ports, etc.). Weird.

Thanks for info.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

CVS version 32 vs 64-bit

[Vince Rice]

Is there a reason there’s a different version of cvs in 32-bit vs 64-bit Cygwin?

32-bit shows 1.12.13-10.
64-bit shows 1.11.23.

(Yes, I know, git forever, but not everyone got the memo.)
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: changes in 32-bit Cygwin OpenGL causing crashes?

[Vince Rice]

> On May 26, 2016, at 10:01 PM, lloyd.w...@yahoo.co.uk wrote:
> 
> It's odd, the amount of extra support that Cygwin needs.
> 
> Okay, OpenGL is broken in 32-bit cygwin, not for the first
> time.
> 
> I'm unsure if OpenGL is broken in 64-bit cygwin, because
> the piping my applications use is broken in 64-bit cygwin -
> and only there. Not in any other linux or unix I've run on.
> So, it's rather tempting to blame 64-bit Cygwin.
> 
> But the OpenGL code is clearly obviously different
> and later in 64-bit Cygwin, because it builds to different
> function names (dropped a bunch of EXTs.) That's... odd.
> But in any case, we have a -noopengl flag just to work
> around OpenGL segfaulting in 32-bit Cygwin (and whether
> 64-bit segfaults is unknown, because piping problems.).
> 
> And there are graphical glitches I see in 32-bit Cygwin
> Tcl/Tk, but not in 64-bit Cygwin Tcl/Tk or anywhere else,
> 32- or 64-bit, in Linux/Unix land.
> 
> Those are the major things that come to mind when I think 
> of Cygwin.
> 
> Notes at:
> http://sat-net.com/L.Wood/software/SaVi/building-under-Windows/
> 
> where I try and suggest to users that Cygwin is not
> their best choice. Really.
> 
> It's been over fifteen years of 'under construction' so far.

First, please don't https://cygwin.com/acronyms/#TOFU.
Second, https://cygwin.com/acronyms/#PCYMTNQREAIYR.
Third, it’s posts like this that make me wish a former co-leader =
was still around.

Here are the major things that come to mind when I think of Cygwin.
Gratitude. Oceans and oceans of gratitude.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: tar incremental backups and ctime‏ problem

[Vince Rice]

> On Mon, May 23, 2016 at 5:29 PM, Eric Blake  wrote:
>> On 05/23/2016 03:18 AM, x y wrote:
>>> It is not clear to me your expectation:
>>> - are you asking how to use ctime to select the file with tar alone ?
>>>  It is not possible for my understanding of the manual.
>>> 
>>> - Are you asking the package maintainer to change the behaviour of
>>>  cygwin tar ? Unlikely to happen, but I leave to him.
>>> 
>>> 
>>> Hi Marco,
>>> 
>>> Sorry, I am new to the mailing list. If I am not wrong, tar is
>>> checking both of the ctime and mtime values to compare files during
>>> incremental backups. Since opening and closing a MS document without
>>> changing the content updates ctime, it would be preferable to add a
>>> new option to tar to use only mtime for file comparing during
>>> incremental backups.
>> 
>> mtime is fakeable, ctime is not.  Using only mtime makes it likely that
>> your incremental backup will miss files.  I don't have any good reason
>> to differ from upstream behavior here.
> 
> Hi Eric,
> 
> The problem is not faking time stamps. Even commercial Windows backup
> programs are checking the modification time to identify the modified
> files.
> 
> Consider that you have a lot of files opened and closed without any
> modification in your company. Because of the priority of the ctime
> time stamp, reintroducing all of those files to the incremental backup
> does not make any sense. tar has also the capacity to create
> differential backups with the condition of taking care of the snapshot
> file. The ctime issue can result in unnecessarily big differential
> backups filled with unmodified files.
> 
> Cygwin tar can be a good  alternative for Windows users to do
> differential \ incremental backups but the ctime problem must be
> solved.

This is ultimately Eric’s decision, but…

It doesn’t _have_ to be solved. If someone wants to use Cygwin tar as a backup, 
then that someone lives with the fact that tar uses ctime. The differential 
might be a little too big, but no actual harm is done. So what.

I personally don’t want to have to guess at tar’s behavior. I want to know it’s 
the same on Cygwin as elsewhere.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Proposed patch for web site: update most links to HTTPS

[Vince Rice]

> On Apr 25, 2016, at 2:33 PM, Nellis, Kenneth  wrote:
> 
> -Original Message-
> From: Adam Dinwoodie 
>> ...
>> But I agree with Brian: the Cygwin website
>> should use https everywhere unless there's some good, specific reason
>> why it's a bad idea...
> 
> 1. Did Brian say that? I couldn't find it in the thread.
> 2. I would be interested to hear the rationale for such a statement.
> Cygwin is open source. What's the point of encrypting?

I’m not sure what being open source has to do with it.
It should be encrypted for privacy. Frankly, from what we’ve seen in the last 
couple of years, plain http: should disappear. It should all be https. (And 
Adam is exactly correct on the performance; it is a non-issue today and has 
been for years.)



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Question about old win32 api

[Vince Rice]

On Sep 21, 2015, at 8:11 PM, Michael Enright <m...@kmcardiff.com> wrote:
> 
> On Mon, Sep 21, 2015 at 5:50 PM, Vince Rice  wrote:
> 
>> blindly
> 
> The blindness was blindness to the fact that new users were getting a
> different version than existing users in some way other than fixing
> vulns.
> …

The blindness was, as I’ve already pointed out, caused by blindly
updating software without knowing the reason for the update. Had
you/they been doing so, you/they would have known there was a
“different” version. Again, it was _announced_ as being “different”.

Software changes. It changes whether you, or I, like it or not. It
changes for lots of reasons, some of them you/I might agree with,
some of them you/I might not agree with. Nevertheless, it changes.
Telling us it changed, and why, is good practice for software providers.
That was done here. Reading why it changed, and knowing how that
will affect us, is good practice for software users. That apparently
wasn’t done here. The fault does not lie with the software provider.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Question about old win32 api

[Vince Rice]

> On Sep 21, 2015, at 7:04 PM, Michael Enright  wrote:
> 
> On Mon, Sep 21, 2015 at 1:31 PM, Marco Atzeri  wrote:
>> 
>> the change in nc had nothing to do with cygwin
>> change between 1.5 and 1.7
>> 
>> https://sourceware.org/ml/cygwin-announce/2012-05/msg00015.html
>> 
> 
> Implying a tie between the nc version to the release of 1.7.0-0 was
> wrong on my part. I am not wrong in this change to 'nc' did happen.
> Because I was not tracking all things Cygwin all the time I didn't
> know about it at first, and the people who had problems with it in my
> world were those who had deployed new workstations with Cygwin 1.7
> while those who could just keep using Cygwin 1.5 did not have
> problems. The point is that Cygwin doesn't stay the same all the time
> in the ways that all users may care about.

It did happen, and as Marco pointed out, it was _announced_ that
it happened. If someone is using Cygwin, not following the mailing
list (at the very least the announce list), and updating the software
blindly, then there's not much else to be done. They're almost
guaranteed to run into problems.

This is no different than any other software on the planet —
blindly updating Linux versions without knowing what’s in the
update, or blindly updating Word without knowing what’s in
the update, and so on, leads to the same thing — problems
can, and will, happen.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: --line-regexp option with null data

[Vince Rice]

 On Jul 16, 2015, at 10:04 PM, Steven Penny svnp...@gmail.com wrote:
 
 On Thu, Jul 16, 2015 at 9:30 PM, Andrey Repin wrote:
 Linux grep will do the same.
 null byte = not a text.
 Wrong encoding, not matching locale = not a text.
 
 I have repeatedly asked you to stay out of my threads. My experience is you
 typically misread, misunderstand or misrepresent most or all of the threads 
 you
 comment on. I will ask again, please stop.
 …

And you have been just as repeatedly told, by the people in charge of this 
list, that’s not your call, and to stop speaking in such a manner to other 
people on this list.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: delay when querying /proc/loadavg

[Vince Rice]

On Jun 22, 2015, at 11:14 AM, m0viefreak m0viefreak...@googlemail.com wrote:
 
 
 Hello,
 
 I noticed that there is long delay when getting the content of /proc/ladavg:
 
 $ time cat /proc/loadavg
 0.00 0.00 0.00 1/16
 cat /proc/loadavg  0.01s user 1.47s system 100% cpu 1.480 total
 
 I am aware that loadavg is not meaningful on cygwin and always returns
 0 0 0, but it is used in many programs and scripts. For example I
 noticed it with my .bashrc/.zshrc that I copied from another (native
 linux) system.
 
 This slowdown also seems to affect programs like 'top' which takes a
 long time to start and behaves very sluggish when navigating due to
 updating those values.
 
 Is there a reason it takes that long to react? On every other system
 getting the value is instant.

WFM.

$ uname -a
CYGWIN_NT-6.1 SRSMBPROWIN 2.0.4(0.287/5/3) 2015-06-09 12:20 i686 Cygwin
$ time cat /proc/loadavg
0.00 0.00 0.00 1/3

real0m0.031s
user0m0.015s
sys 0m0.000s


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: managing multiple emacs

[Vince Rice]

The good reason is this problem goes away if you’re only using native (cygwin) 
emacs.
The other good reason is that you’ll almost certainly spend more time trying to 
work around not using native tools than you would just installing them (and 
uninstalling the non-native one).

(Spoken as a non-emacs user, so no direct experience either way.)


 On Jun 9, 2015, at 2:28 PM, Nellis, Kenneth kenneth.nel...@xerox.com wrote:
 
 From: Jim Reisert AD1C 
 
 3. I don't have the Cygwin emacs-w32 package installed; my Windows
 version is outside the
 Cygwin environment.
 
 Don't install GNU Emacs for Windows.  Get rid of it.  Install the
 Cygwin emacs-w32 package instead.  You can use this in Windows as long
 as cygwin/bin is in your Windows path.  I did this years ago and have
 never looked back.  It works great!
 
 Thanx for that advice, but since I already have it installed, and without
 any reason given to change, it's hard to justify swapping it out. If there
 are good reasons to do so, I'll be glad to do it.
 
 --Ken Nellis


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: From Microsoft: Windows 10 Console and Cygwin

[Vince Rice]

 On Jun 2, 2015, at 2:20 PM, Eric Blake ebl...@redhat.com wrote:
 
 On 06/02/2015 10:37 AM, Rich Eizenhoefer wrote:
 Can you provide more detail on changing isatty function to support Cygwin 
 PTY's? I need to be able to support the request in our backlog.
 
 As long as we are wishing, it would be awesome if Windows natively
 supported ptys as actual objects, instead of making cygwin have to
 emulate them on top of other objects.
 

An ignorant question from an uninformed bystander — wouldn’t the “awesome” be 
the other of Corinna’s suggestions in her original email, i.e. that Windows 
open up the console API so that Cygwin can create a real TTY instead of having 
to emulate them in PTYs? I would think that would be the biggest win, with the 
least amount of cygwin-specific flavor to it.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Grepping Unicode files?

[Vince Rice]

 On May 14, 2015, at 11:43 AM, Eric Blake ebl...@redhat.com wrote:
 
 On 05/14/2015 10:32 AM, Vince Rice wrote:
 
 …
 
 Now, pardon my continued ignorance, but which of those variables needs to be 
 set to UTF16 in order for grep to work? And I assume it (they?) should be 
 set to en_US.UTF-16?
 
 None.  UTF16 is not a valid locale.  It is a valid encoding (wide
 character), but locales must operate on multi-byte sequences, not wide
 characters.  So you HAVE to convert from wide character to multi-byte
 before you can do anything that requires a locale to work correctly.

Oh my, the rabbit-hole gets deeper. I don’t know the difference between wide 
character and multi-byte. A little searching appears to indicate that Unicode 
is a type of wide-character, while multi-byte is … well, I still don’t know 
what multi-byte is. :) But, we’re definitely out in the weeds of non-cygwinness 
here, and my file is UTF16, so I can learn what multi-byte is and the 
difference later.

Bottom-line…

 
 Thanks to everyone for your help. I think you’ve all confirmed this isn’t 
 cygwin-specific, but I couldn’t find anything even searching generically 
 (“grep unicode” and now “grep utf16”). I did finally find an external 
 reference to iconv, but if grep is supposed to be handle this natively, I 
 haven’t been able to find much on how to do it.
 
 grep cannot handle UTF16 natively.  iconv exists to do encoding
 transformations, so that the rest of the system can live in multi-byte
 world instead of worrying about wide-character encodings.

… grep can’t handle unicode files. Good to know. iconv it is.

Thanks again!
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Grepping Unicode files?

[Vince Rice]

On May 14, 2015, at 10:56 AM, Andrey Repin anrdae...@yandex.ru wrote:
 
 Greetings, Vince Rice!
 
 uname says CYGWIN_NT-6.1 machinename 1.7.35(0.287/5/3) 2015-03-04 12:07 
 i686 Cygwin”.
 I’m running grep 2.21.2, which cygcheck -c says is OK.
 
 Does Cygwin’s grep support Unicode files? The output from a SQL Server SQL
 Agent job is a Unicode file, i.e. if you look at it in a hex editor every
 other character is 00 because each character is taking up two bytes. The
 filename itself is fine, it’s the contents that is Unicode. I can’t get grep
 to work on it, either with or without -a.
 
 This may not be a Cygwin-specific question, but I haven’t been able to find
 anything after several Google searches, including the archives, and neither
 --help nor the man page for grep references Unicode.
 
 By default I have neither LC_ALL nor LC_COLLATE set.
 
 A pointer to a better search or a website that explains this would be
 great, or if it can’t currently be done, that’s OK, too.
 
 grep only treat files as text if they are matching current locale.
 Check `locale` output to see your current settings.

First, to the other responder(s), running it through iconv with a from of UTF16 
and a to of UTF8 did work. Thanks for the pointer. (I’ve never had to deal with 
anything but ANSI files, so I didn’t know about iconv. And I guessed on the 
UTF8, given what I found below.)

locale run from a cmd.exe session says that everything is “C.UTF-8”, while 
locale run from mintty says that everything is en_US.UTF-8. A “which” in both 
cases shows that the locale being run is cygwin’s, so I assume mintty does 
something slightly differently than the normal console? I don’t even know if 
there’s a difference. (Have I mentioned I don’t know anything about all of 
this?)

From cmd.exe:
LANG=
LC_CTYPE=C.UTF-8
LC_NUMERIC=C.UTF-8
LC_TIME=C.UTF-8
LC_COLLATE=C.UTF-8
LC_MONETARY=C.UTF-8
LC_MESSAGES=C.UTF-8
LC_ALL=

From mintty
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_ALL=

Now, pardon my continued ignorance, but which of those variables needs to be 
set to UTF16 in order for grep to work? And I assume it (they?) should be set 
to en_US.UTF-16?

Thanks to everyone for your help. I think you’ve all confirmed this isn’t 
cygwin-specific, but I couldn’t find anything even searching generically (“grep 
unicode” and now “grep utf16”). I did finally find an external reference to 
iconv, but if grep is supposed to be handle this natively, I haven’t been able 
to find much on how to do it.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Grepping Unicode files?

[Vince Rice]

uname says CYGWIN_NT-6.1 machinename 1.7.35(0.287/5/3) 2015-03-04 12:07 i686 
Cygwin”.
I’m running grep 2.21.2, which cygcheck -c says is OK.

Does Cygwin’s grep support Unicode files? The output from a SQL Server SQL 
Agent job is a Unicode file, i.e. if you look at it in a hex editor every other 
character is 00 because each character is taking up two bytes. The filename 
itself is fine, it’s the contents that is Unicode. I can’t get grep to work on 
it, either with or without -a.

This may not be a Cygwin-specific question, but I haven’t been able to find 
anything after several Google searches, including the archives, and neither 
--help nor the man page for grep references Unicode.

By default I have neither LC_ALL nor LC_COLLATE set.

A pointer to a better search or a website that explains this would be great, or 
if it can’t currently be done, that’s OK, too.

Thanks for your help!
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Although advertised on a different Cygwin mailing list ...

[Vince Rice]

 PS: the cygwin web site seems very slow. Is it just my connection ?

What he said. It’s been off and on for a couple of weeks, but this morning it 
actually timed out. I actually did a traceroute and it was a 70.* address that 
was the problem. (Sorry, I did it at home and don’t have the output with me on 
my laptop.)
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: A list of installed packages (no dependencies)

[Vince Rice]

This is the fourth or fifth time you have persisted in this rudeness, even 
after Yaakov called you down for it the first time and told you it would not be 
tolerated here.
I’m calling attention to it so he and Corinna will see it for what it is, not 
just a benign link.


On Jan 1, 2015, at 4:25 PM, Steven Penny svnp...@gmail.com wrote:

 On Thu, Jan 1, 2015 at 10:00 AM, Andrey Repin wrote:
 http://cygwin.com/acronyms/#PTC
 
 http://cygwin.com/ml/cygwin/2014-08/msg00179.html


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

cygcheck -p indicate obsoleteness?

[Vince Rice]

tl;dr version: can cygcheck possibly be improved (I know, PTC :) ) to show that 
a package is obsolete, instead of just showing the “current” version? 

Longer explanation of where the request came from:
I’ve had an alias for c=clearw.exe for quite some time. I did an update today 
to get the bash exploit fix, and while I was at it updated the other packages 
that needed to be updated. Whereupon my alias didn't work, which was because 
clearw.exe was no longer present in /bin.

Hmmm. I was pretty sure I knew what provided clearw, but to confirm...

$ cygcheck -p .*clearw.*
Found 1 matches for .*clearw.*
ncursesw-5.7-18 - Utilities for terminal handling

Ah, something must have happened to my ncursesw, I just need to reinstall it. 
So I fired up setup to install ncursesw-5.7-18. Except that I couldn’t find it.

After looking around for a while, I then did a cygcheck -c. Which showed that 
ncursesw had the same version as ncurses. Interesting.

I then did a cygcheck -p “.*ncursesw.*” I got a long list, among them
...
ncursesw-5.7-18 - Utilities for terminal handling
ncursesw-5.7-18-src - Source code for Utilities for terminal handling
ncursesw-5.9-20140524-1 - Utilities for terminal handling
...

Hmmm. I then went back to setup and thought to uncheck “Hide obsolete” 
packages. And lo and behold, there was ncursesw, with a name of “ncursesw - 
obsoleted by ncurses”.

So, ncursesw was obsoleted, and thus I should use clear.exe instead of 
clearw.exe. However, it took me a while to figure that out because cygcheck -p 
didn't indicate that the ncursesw package was obsoleted.  Thus, the request.

Thanks, and thanks very much for cygwin in general.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

mintty and readline mapping

[Vince Rice]

mintty 0.4.4 on CYGWIN_NT-5.1 SRSMBPROWIN 1.7.0(0.212/5/3) 2009-08-20 10:56 
i686 Cygwin

I'm trying to map ctrl-tab in mintty and can't seem to get it working. I've 
Googled bash and key bindings, key mapping, etc., but haven't found anything 
that helps with the problem.

I'm trying to bind ctrl-tab to reverse-menu-complete. 
cat .inputrc
# use ctrl-left/right to jump between words
;5C: forward-word
;5D: backward-word

# enable inline completion
TAB: menu-complete
;5I: reverse-menu-complete

The ctrl-left/right mappings above work (that took me a while by itself -- 
those keys map with \e[5C and \e[5D  on OS X, my other available Unix right 
now). The ctrl-tab key displays ;5I (that's a capital-eye) when pressed, 
which makes it look like the above is tantalizingly close.

What am I missing? If this is a generic mapping issue, feel free to point me to 
somewhere else to look.

Thanks,

Vince



  
Cygwin Configuration Diagnostics
Current System Time: Wed Aug 26 15:44:59 2009

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   C:\cygwin\home\vrice\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\bat
C:\utils
C:\Programs\Perl\bin
C:\cygwin\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\Microsoft SQL Server\80\Tools\BINN
C:\Programs\MSSQL\100\DTS\Binn\
C:\Programs\MSSQL\100\Tools\Binn\VSShell\Common7\IDE\
C:\Programs\MSSQL\100\Tools\Binn\
C:\Program Files\Microsoft Visual Studio 
9.0\Common7\IDE\PrivateAssemblies\
C:\WINDOWS\system32\WindowsPowerShell\v1.0

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1004(vrice)GID: 513(None)
544(Administrators) 545(Users)  513(None)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1004(vrice)GID: 513(None)
544(Administrators) 545(Users)  513(None)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

USER = 'vrice'
PWD = '/home/vrice'
HOME = '/home/vrice'

HOMEPATH = '\Documents and Settings\vrice'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Documents and Settings\vrice\Application Data'
HOSTNAME = 'SRSMBPROWIN'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 23 Stepping 6, GenuineIntel'
WINDIR = 'C:\WINDOWS'
CVSROOT = '/z/Documents/cvs'
OLDPWD = '/c/Documents and Settings/vrice'
USERDOMAIN = 'SRSMBPROWIN'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
TEMP = '/c/tmp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
USERNAME = 'vrice'
PAGER = 'less'
PROCESSOR_LEVEL = '6'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
USERPROFILE = 'C:\Documents and Settings\vrice'
CLIENTNAME = 'Console'
PS1 = '$logn...@srsmbprowin:$PWD\'
LOGONSERVER = '\\SRSMBPROWIN'
PROCESSOR_ARCHITECTURE = 'x86'
HISTCONTROL = 'ignoredups'
J2D_D3D = 'false'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1'
HOMEDRIVE = 'C:'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
LESS = '-c -X'
TMP = '/c/tmp'
SYSTEMROOT = 'C:\WINDOWS'
PRINTER = 'HP4345#:2'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '1706'
lib = 'C:\Program Files\SQLXML 4.0\bin\'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files'
NUMBER_OF_PROCESSORS = '1'
SESSIONNAME = 'Console'
COMPUTERNAME = 'SRSMBPROWIN'
_ = '/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'C:\cygwin15'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = 'C:\cygwin15/bin'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = 'C:\cygwin15/lib'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin\setup
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
  (default) = 'C:\cygwin'

obcaseinsensitive set to 1

a:  fd N/AN/A
c:  hd  NTFS 32757Mb  35% CP CS UN PA FC 
d:  cd N/AN/A
e:  net HGFS304917Mb  55% CP Shared Folders
p:  net NTFS133120Mb  73% CP CS UN PAIT
r:  net NTFS133120Mb 100% CP CS UN PACustSe
z:  net HGFS304917Mb  55% CP Shared Folders

Warning: Mount entries should not have a trailing (back)slash

C:\cygwin  / system  

Re: Cygwin openssh(d) login without password

[Vince Rice]

 3. One may try 'help ssh' and be told to try 'man -k ssh' which
 produces  ssh: nothing appropriate, another showstopper.  One _might_
 ultimately  try 'man ssh' instead and get (sort of) lucky.

 This is *your* setup, this has nothing to do with openssh:

 $ man -k ssh
 [...]
 ssh (1) - OpenSSH SSH client (remote login program)
 ssh [slogin] (1) - OpenSSH SSH client (remote login program)
 ssh-add (1) - adds RSA or DSA identities to the authentication agent

Well, one could say it has to do with *your* setup.
cygcheck -c openssh
Cygwin Package Information
Package  VersionStatus
openssh  3.9p1-1OK

man -k ssh
ssh: nothing appropriate

 I think if it is too much for Joe User to:
 1. read just four pages of docu
 2. after searching the docu one hour
 3. just to get sshd up and running the first time

You are hardly a new user, Gerritt.  Not a new user to ssh, a new user
*period*. Lots of things are obvious to an experienced user that aren't to a
new user (something I'm thankfully reminded of every time I sit with my wife at
a computer for more than five minutes).  And the steps lex ein laid are
extremely accurate.  For a new user.

Vince



___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Mounted text mode but acting binary

[Vince Rice]

I have a directory mounted text mode.  In that directory, I'm running a grep
looking for trailing spaces and/or tabs.  It's not finding any in a file that I
know has them, so I created a small file with one line and a trailing tab.  It
doesn't find that, either.  I changed the file from DOS line endings to Unix
line endings, and grep found it.

So, grep appears to be acting as if the current directory is binary mode, but
the mount table shows it as text mode.  What am I missing?

I'm on 1.5.10-3 on W2KSP2.  Here is the output of mount:
d:\cygwin\bin\cygcheck.exe on /bin/cygcheck type system (binmode,exec)
d:\cygwin\bin\cygcheck.exe on /bin/cygcheck.exe type system (binmode,exec)
e:\clients\iasg\csv on /e/clients/iasg/csv type system (textmode)
e:\mas\mmb\sql\ap on /e/mas/mmb/sql/ap type system (textmode)
d:\cygwin\bin on /usr/bin type system (binmode)
d:\cygwin\lib on /usr/lib type system (binmode)
d:\cygwin on / type system (binmode)
c: on /c type user (binmode,noumount)
d: on /d type user (binmode,noumount)
e: on /e type user (binmode,noumount)
k: on /k type user (binmode,noumount)
o: on /o type user (binmode,noumount)
s: on /s type user (binmode,noumount)

I'm in the e:\mas\mmb\sql\ap directory when I'm doing the grep.  I've confirmed
that grep is Cygwin's (which grep yields grep is an external :
D:\cygwin\bin\grep.exe).  I've tried it both from cmd and from a bash prompt;
neither works.

I've also attached my cygcheck output if the above doesn't provide any hints.

Thanks,

Vince

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

cygcheck.out
Description: cygcheck.out
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Mounted text mode but acting binary

[Vince Rice]

--- Larry Hall [EMAIL PROTECTED] wrote:

 At 03:33 PM 8/9/2004, you wrote:
 I have a directory mounted text mode.  In that directory, I'm running a grep
 looking for trailing spaces and/or tabs.  It's not finding any in a file
 that I know has them...
 
 WFM with same O/S (though SP3) and Cygwin versions all around.  Are you 
 quite certain you're not getting the Borland one somehow?

Yes, as I mentioned in the original message.  Both which and grep --help show
that grep is Cygwin's (I didn't even know there was one in Borland's directory;
I've never used it).

Jacek's message hit the nail on the head.  I downloaded the most recent
snapshot, and it works.  So it was a Cygwin bug (although Pierre's message
seems to indicate it didn't manifest itself in 1.5.9, that's where I saw it
originally; I only dl'd 1.5.10 to eliminate 1.5.9 as the problem).

Jacek, thanks very much.  I would reply to your message directly, but I'm not
subscribed to the list and I don't know how to do that (I only was able to
reply to Larry because he cc'd me).

Vince



__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Mounted text mode but acting binary

[Vince Rice]

Sorry, I realized too late that I left Larry's address in the reply.  My
apologies; I'm using a Web mailer so it doesn't obfuscate automatically, and I
didn't catch it before I hit send.

Vince



__
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: wtfindex and dos line endings

[Vince Rice]

 Igor Pechtchanski [EMAIL PROTECTED] wrote:
 On Tue, 25 Nov 2003, Vince Rice wrote:

 I reported a couple of weeks ago that wtfindex choked on text
mounts,
 and Igor promptly fixed it (thanks, Igor!). I just discovered that
 wtfindex can't handle DOS line endings, even on text mounts.
 ...

 Vince,

 I'm sorry, I can't reproduce this on my machine. Please provide the
 *exact* steps needed to reproduce it, including the correct mount
command
 (you can temporarily mount some directory, say /tmp/text, in text
mode if
 you need to).
 Igor

Well, then my apologies for not sending cygcheck.out last time; I
thought this would be as simple as the last one (it never is, is
it?). Here is a copy of the session to duplicate this, the file I did
it with, and cygcheck.out.

Thanks,

Vince

@IS2E296:/usr/text\ uname -a
CYGWIN_NT-5.0 IS2E296 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown
unknown Cygwin
@IS2E296:/usr/text\ mount -b c:\cygwin\usr\text /usr/text
@IS2E296:/usr/text\ od -xa testwtf
000 4641 4941 0943 7361 6620 7261 6120 2073
  A   F   A   I   C  ht   a   s  sp   f   a   r  sp   a   s 
sp
020 2749 206d 6f63 636e 7265 656e 0a64 4641
  I   '   m  sp   c   o   n   c   e   r   n   e   d  nl   A  
F
040 4941 5243 6109 2073 6166 2072 7361 4920
  A   I   C   R  ht   a   s  sp   f   a   r  sp   a   s  sp  
I
060 6320 6e61 7220 6365 6c61 0a6c
 sp   c   a   n  sp   r   e   c   a   l   l  nl
074
@IS2E296:/usr/text\ wtfindex testwtf
@IS2E296:/usr/text\ wtfdump testwtf
Textfile: testwtf
Datafile: testwtf.dat
Items: 2
Offset  Key Value
0   AFAIC   as far as I'm concerned
1   AFAICR  as far as I can recall
@IS2E296:/usr/text\ unix2dos testwtf
testwtf: done.
@IS2E296:/usr/text\ od -xa testwtf
000 4641 4941 0943 7361 6620 7261 6120 2073
  A   F   A   I   C  ht   a   s  sp   f   a   r  sp   a   s 
sp
020 2749 206d 6f63 636e 7265 656e 0d64 410a
  I   '   m  sp   c   o   n   c   e   r   n   e   d  cr  nl  
A
040 4146 4349 0952 7361 6620 7261 6120 2073
  F   A   I   C   R  ht   a   s  sp   f   a   r  sp   a   s 
sp
060 2049 6163 206e 6572 6163 6c6c 0a0d
  I  sp   c   a   n  sp   r   e   c   a   l   l  cr  nl
076
@IS2E296:/usr/text\ wtfindex testwtf
@IS2E296:/usr/text\ wtfdump testwtf
Textfile: testwtf
Datafile: testwtf.dat
Items: 2
Offset  Key Value
0   AFAIC   as far as I'm concerned
1   AFAICR  as far as I can recall
@IS2E296:/usr/text\ dos2unix testwtf
testwtf: done.
@IS2E296:/usr/text\ umount /usr/text
@IS2E296:/usr/text\ mount -t c:\cygwin\usr\text /usr/text
@IS2E296:/usr/text\ od -xa testwtf
000 4641 4941 0943 7361 6620 7261 6120 2073
  A   F   A   I   C  ht   a   s  sp   f   a   r  sp   a   s 
sp
020 2749 206d 6f63 636e 7265 656e 0a64 4641
  I   '   m  sp   c   o   n   c   e   r   n   e   d  nl   A  
F
040 4941 5243 6109 2073 6166 2072 7361 4920
  A   I   C   R  ht   a   s  sp   f   a   r  sp   a   s  sp  
I
060 6320 6e61 7220 6365 6c61 0a6c
 sp   c   a   n  sp   r   e   c   a   l   l  nl
074
@IS2E296:/usr/text\ wtfindex testwtf
@IS2E296:/usr/text\ wtfdump testwtf
Textfile: testwtf
Datafile: testwtf.dat
Items: 2
Offset  Key Value
0   AFAIC   as far as I'm concerned
1   AFAICR  as far as I can recall
@IS2E296:/usr/text\ unix2dos testwtf
testwtf: done.
@IS2E296:/usr/text\ od -xa testwtf
000 4641 4941 0943 7361 6620 7261 6120 2073
  A   F   A   I   C  ht   a   s  sp   f   a   r  sp   a   s 
sp
020 2749 206d 6f63 636e 7265 656e 0d64 410a
  I   '   m  sp   c   o   n   c   e   r   n   e   d  cr  nl  
A
040 4146 4349 0952 7361 6620 7261 6120 2073
  F   A   I   C   R  ht   a   s  sp   f   a   r  sp   a   s 
sp
060 2049 6163 206e 6572 6163 6c6c 0a0d
  I  sp   c   a   n  sp   r   e   c   a   l   l  cr  nl
076
@IS2E296:/usr/text\ wtfindex testwtf
@IS2E296:/usr/text\ wtfdump testwtf
Textfile: testwtf
Datafile: testwtf.dat
Items: 2
Offset  Key Value
0
AFAIC   as far as I can recal
1   AFAIC   as far as I'm concerned
@IS2E296:/usr/text\


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/AFAIC   as far as I'm concerned
AFAICR  as far as I can recall

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Tue Nov 25 14:38:03 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3

Path:   C:\cygwin\usr\local\bin
c:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1001(vrice) GID: 513(None)
513(None)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1001(vrice) GID: 513(None)
544(Administrators)  545(Users)

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

HOME = `C:\cygwin\home\vrice'
MAKE_MODE = `unix'
PWD = `/usr/text'
USER = `vrice'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\vrice

Re: wtfindex and dos line endings

[Vince Rice]

Aacch, I just saw that the mailer put the file and the cygcheck.out
in the message instead of attaching them.  They were attachments when
I hit Send; I had to use Yahoo's web emailer since I wasn't at the
office.  I apologize, I've never sent a text attachment from there
before, so I didn't know they did that.

Vince

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

wtfindex produces corrupt files on DOS mounts

[Vince Rice]

/home/vrice\ uname -a
CYGWIN_NT-5.0 SRS8100 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown
unknown Cygwin

/home/vrice\ which wtfindex
/usr/bin/wtfindex
/home/vrice\ ls -Fal /usr/bin/wtfindex.exe
-rwxrwxrwx1 vriceUsers   12800 Sep  4 11:12
/usr/bin/wtfindex.exe*

On DOS mounts, wtfindex produces a .dat file that causes coredumps in
wtf.  I had edited my acronyms file, ran wtfindex, then wtf started
coredumping.  I reinstalled wtf, then saved off the existing
acronyms.dat, and ran wtfindex against acronyms without making any
changes.  The resulting acronyms.dat differed from the original by
thirteen bytes, and a comparison showed that where OD existed in the
original, 0D0A existed in the newly generated one.  Switching to a
Unix mount generated an identical file to the original, no coredumps.

I think this is enough information that a cygcheck shouldn't be
needed, but if you think otherwise just let me know.

Thanks,

Vince

P.S. -- I'm one of the tens of thousands who have never had a
problem, so I seldom have any reason to post.  So to offset the
problem report, let me say that Cygwin is the best thing sinced
sliced bread.  I've used it off and on since before B19 (and what a
wonderful release THAT was! :) ), and it's been a huge productivity
enhancer at several client sites.  Thanks to ALL the volunteers who
make it possible.

__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: wtfindex produces corrupt files on DOS mounts

[Vince Rice]

--- Igor Pechtchanski [EMAIL PROTECTED] wrote:
 Vince,
 
 Thanks for the report.  It would have been great if you also
 specified the version of wtf that you used.  However, I've just 
 reproduced this with wtf-0.0.4-4.  Expect a new release soon.

My apologies.  I did try to figure out the version, but I couldn't
find anything that would tell me.  There appears to be only one
command line switch (-a), it wasn't in the man page, I tried cygcheck
wtf, and I tried an old filever utility I have on the wtf.exe itself.
 While I'm typing it occurs to me I could have run through setup and
let it tell me...  I know this is a lean and mean program, but would
you consider supporting command line options -v or --version in wtf
itself?

I just did the setup thing, and it is indeed 0.0.4-4 that I have as
well.  Thanks for the quick fix!

Vince

P.S. -- I got to thinking about how setup knew, so I poked around
some more on cygcheck and found that cygcheck -c told me the
information as well.  So now I'll know for next time.  However,
supporting -v or --version in the program itself would still be nice. :)

__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Setup snapshot location?

[Vince Rice]

I'm sure I've missed something blindingly obvious, but I have looked
and searched:
1.  The Cygwin home page
2.  The Cygwin snapshot page
3.  The FAQ
4.  Google (using setup.exe cygwin snapshot and a couple of other
combinations)

I can find nothing that indicates where setup snapshots are located. 
In fact, I can't even find setup's home page, although I know there
is one because I've been there before.  Which is how I know I'm
missing something blindingly obvious; my apologies in advance.

Thanks,

Vince

__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/