Re: Creating a desktop shortcut to Cygwin emacs

[David Karr via Cygwin]

Ok. I forgot I had to add that package.

However, now there's another odd problem. The command line still doesn't
start anything, but it does print an error message, saying that it can't
find "/usr/local/bin/emacs.xml".  I can copy that file from the old laptop,
but is that file supposed to be generated by something?

On Thu, Feb 22, 2024 at 1:12 PM Ken Brown  wrote:

> On 2/22/2024 2:44 PM, David Karr via Cygwin wrote:
> > Every three years or so I have to set up a new laptop, and several things
> > that I only do in that period I either lose the notes on it, or something
> > has changed that I'm not aware of.
> >
> > I'm installing Cygwin on a new laptop, version 3.5.0-1.x86_64. I had
> 3.4.6
> > on the old laptop.
> >
> > My desktop shortcut on the old laptop goes to:
> >
> > C:\cygwin64\bin\run2.exe --display 127.0.0.1:0.0
> /usr/local/bin/emacs.xml
> >
> > I tried to set this up on the new laptop, and I noticed that "run2"
> doesn't
> > exist, but "run" does.
>
> The run2 package still exists:
>
>https://cygwin.com/packages/summary/run2.html
>
> Ken
>

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

Creating a desktop shortcut to Cygwin emacs

[David Karr via Cygwin]

Every three years or so I have to set up a new laptop, and several things
that I only do in that period I either lose the notes on it, or something
has changed that I'm not aware of.

I'm installing Cygwin on a new laptop, version 3.5.0-1.x86_64. I had 3.4.6
on the old laptop.

My desktop shortcut on the old laptop goes to:

   C:\cygwin64\bin\run2.exe --display 127.0.0.1:0.0 /usr/local/bin/emacs.xml

I tried to set this up on the new laptop, and I noticed that "run2" doesn't
exist, but "run" does. I tried just changing the command line to call "run"
instead, but that resulting command line doesn't appear to do anything. No
errors, just returns to the prompt and nothing happens.

I tried googling for this, and I found a page on the EmacsWiki, but I can't
tell if that is up to date.

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

Re: Another confusing error from someone else's Cygwin setup

[David Karr via Cygwin]

The line endings were the issue, thanks. They were that way because I
didn't realize I should force those files in git to have eol=lf in a
.gitattributes file.  This is now all fixed.

On Mon, Jun 26, 2023 at 7:08 PM Mike Gran  wrote:

> > On Monday, June 26, 2023 at 04:36:30 PM PDT, David Karr via Cygwin <
> cygwin@cygwin.com> wrote:
>
> > m seeing a problem with someone else's Cygwin setup, sort of similar to a
> > problem I asked about a couple of weeks ago, in that it's a problem with
> > the same user, but seemingly a completely different problem.
>
> ...
>
> > He was getting a weird error on line 3, just saying this:
> > -
> > ...: line 3: syntax error near unexpected token `$'{\r''
> > ...: line 3: `main() {
> > ---
>
> If you run bash with the "-o igncr" option, it will ignore extraneous
> carriage return characters.
>
> But the characters are there in the first place because your
> script has been converted into using Windows line endings:
> carriage return + linefeed.
>
> You didn't say how the script was transferred, but lots
> of programs could add returns when you transfer something
> to windows: git or ftp just to name a few.
>
> You both could try running "bash --version".  The first line should
> say something like
> "GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin)"
>
> Note the "pc-cygwin" at the end.
>
> HTH,
> Mike Gran
>

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

Another confusing error from someone else's Cygwin setup

[David Karr via Cygwin]

I'm seeing a problem with someone else's Cygwin setup, sort of similar to a
problem I asked about a couple of weeks ago, in that it's a problem with
the same user, but seemingly a completely different problem.

He is using a Bash script that I wrote, and he gets a seemingly nonsensical
error that I don't understand.

The script starts out pretty simply, just like this:
--
#! /bin/bash
#set -x
main() {
if [ "$1" == "" ]; then
usage;
exit;
fi
...
-

He was getting a weird error on line 3, just saying this:
-
...: line 3: syntax error near unexpected token `$'{\r''
...: line 3: `main() {
---

This was pretty perplexing, so I asked him to uncomment the "set -x" line
to see if that provided any useful information, and that fails with a
different error:
---
: invalid option...: line 2: set: -
set: usage: set [-abefhkmnptuvxBCEHPT] [-o option-name] [--] [-] [arg ...]
--

This also makes no sense to me.  I compared our "uname -a" outputs, and
they are almost identical. However, I then had him run "bash --version",
and I compared it to mine.  Ironically, I'm using an OLDER version of bash
than he is. I'm on v4.4.12(3)-release, and he's on v5.2.15(3)-release.  Is
there something in 5.x versions of Bash that could cause these issues?

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

Re: Trying to figure out what is wrong in a colleague's Cygwin setup

[David Karr via Cygwin]

Actually, I was mistaken. I was given incomplete information. I'm getting
much of this second hand. Adding that to the PATH made no difference.

It appears this is something specific to "kubectl".  They ended up setting
the KUBECONFIG environment variable to "C:\Users\\.kube\config", which
is very odd, as that is basically the default value of it, and I have never
set that, and I've never seen this problem. Whatever. They're working now.

On Fri, Jun 16, 2023 at 12:17 PM Mike Gran  wrote:

> > Ok, well, we managed to resolve this, but I don't understand why what we
> > did would fix this.
>
> > In system environment variables in Windows, they added "c:\cygwin64\bin"
> to
> > the end of the PATH. That fixes the problem. That just doesn't make any
> > sense to me. In a Cygwin shell, "/usr/bin" is in the PATH, which is the
> > same as "c:\cygwin64\bin".
>
> Hello David-
> The fact that their uname said MINGW implies they weren't running
> "real" Cygwin, but, actually MSYS, which is the slightly modified Cygwin
> that is bundled with MINGW to allow it to run bash and other
> coreutils.
>
> MSYS has its own location for '/usr/bin', which is probably
> c:/msys64/usr/bin or similar. It won't look in c:/cygwin64 by default.
>
> Just a guess, but, hope this helps.
> -Mike Gran
>

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

Re: Trying to figure out what is wrong in a colleague's Cygwin setup

[David Karr via Cygwin]

Ok, well, we managed to resolve this, but I don't understand why what we
did would fix this.

In system environment variables in Windows, they added "c:\cygwin64\bin" to
the end of the PATH. That fixes the problem. That just doesn't make any
sense to me. In a Cygwin shell, "/usr/bin" is in the PATH, which is the
same as "c:\cygwin64\bin".

On Thu, Jun 15, 2023 at 2:07 PM David Karr 
wrote:

> (I replied with this earlier directly to someone who I didn't realize had
> only replied to me.)
>
> I do have a couple other clues that I've noticed while continuing to debug
> this.
>
> This person also has "git bash" installed, which is certainly similar to
> Cygwin, but not quite the same.  In his gitbash shell, he does not get this
> error.
>
> If it matters, here is the "uname -a" output (hostname elided):
>
> CYGWIN_NT-10.0-22000 ... 3.4.6-1.x86_64 2023-02-14 13:23 UTC x86_64
> Cygwin
>
> If it matters, here is the same from his gitbash shell:
>
> MINGW64_NT-10.0-22000 ... 3.1.7-340.x86_64 2021-03-26 22:17 UTC x86_64
> Msys
>
> He is running Windows 11 (as I am).
>
> What else can I try to narrow this down?
>
> On Tue, Jun 13, 2023 at 2:54 PM David Karr 
> wrote:
>
>> I have been using Cygwin for many years, although I wouldn't call myself
>> an advanced user.
>>
>> I'm working with some much newer users.  They set up Cygwin, but I didn't
>> see them do it. I ran "uname -a" and it was about the same as mine.  I
>> compared the output of "env|sort" and I saw some differences, but I can't
>> tell if they were significant.
>>
>> When I run the following command:
>>
>> kubectl config use-context dev2ff
>>
>> It works perfectly fine, setting the correct context.  When this user I'm
>> working with runs the same command, he gets this (replacing his userid with
>> "..."):
>>
>> error: FindFirstFile C:\cygwin64\home\.../.kube/config: The directory
>> name is invalid.
>>
>> He did have "HOME=/c/Users/...", but I had him change it to "/home/...",
>> but that didn't make any difference.
>>
>> I'm not sure what could be happening here.
>>
>

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

Re: Trying to figure out what is wrong in a colleague's Cygwin setup

[David Karr via Cygwin]

(I replied with this earlier directly to someone who I didn't realize had
only replied to me.)

I do have a couple other clues that I've noticed while continuing to debug
this.

This person also has "git bash" installed, which is certainly similar to
Cygwin, but not quite the same.  In his gitbash shell, he does not get this
error.

If it matters, here is the "uname -a" output (hostname elided):

CYGWIN_NT-10.0-22000 ... 3.4.6-1.x86_64 2023-02-14 13:23 UTC x86_64
Cygwin

If it matters, here is the same from his gitbash shell:

MINGW64_NT-10.0-22000 ... 3.1.7-340.x86_64 2021-03-26 22:17 UTC x86_64
Msys

He is running Windows 11 (as I am).

What else can I try to narrow this down?

On Tue, Jun 13, 2023 at 2:54 PM David Karr 
wrote:

> I have been using Cygwin for many years, although I wouldn't call myself
> an advanced user.
>
> I'm working with some much newer users.  They set up Cygwin, but I didn't
> see them do it. I ran "uname -a" and it was about the same as mine.  I
> compared the output of "env|sort" and I saw some differences, but I can't
> tell if they were significant.
>
> When I run the following command:
>
> kubectl config use-context dev2ff
>
> It works perfectly fine, setting the correct context.  When this user I'm
> working with runs the same command, he gets this (replacing his userid with
> "..."):
>
> error: FindFirstFile C:\cygwin64\home\.../.kube/config: The directory
> name is invalid.
>
> He did have "HOME=/c/Users/...", but I had him change it to "/home/...",
> but that didn't make any difference.
>
> I'm not sure what could be happening here.
>

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

Trying to figure out what is wrong in a colleague's Cygwin setup

[David Karr via Cygwin]

I have been using Cygwin for many years, although I wouldn't call myself an
advanced user.

I'm working with some much newer users.  They set up Cygwin, but I didn't
see them do it. I ran "uname -a" and it was about the same as mine.  I
compared the output of "env|sort" and I saw some differences, but I can't
tell if they were significant.

When I run the following command:

kubectl config use-context dev2ff

It works perfectly fine, setting the correct context.  When this user I'm
working with runs the same command, he gets this (replacing his userid with
"..."):

error: FindFirstFile C:\cygwin64\home\.../.kube/config: The directory
name is invalid.

He did have "HOME=/c/Users/...", but I had him change it to "/home/...",
but that didn't make any difference.

I'm not sure what could be happening here.

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

Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Wed, Jun 17, 2020 at 6:06 PM Brian Inglis  wrote:

> On 2020-06-17 10:39, David Karr via Cygwin wrote:
> > On Mon, Jun 15, 2020 at 9:10 AM David Karr wrote:
> >> On Sun, Jun 14, 2020 at 12:32 PM David Karr wrote:
> >>> On Sun, Jun 14, 2020 at 12:09 PM Brian Inglis wrote:
> >>>> On 2020-06-14 12:16, David Karr via Cygwin wrote:
> >>>>> On Sun, Jun 14, 2020 at 10:20 AM Brian Inglis wrote:
> >>>>>> On 2020-06-14 09:38, David Karr via Cygwin wrote:
> >>>>>>> On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:
> >>>>>>>> On 14.06.2020 08:12, David Karr wrote:
> >>>>>>>>> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
> >>>>>>>>>> On 13.06.2020 20:53, David Karr via Cygwin wrote:
> >>>>>>>>>>> I've been using kubectl in Cygwin on Windows 10 for quite a
> >>>> while,
> >>>>>>>>>>> to communicate to our in-house k8s clusters. I often use
> "kubectl
> >>>>>>>>>>> exec" to open a shell in a container or directly execute a
> shell
> >>>>>>>>>>> command.
> >>>>>>>>>>> This has worked perfectly fine for a long time.
> >>>>>>>>>>> A couple of days ago, I discovered that all of these attempts
> >>>> were
> >>>>>>>>>>> failing with "Upgrade request required".  I hadn't upgraded
> >>>> kubectl
> >>>>>>>>>>> or Cygwin in quite a while. I doubt our clusters had a k8s
> >>>> upgrade,
> >>>>>>>>>>> but it's entirely possible.
> >>>>>>>>>>> A colleague of mine has a very similar desktop configuration
> >>>>>>>>>>> (Windows 10, Cygwin), and he's not seeing this symptom.
> >>>>>>>>>>> I noticed that when I ran "kubectl exec" with max verbosity, it
> >>>> shows
> >>>>>>>>>>> the resulting "curl" command that it runs. I tried that
> resulting
> >>>>>>>>>>> command, and it results in the same response. I then tried
> >>>> updating
> >>>>>>>>>>> my Cygwin tools and retesting, no change.>>>>> I then took the
> >>>>>> entire resulting "kubectl exec" command line and ran
> >>>>>>>>>>> it in a "cmd" shell.  No problem at all.  No error.
> >>>>>>>>>>> I know I haven't provided much useful information yet. I wanted
> >>>> to
> >>>>>>>>>>> get an initial response before I started providing those
> >>>> diagnostics.
> >>>>>>>>>>> Is there a clear issue here that I'm not aware of?
> >>>>>>
> >>>>>>>>> from where is kubectl coming from ?
> >>>>>>>>> In cygwin I found only a kubectl.py in the ansible package
> >>>>>>
> >>>>>>>>>> It's from here:
> >>>>>>>>>>
> >>>>>>
> >>>>
> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
> >>>>>>
> >>>>>>>> so it is NOT a cygwin program.
> >>>>>>>> If the warning is coming about curl, it is likely
> >>>>>>>> that using from cygwin you are using the cygwin curl
> >>>>>>>> and from CMD the windows one
> >>>>>>>> $ which -a curl
> >>>>>>>> /usr/bin/curl
> >>>>>>>> /cygdrive/c/WINDOWS/system32/curl
> >>>>>>>> $ /cygdrive/c/WINDOWS/system32/curl -V
> >>>>>>>> curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
> >>>>>>>> Release-Date: 2017-11-14, security patched: 2019-11-05
> >>>>>>>> Protocols: dict file ftp ftps http https imap imaps pop3 pop3s
> smtp
> >>>>>> smtps
> >>>>>>>> telnet tftp
> >>>>>>>> Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
> >>>>>>>>
> >>>>>>>> $ /usr/bin/curl -V
> >>>>>>&

Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Mon, Jun 15, 2020 at 9:10 AM David Karr wrote:

>
> On Sun, Jun 14, 2020 at 12:32 PM David Karr wrote:
>
>>
>> On Sun, Jun 14, 2020 at 12:09 PM Brian Inglis <
>> brian.ing...@systematicsw.ab.ca> wrote:
>>
>>> On 2020-06-14 12:16, David Karr via Cygwin wrote:
>>> > On Sun, Jun 14, 2020 at 10:20 AM Brian Inglis <
>>> > brian.ing...@systematicsw.ab.ca> wrote:
>>> >
>>> >> On 2020-06-14 09:38, David Karr via Cygwin wrote:
>>> >>> On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:
>>> >>>> On 14.06.2020 08:12, David Karr wrote:
>>> >>>>> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
>>> >>>>>> On 13.06.2020 20:53, David Karr via Cygwin wrote:
>>> >>>>>>> I've been using kubectl in Cygwin on Windows 10 for quite a
>>> while,
>>> >>>>>>> to communicate to our in-house k8s clusters. I often use "kubectl
>>> >>>>>>> exec" to open a shell in a container or directly execute a shell
>>> >>>>>>> command.
>>> >>>>>>> This has worked perfectly fine for a long time.
>>> >>>>>>> A couple of days ago, I discovered that all of these attempts
>>> were
>>> >>>>>>> failing with "Upgrade request required".  I hadn't upgraded
>>> kubectl
>>> >>>>>>> or Cygwin in quite a while. I doubt our clusters had a k8s
>>> upgrade,
>>> >>>>>>> but it's entirely possible.
>>> >>>>>>> A colleague of mine has a very similar desktop configuration
>>> >>>>>>> (Windows 10, Cygwin), and he's not seeing this symptom.
>>> >>>>>>> I noticed that when I ran "kubectl exec" with max verbosity, it
>>> shows
>>> >>>>>>> the resulting "curl" command that it runs. I tried that resulting
>>> >>>>>>> command, and it results in the same response. I then tried
>>> updating
>>> >>>>>>> my Cygwin tools and retesting, no change.>>>>> I then took the
>>> >> entire resulting "kubectl exec" command line and ran
>>> >>>>>>> it in a "cmd" shell.  No problem at all.  No error.
>>> >>>>>>> I know I haven't provided much useful information yet. I wanted
>>> to
>>> >>>>>>> get an initial response before I started providing those
>>> diagnostics.
>>> >>>>>>> Is there a clear issue here that I'm not aware of?
>>> >>
>>> >>>>> from where is kubectl coming from ?
>>> >>>>> In cygwin I found only a kubectl.py in the ansible package
>>> >>
>>> >>>>>> It's from here:
>>> >>>>>>
>>> >>
>>> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
>>> >>
>>> >>>> so it is NOT a cygwin program.
>>> >>>> If the warning is coming about curl, it is likely
>>> >>>> that using from cygwin you are using the cygwin curl
>>> >>>> and from CMD the windows one
>>> >>>> $ which -a curl
>>> >>>> /usr/bin/curl
>>> >>>> /cygdrive/c/WINDOWS/system32/curl
>>> >>>> $ /cygdrive/c/WINDOWS/system32/curl -V
>>> >>>> curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
>>> >>>> Release-Date: 2017-11-14, security patched: 2019-11-05
>>> >>>> Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp
>>> >> smtps
>>> >>>> telnet tftp
>>> >>>> Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
>>> >>>>
>>> >>>> $ /usr/bin/curl -V
>>> >>>> curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f
>>> zlib/1.2.11
>>> >>>> brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
>>> >>>> libssh/0.8.7/openssl/zlib nghttp2/1.37.0
>>> >>>> Release-Date: 2019-09-11
>>> >>>> Protocols: dict file ftp ftps gopher http https imap imaps ldap
>>> ldaps
>>> >>>> pop3 pop3s rtsp scp sftp smb smbs smtp s

Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Sun, Jun 14, 2020 at 12:32 PM David Karr wrote:

>
> On Sun, Jun 14, 2020 at 12:09 PM Brian Inglis <
> brian.ing...@systematicsw.ab.ca> wrote:
>
>> On 2020-06-14 12:16, David Karr via Cygwin wrote:
>> > On Sun, Jun 14, 2020 at 10:20 AM Brian Inglis <
>> > brian.ing...@systematicsw.ab.ca> wrote:
>> >
>> >> On 2020-06-14 09:38, David Karr via Cygwin wrote:
>> >>> On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:
>> >>>> On 14.06.2020 08:12, David Karr wrote:
>> >>>>> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
>> >>>>>> On 13.06.2020 20:53, David Karr via Cygwin wrote:
>> >>>>>>> I've been using kubectl in Cygwin on Windows 10 for quite a while,
>> >>>>>>> to communicate to our in-house k8s clusters. I often use "kubectl
>> >>>>>>> exec" to open a shell in a container or directly execute a shell
>> >>>>>>> command.
>> >>>>>>> This has worked perfectly fine for a long time.
>> >>>>>>> A couple of days ago, I discovered that all of these attempts were
>> >>>>>>> failing with "Upgrade request required".  I hadn't upgraded
>> kubectl
>> >>>>>>> or Cygwin in quite a while. I doubt our clusters had a k8s
>> upgrade,
>> >>>>>>> but it's entirely possible.
>> >>>>>>> A colleague of mine has a very similar desktop configuration
>> >>>>>>> (Windows 10, Cygwin), and he's not seeing this symptom.
>> >>>>>>> I noticed that when I ran "kubectl exec" with max verbosity, it
>> shows
>> >>>>>>> the resulting "curl" command that it runs. I tried that resulting
>> >>>>>>> command, and it results in the same response. I then tried
>> updating
>> >>>>>>> my Cygwin tools and retesting, no change.>>>>> I then took the
>> >> entire resulting "kubectl exec" command line and ran
>> >>>>>>> it in a "cmd" shell.  No problem at all.  No error.
>> >>>>>>> I know I haven't provided much useful information yet. I wanted to
>> >>>>>>> get an initial response before I started providing those
>> diagnostics.
>> >>>>>>> Is there a clear issue here that I'm not aware of?
>> >>
>> >>>>> from where is kubectl coming from ?
>> >>>>> In cygwin I found only a kubectl.py in the ansible package
>> >>
>> >>>>>> It's from here:
>> >>>>>>
>> >>
>> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
>> >>
>> >>>> so it is NOT a cygwin program.
>> >>>> If the warning is coming about curl, it is likely
>> >>>> that using from cygwin you are using the cygwin curl
>> >>>> and from CMD the windows one
>> >>>> $ which -a curl
>> >>>> /usr/bin/curl
>> >>>> /cygdrive/c/WINDOWS/system32/curl
>> >>>> $ /cygdrive/c/WINDOWS/system32/curl -V
>> >>>> curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
>> >>>> Release-Date: 2017-11-14, security patched: 2019-11-05
>> >>>> Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp
>> >> smtps
>> >>>> telnet tftp
>> >>>> Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
>> >>>>
>> >>>> $ /usr/bin/curl -V
>> >>>> curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f
>> zlib/1.2.11
>> >>>> brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
>> >>>> libssh/0.8.7/openssl/zlib nghttp2/1.37.0
>> >>>> Release-Date: 2019-09-11
>> >>>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
>> >>>> pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
>> >>>> Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6
>> >>>> Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP
>> >>>> TrackMemory UnixSockets
>> >>>> the support Forum https://discuss.kubernetes.io/
>> >>>> is probably the most indicate place for guidance

Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Sun, Jun 14, 2020 at 12:09 PM Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

> On 2020-06-14 12:16, David Karr via Cygwin wrote:
> > On Sun, Jun 14, 2020 at 10:20 AM Brian Inglis <
> > brian.ing...@systematicsw.ab.ca> wrote:
> >
> >> On 2020-06-14 09:38, David Karr via Cygwin wrote:
> >>> On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:
> >>>> On 14.06.2020 08:12, David Karr wrote:
> >>>>> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
> >>>>>> On 13.06.2020 20:53, David Karr via Cygwin wrote:
> >>>>>>> I've been using kubectl in Cygwin on Windows 10 for quite a while,
> >>>>>>> to communicate to our in-house k8s clusters. I often use "kubectl
> >>>>>>> exec" to open a shell in a container or directly execute a shell
> >>>>>>> command.
> >>>>>>> This has worked perfectly fine for a long time.
> >>>>>>> A couple of days ago, I discovered that all of these attempts were
> >>>>>>> failing with "Upgrade request required".  I hadn't upgraded kubectl
> >>>>>>> or Cygwin in quite a while. I doubt our clusters had a k8s upgrade,
> >>>>>>> but it's entirely possible.
> >>>>>>> A colleague of mine has a very similar desktop configuration
> >>>>>>> (Windows 10, Cygwin), and he's not seeing this symptom.
> >>>>>>> I noticed that when I ran "kubectl exec" with max verbosity, it
> shows
> >>>>>>> the resulting "curl" command that it runs. I tried that resulting
> >>>>>>> command, and it results in the same response. I then tried updating
> >>>>>>> my Cygwin tools and retesting, no change.>>>>> I then took the
> >> entire resulting "kubectl exec" command line and ran
> >>>>>>> it in a "cmd" shell.  No problem at all.  No error.
> >>>>>>> I know I haven't provided much useful information yet. I wanted to
> >>>>>>> get an initial response before I started providing those
> diagnostics.
> >>>>>>> Is there a clear issue here that I'm not aware of?
> >>
> >>>>> from where is kubectl coming from ?
> >>>>> In cygwin I found only a kubectl.py in the ansible package
> >>
> >>>>>> It's from here:
> >>>>>>
> >>
> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
> >>
> >>>> so it is NOT a cygwin program.
> >>>> If the warning is coming about curl, it is likely
> >>>> that using from cygwin you are using the cygwin curl
> >>>> and from CMD the windows one
> >>>> $ which -a curl
> >>>> /usr/bin/curl
> >>>> /cygdrive/c/WINDOWS/system32/curl
> >>>> $ /cygdrive/c/WINDOWS/system32/curl -V
> >>>> curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
> >>>> Release-Date: 2017-11-14, security patched: 2019-11-05
> >>>> Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp
> >> smtps
> >>>> telnet tftp
> >>>> Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
> >>>>
> >>>> $ /usr/bin/curl -V
> >>>> curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f
> zlib/1.2.11
> >>>> brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
> >>>> libssh/0.8.7/openssl/zlib nghttp2/1.37.0
> >>>> Release-Date: 2019-09-11
> >>>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
> >>>> pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
> >>>> Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6
> >>>> Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP
> >>>> TrackMemory UnixSockets
> >>>> the support Forum https://discuss.kubernetes.io/
> >>>> is probably the most indicate place for guidance
> >>
> >>> I thought it was obvious that it was not working because it was calling
> >> the
> >>> Cygwin curl. I wouldn't have posted here if that wasn't obvious to me.
> >>> And since I'm well aware of the k8s community, I already posted
> questions
> >>> about this in the appropriate place, before

Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Sun, Jun 14, 2020 at 10:20 AM Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

> On 2020-06-14 09:38, David Karr via Cygwin wrote:
> > On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:
> >> On 14.06.2020 08:12, David Karr wrote:
> >>> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
> >>>> On 13.06.2020 20:53, David Karr via Cygwin wrote:
> >>>>> I've been using kubectl in Cygwin on Windows 10 for quite a while,
> >>>>> to communicate to our in-house k8s clusters. I often use "kubectl
> >>>>> exec" to open a shell in a container or directly execute a shell
> >>>>> command.
> >>>>> This has worked perfectly fine for a long time.
> >>>>> A couple of days ago, I discovered that all of these attempts were
> >>>>> failing with "Upgrade request required".  I hadn't upgraded kubectl
> >>>>> or Cygwin in quite a while. I doubt our clusters had a k8s upgrade,
> >>>>> but it's entirely possible.
> >>>>> A colleague of mine has a very similar desktop configuration
> >>>>> (Windows 10, Cygwin), and he's not seeing this symptom.
> >>>>> I noticed that when I ran "kubectl exec" with max verbosity, it shows
> >>>>> the resulting "curl" command that it runs. I tried that resulting
> >>>>> command, and it results in the same response. I then tried updating
> >>>>> my Cygwin tools and retesting, no change.>>>>> I then took the
> entire resulting "kubectl exec" command line and ran
> >>>>> it in a "cmd" shell.  No problem at all.  No error.
> >>>>> I know I haven't provided much useful information yet. I wanted to
> >>>>> get an initial response before I started providing those diagnostics.
> >>>>> Is there a clear issue here that I'm not aware of?
>
> >>> from where is kubectl coming from ?
> >>> In cygwin I found only a kubectl.py in the ansible package
>
> >>>> It's from here:
> >>>>
> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
>
> >> so it is NOT a cygwin program.
> >> If the warning is coming about curl, it is likely
> >> that using from cygwin you are using the cygwin curl
> >> and from CMD the windows one
> >> $ which -a curl
> >> /usr/bin/curl
> >> /cygdrive/c/WINDOWS/system32/curl
> >> $ /cygdrive/c/WINDOWS/system32/curl -V
> >> curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
> >> Release-Date: 2017-11-14, security patched: 2019-11-05
> >> Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp
> smtps
> >> telnet tftp
> >> Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
> >>
> >> $ /usr/bin/curl -V
> >> curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f zlib/1.2.11
> >> brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
> >> libssh/0.8.7/openssl/zlib nghttp2/1.37.0
> >> Release-Date: 2019-09-11
> >> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
> >> pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
> >> Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6
> >> Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP
> >> TrackMemory UnixSockets
> >> the support Forum https://discuss.kubernetes.io/
> >> is probably the most indicate place for guidance
>
> > I thought it was obvious that it was not working because it was calling
> the
> > Cygwin curl. I wouldn't have posted here if that wasn't obvious to me.
> > And since I'm well aware of the k8s community, I already posted questions
> > about this in the appropriate place, before I posted here.
> > What I was hoping to get here was some indication or thoughts on why a
> > process using Windows curl doesn't have a problem, but does have a
> problem
> > when using Cygwin Curl. This isn't likely something that Cygwin curl is
> > doing "wrong", it's just that it's doing something different.
> > If it matters, the following is an elided version of the resulting curl
> > command:
> > curl -k -v -XPOST  -H "User-Agent: kubectl.exe/v1.18.0
> (windows/amd64)
> > kubernetes/9e99141" -H "Authorization: Bearer ..." -H
> > "X-Stream-Protocol-Version: v4.channel.k8s.io" -H
> > "X-Stream-Protocol-Version:

Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:

> On 14.06.2020 08:12, David Karr wrote:
> >
> >
> > On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
> >
> >     On 13.06.2020 20:53, David Karr via Cygwin wrote:
> >  > I've been using kubectl in Cygwin on Windows 10 for quite a
> while, to
> >  > communicate to our in-house k8s clusters. I often use "kubectl
> > exec" to
> >  > open a shell in a container or directly execute a shell command.
> > This has
> >  > worked perfectly fine for a long time.
> >  >
> >  > A couple of days ago, I discovered that all of these attempts
> > were failing
> >  > with "Upgrade request required".  I hadn't upgraded kubectl or
> > Cygwin in
> >  > quite a while. I doubt our clusters had a k8s upgrade, but it's
> > entirely
> >  > possible.
> >  >
> >  > A colleague of mine has a very similar desktop configuration
> > (Windows 10,
> >  > Cygwin), and he's not seeing this symptom.
> >  >
> >  > I noticed that when I ran "kubectl exec" with max verbosity, it
> > shows the
> >  > resulting "curl" command that it runs. I tried that resulting
> > command, and
> >  > it results in the same response. I then tried updating my Cygwin
> > tools and
> >  > retesting, no change.
> >  >
> >  > I then took the entire resulting "kubectl exec" command line and
> > ran it in
> >  > a "cmd" shell.  No problem at all.  No error.
> >  >
> >  > I know I haven't provided much useful information yet. I wanted
> > to get an
> >  > initial response before I started providing those diagnostics. Is
> > there a
> >  > clear issue here that I'm not aware of?
> >  > --
> >
> > from where is kubectl coming from ?
> >
> > In cygwin I found only a kubectl.py in the ansible package
> >
> >
> > It's from here:
> >
> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
> > .
>
> so it is NOT a cygwin program.
>
> If the warning is coming about curl, it is likely
> that using from cygwin you are using the cygwin curl
> and from CMD the windows one
>
>
> $ which -a curl
> /usr/bin/curl
> /cygdrive/c/WINDOWS/system32/curl
>
>
> $ /cygdrive/c/WINDOWS/system32/curl -V
> curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
> Release-Date: 2017-11-14, security patched: 2019-11-05
> Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp
> smtps telnet
>   tftp
> Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
>
> $ /usr/bin/curl -V
> curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f zlib/1.2.11
> brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
> libssh/0.8.7/openssl/zlib nghttp2/1.37.0
> Release-Date: 2019-09-11
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
> pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
> Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6
> Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP
> TrackMemory UnixSockets
>
>
> the support Forum https://discuss.kubernetes.io/
> is probably the most indicate place for guidance
>
> Regards
> Marco
>

I thought it was obvious that it was not working because it was calling the
Cygwin curl. I wouldn't have posted here if that wasn't obvious to me.

And since I'm well aware of the k8s community, I already posted questions
about this in the appropriate place, before I posted here.

What I was hoping to get here was some indication or thoughts on why a
process using Windows curl doesn't have a problem, but does have a problem
when using Cygwin Curl. This isn't likely something that Cygwin curl is
doing "wrong", it's just that it's doing something different.

If it matters, the following is an elided version of the resulting curl
command:

curl -k -v -XPOST  -H "User-Agent: kubectl.exe/v1.18.0 (windows/amd64)
kubernetes/9e99141" -H "Authorization: Bearer ..." -H
"X-Stream-Protocol-Version: v4.channel.k8s.io" -H
"X-Stream-Protocol-Version: v3.channel.k8s.io" -H
"X-Stream-Protocol-Version: v2.channel.k8s.io" -H
"X-Stream-Protocol-Version: channel.k8s.io" 'https://
.../api/v1/namespaces/.../pods/.../exec?command=%2Fbin%2Fls=...=true=true=true'

I can't tell from the logging what request body it sent. It's possible it
didn't send any.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:

> On 13.06.2020 20:53, David Karr via Cygwin wrote:
> > I've been using kubectl in Cygwin on Windows 10 for quite a while, to
> > communicate to our in-house k8s clusters. I often use "kubectl exec" to
> > open a shell in a container or directly execute a shell command.  This
> has
> > worked perfectly fine for a long time.
> >
> > A couple of days ago, I discovered that all of these attempts were
> failing
> > with "Upgrade request required".  I hadn't upgraded kubectl or Cygwin in
> > quite a while. I doubt our clusters had a k8s upgrade, but it's entirely
> > possible.
> >
> > A colleague of mine has a very similar desktop configuration (Windows 10,
> > Cygwin), and he's not seeing this symptom.
> >
> > I noticed that when I ran "kubectl exec" with max verbosity, it shows the
> > resulting "curl" command that it runs. I tried that resulting command,
> and
> > it results in the same response. I then tried updating my Cygwin tools
> and
> > retesting, no change.
> >
> > I then took the entire resulting "kubectl exec" command line and ran it
> in
> > a "cmd" shell.  No problem at all.  No error.
> >
> > I know I haven't provided much useful information yet. I wanted to get an
> > initial response before I started providing those diagnostics. Is there a
> > clear issue here that I'm not aware of?
> > --
>
> from where is kubectl coming from ?
>
> In cygwin I found only a kubectl.py in the ansible package
>

It's from here:
https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

"kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

I've been using kubectl in Cygwin on Windows 10 for quite a while, to
communicate to our in-house k8s clusters. I often use "kubectl exec" to
open a shell in a container or directly execute a shell command.  This has
worked perfectly fine for a long time.

A couple of days ago, I discovered that all of these attempts were failing
with "Upgrade request required".  I hadn't upgraded kubectl or Cygwin in
quite a while. I doubt our clusters had a k8s upgrade, but it's entirely
possible.

A colleague of mine has a very similar desktop configuration (Windows 10,
Cygwin), and he's not seeing this symptom.

I noticed that when I ran "kubectl exec" with max verbosity, it shows the
resulting "curl" command that it runs. I tried that resulting command, and
it results in the same response. I then tried updating my Cygwin tools and
retesting, no change.

I then took the entire resulting "kubectl exec" command line and ran it in
a "cmd" shell.  No problem at all.  No error.

I know I haven't provided much useful information yet. I wanted to get an
initial response before I started providing those diagnostics. Is there a
clear issue here that I'm not aware of?
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Why didn't a Cygwin install create the default dot files?

[David Karr via Cygwin]

I've been using Cygwin for a long time. I haven't run a fresh install for
quite a while.

A colleague just installed Cygwin for the first time, following my basic
instructions. He ended up with his Cygwin home being the same as his
Windows home, which is different from my setup, but I think that's fine.
What seems odd is that he didn't get the default dot files created, being
.profile, .bash_profile, and .bashrc.  I don't even remember whether this
happened the first time I set it up.  In any case, I handed him my dot
files to template from, but I was curious about that process.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: After cygwin upgrade, Emacs shell buffers with colors are corrupted

[David Karr via Cygwin]

On Wed, Mar 18, 2020 at 2:17 PM David Karr <> wrote:

> On Wed, Mar 18, 2020 at 9:38 AM Ken Brown via Cygwin <> wrote:
>
>> On 3/18/2020 11:22 AM, Andrey Repin wrote:
>> > Greetings, David Karr!
>> >
>> >> Thanks, that worked.  For now, I guess I have to figure out how to set
>> that
>> >> property permanently, or until this pty bug is fixed.. I start Emacs
>> from a
>> >> shortcut, executing "emacs.xml".  I see the file appears to have some
>> >> syntax for setting the environment, but I've never inspected that file
>> >> before.
>> >
>> > You set it in Windows.
>>
>> Not necessarily.  He might just want to set it for emacs.  Editing
>> emacs.xml is
>> a fine way to do it.
>>
>
> I have no idea whether I would want to do it only for Emacs, as I don't
> know what the issue is.
>
> However, if I wanted to, could you point me to the documentation for
> changing that file?  The README doesn't say anything about this.
>
>
Just so it's clear, Ken Brown directly sent me some information of what he
knew about the emacs.xml documentation, but it didn't appear to work.

I've verified that setting the CYGWIN variable globally to "disable_pcon"
has resolved the problem.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: After cygwin upgrade, Emacs shell buffers with colors are corrupted

[David Karr via Cygwin]

On Wed, Mar 18, 2020 at 9:38 AM Ken Brown via Cygwin <> wrote:

> On 3/18/2020 11:22 AM, Andrey Repin wrote:
> > Greetings, David Karr!
> >
> >> Thanks, that worked.  For now, I guess I have to figure out how to set
> that
> >> property permanently, or until this pty bug is fixed.. I start Emacs
> from a
> >> shortcut, executing "emacs.xml".  I see the file appears to have some
> >> syntax for setting the environment, but I've never inspected that file
> >> before.
> >
> > You set it in Windows.
>
> Not necessarily.  He might just want to set it for emacs.  Editing
> emacs.xml is
> a fine way to do it.
>

I have no idea whether I would want to do it only for Emacs, as I don't
know what the issue is.

However, if I wanted to, could you point me to the documentation for
changing that file?  The README doesn't say anything about this.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: After cygwin upgrade, Emacs shell buffers with colors are corrupted

[David Karr via Cygwin]

Thanks, that worked.  For now, I guess I have to figure out how to set that
property permanently, or until this pty bug is fixed.. I start Emacs from a
shortcut, executing "emacs.xml".  I see the file appears to have some
syntax for setting the environment, but I've never inspected that file
before.

On Tue, Mar 17, 2020 at 6:04 PM Ken Brown via Cygwin 
wrote:

> On 3/17/2020 7:14 PM, David Karr via Cygwin wrote:
> > Yesterday I upgraded Cygwin, which I hadn't done in a while. I had
> recently
> > upgraded my Windows 10 OS from build 1709 to 1809 (yes, those are
> correct).
> >
> > My current Emacs version is 26.3, but I don't know what it was before the
> > upgrade.
> >
> > If I create a shell buffer and execute a command that produces plain,
> > uncolored output, it appears to work fine.  However, output from "Maven"
> > has always been colorized for me, and it's always worked fine.  Today,
> I'm
> > seeing that the output is severely corrupted.  If I pipe the output into
> a
> > file and view that, which doesn't have colors, the contents are fine. I
> > also ran the same process in a mintty window, which is colorized in the
> > same way, and that is also working fine.
> >
> > For instance, if this is what I see in a mintty buffer:
> > ---
> > [WACDTL03DK068X:~/git/cartms] mvn package
> > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
> > MaxPermSize=128m; sup
> > port was removed in 8.0
> > [INFO] Scanning for projects...
> > [WARNING]
> > ...
> > -
> >
> > What I see in the Emacs shell buffer is something like this:
> > -
> > [WACDTL03DK068X:~/git/cartms] mvn package
> > [WACDTL03DK068X:~/git/cartms] [WACDTL03DK068X:~/git/cartms] Java
> > HotSpot(TM) 64-
> > Bit Server VM warning:ignoring option MaxPermSize=128m; support was
> removed
> > in
> > 8.0
> > [INFO] Scanning for projects...[
> > [WARNING] l
> >
> >
> >
> >
> >
> > 
> > ---
> >
> > The first thing I see is that it prints the shell prompt twice AFTER
> > pressing enter on the command line to run. That might possibly be an
> issue
> > with my Bash dot files, but this didn't happen before the Cygwin upgrade,
> > and it doesn't happen in the mintty window.
> >
> > After that, it gets even worse.  The "Java HotSpot ..." line prints in
> > three lines, instead of a single line.  Then, the first "WARNING" line
> has
> > the "l" at the end of the line, and then numerous blank lines.  The rest
> of
> > the output is mangled in other ways.
> >
> > Any ideas what might be wrong here?
>
> This is probably related to the new pty code.  Does it help if you start
> emacs
> like this?
>
>CYGWIN=disable_pcon emacs
>
> If so, that confirms my guess and gives you a workaround.
>
> Ken
> --
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

After cygwin upgrade, Emacs shell buffers with colors are corrupted

[David Karr via Cygwin]

Yesterday I upgraded Cygwin, which I hadn't done in a while. I had recently
upgraded my Windows 10 OS from build 1709 to 1809 (yes, those are correct).

My current Emacs version is 26.3, but I don't know what it was before the
upgrade.

If I create a shell buffer and execute a command that produces plain,
uncolored output, it appears to work fine.  However, output from "Maven"
has always been colorized for me, and it's always worked fine.  Today, I'm
seeing that the output is severely corrupted.  If I pipe the output into a
file and view that, which doesn't have colors, the contents are fine. I
also ran the same process in a mintty window, which is colorized in the
same way, and that is also working fine.

For instance, if this is what I see in a mintty buffer:
---
[WACDTL03DK068X:~/git/cartms] mvn package
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=128m; sup
port was removed in 8.0
[INFO] Scanning for projects...
[WARNING]
...
-

What I see in the Emacs shell buffer is something like this:
-
[WACDTL03DK068X:~/git/cartms] mvn package
[WACDTL03DK068X:~/git/cartms] [WACDTL03DK068X:~/git/cartms] Java
HotSpot(TM) 64-
Bit Server VM warning:ignoring option MaxPermSize=128m; support was removed
in
8.0
[INFO] Scanning for projects...[
[WARNING] l






---

The first thing I see is that it prints the shell prompt twice AFTER
pressing enter on the command line to run. That might possibly be an issue
with my Bash dot files, but this didn't happen before the Cygwin upgrade,
and it doesn't happen in the mintty window.

After that, it gets even worse.  The "Java HotSpot ..." line prints in
three lines, instead of a single line.  Then, the first "WARNING" line has
the "l" at the end of the line, and then numerous blank lines.  The rest of
the output is mangled in other ways.

Any ideas what might be wrong here?
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Conflict between Eclipse JGit and Cygwin HOME

[David Karr via Cygwin]

On Mon, Mar 16, 2020 at 11:20 PM Brian Inglis wrote:

> On 2020-03-16 19:03, Andrey Repin wrote:
> > Greetings, David Karr!
> >
> >> I've been running Cygwin on my Windows 10 laptop for quite a while.  I
> use
> >> git in Eclipse and in the shell.
> >
> >> What I'm describing isn't really a bug with Cygwin, but it breaks
> because
> >> of the interaction with Cygwin, and I'm trying to find out a reasonable
> way
> >> to fix this.
> >
> >> Over the weekend, I upgraded Windows 10 from 1709 to 1809.  Somehow
> after
> >> that I have messed up how git is used in Eclipse.
> >
> >> The Eclipse JGit framework figures out where my git config is by
> checking
> >> things in the following order:
> >
> >> - 1. %HOME% if set,
> >> - 2. %HOMEDRIVE%\%HOMEPATH%, if %HOMEDRIVE% is set,
> >> - 3. %HOMESHARE% if set,
> >> - 4. Java system property "user.home".
> >
> >> The HOMEDRIVE, HOMEPATH, and HOMESHARE variables are set by my work
> >> infrastructure, and I appear to have no control over them. The resulting
> >> %HOMEDRIVE%\%HOMEPATH% doesn't even exist.
> >
> > It should, that's nonsense. File an issue with your infrastructure team.
> >
> >> The HOME variable is set by Cygwin, apparently.
> >
> > No, it only set HOME if it is not set yet, and even then only for login
> > shells.
> >
> >> It is set to "/home/".
> >
> > What "myid" is supposed to mean? HOME is set to /home/$USER by default,
> but
> > can be overridden with proper nsswitch configuration.
> >
> >> I'm guessing that JGit looks at that and can't do
> >> anything with it, so it goes down the list and doesn't find anything
> >> useful. I end up with bad git config values.
> >
> > Just install Git for Windows, but don't add it to %PATH% in any way,
> shape or
> > form. Then configure Eclipse to use that git instead of Cygwin one.
> >
> >> The workaround I've figured out is a batch file that sets HOME to the
> >> expected Windows HOME, and then executes its command-line parameters.  I
> >> changed the target property in the Eclipse shortcut to add the full
> path to
> >> this batch file at the front of the command line, and then I have to
> find
> >> the eclipse.exe file and get the desktop icon from it.  I'll have to do
> >> this every time I install a new Eclipse distribution.
> >
> > Start by solving the issue from its head.
> > Fix your %HOMEDRIVE%/%HOMEPATH%/%HOMESHARE%, configure your nsswitch to
> point
> > to an existing profile path.
>
> You problem seems to be with your Windows network profile and Windows
> programs,
> nothing to do with Cygwin.
> Fixing the former will probably fix the latter.
>

If it wasn't obvious, I'm trying to find a solution, not assign blame.  Of
course it has "something to do with Cygwin", because I'm using it, and
Cygwin and WIndows are using a shared resource, the "HOME" variable.
Cygwin and Windows try to use it for different purposes.  There's nothing I
can do about the "Windows network profile".


> But if your work infrastructure does not yet support W10 1809 (do you
> really
> mean that release, not the current 1909 release?) you should not have
> upgraded,
> and any breakage is down to you.
>

Again, you took this as me trying to assign blame, which is pointless.

Yes, I meant 1809, and although I performed the upgrade manually, it would
have been done automatically in the near future if I hadn't, so there was
no choice there.


> For Cygwin options see:
>
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-desc


Yes, I've seen that, and considered my options there, but I don't think
that will address this situation.  The problem is the contents of the
"HOME" variable. It doesn't matter where my Cygwin HOME directory actually
resides.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Conflict between Eclipse JGit and Cygwin HOME

[David Karr via Cygwin]

I've been running Cygwin on my Windows 10 laptop for quite a while.  I use
git in Eclipse and in the shell.

What I'm describing isn't really a bug with Cygwin, but it breaks because
of the interaction with Cygwin, and I'm trying to find out a reasonable way
to fix this.

Over the weekend, I upgraded Windows 10 from 1709 to 1809.  Somehow after
that I have messed up how git is used in Eclipse.

The Eclipse JGit framework figures out where my git config is by checking
things in the following order:

- 1. %HOME% if set,
- 2. %HOMEDRIVE%\%HOMEPATH%, if %HOMEDRIVE% is set,
- 3. %HOMESHARE% if set,
- 4. Java system property "user.home".

The HOMEDRIVE, HOMEPATH, and HOMESHARE variables are set by my work
infrastructure, and I appear to have no control over them. The resulting
%HOMEDRIVE%\%HOMEPATH% doesn't even exist.

The HOME variable is set by Cygwin, apparently.  It is set to
"/home/".  I'm guessing that JGit looks at that and can't do
anything with it, so it goes down the list and doesn't find anything
useful. I end up with bad git config values.

The workaround I've figured out is a batch file that sets HOME to the
expected Windows HOME, and then executes its command-line parameters.  I
changed the target property in the Eclipse shortcut to add the full path to
this batch file at the front of the command line, and then I have to find
the eclipse.exe file and get the desktop icon from it.  I'll have to do
this every time I install a new Eclipse distribution.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: More on Win7 update messing up HOME

[David Karr]

On Sat, Aug 17, 2019 at 12:12 AM Achim Gratz  wrote:

> David Karr writes:
> > I noticed that when I do an "ls -lt" in my homedir, instead of the owner
> > and group of files being my simple uid, it's something like
> > "+User(1944941)" and "2993517" (group and user, respectively, I
> > believe).
>
> There's your problem.  For whatever reason, the DC did not resolve your
> user ID when it was asked by Cygwin and so all the other information
> associated with your account is likewise unavailable.  Are you starting
> any Cygwin services at boot?  If so, make them depend on tcp_ip so they
> don't start before networking is available and/or set them to delayed
> start.  If that doesn't fix it, check the user they are running under,
> both cygserver and sshd should run under LocalSystem for an up-to-date
> Cygwin.
>

About a month ago I worked on getting crontab working. I hadn't done it
before, and I found there were lots of details that were hard to get right.
I'd have to review it again to remember how that is set up.

In the older setup, without the physical passwd or group files, what would
happen if I rebooted at a point when the laptop wouldn't have been able to
reach the domain server?


>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> Wavetables for the Terratec KOMPLEXER:
> http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
>
> --
> 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
>
>

--
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: Win7 system update hosed something in Cygwin

[David Karr]

On Fri, Aug 16, 2019 at 3:33 PM David Karr wrote:

> On Fri, Aug 16, 2019 at 2:17 PM L A Walsh wrote:
>
>> On 2019/08/15 18:28, David Karr wrote:
>> > I logged into my Win7 laptop and I saw it was having some connection
>> > problems, so I decided to reboot.
>> >
>> > After the reboot I found that Cygwin had some basic problems.  I
>> brought up
>> > a mintty window (C:\cygwin64\bin\mintty.exe -e /bin/bash --login) and
>> the
>> > prompt looked odd.  It wasn't the PS1 value that I set in my .bashrc. It
>> > also seemed to be saying that my current directory was "/", which is
>> not my
>> > homedir.
>> >
>> You might want to read the section in the cygwin user manual, especially
>> https://www.cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping
>>
>> If you don't have /etc/passwd or /etc/group, cygwin will generate
>> DOMAIN+USER entries dynamically each time you start cygwin (or per-boot)
>> if you have cygwin processes started at boot.  The /etc/passwd and group
>> files do not exist by default.
>>
>> If you want consistency -- same user names+id's with each boot and
>> MS-Win compatible names, you may want to create /etc/passwd
>> and /etc/group using mkpasswd, mkgroup and hand tuning.  It isn't
>> suggested for most users, but it may be something you want.
>>
>>
> I would most like to understand what changed to make this suddenly start
> happening.
>
> Also note the following:
>
> $ mkpasswd -u  -d
>
> :*:2993517:1049089:U-ITSERVICES\,S-1-5-21-2057499049-1289676208-1959431660-1944941:/home/:/bin/bash
>

Well, I guess I've managed to resolve this, but I would really like to
understand why I had to do what I did.  I basically ran both mkpasswd and
mkgroup, passing "-d -c"  and writing the output to the corresponding
passwd or group file, and then rebooting.  It now appears to work just as
well as it did before.

I've been running this Cygwin installation for a long time on this laptop
without any problem 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: Win7 system update hosed something in Cygwin

[David Karr]

On Fri, Aug 16, 2019 at 2:17 PM L A Walsh wrote:

> On 2019/08/15 18:28, David Karr wrote:
> > I logged into my Win7 laptop and I saw it was having some connection
> > problems, so I decided to reboot.
> >
> > After the reboot I found that Cygwin had some basic problems.  I brought
> up
> > a mintty window (C:\cygwin64\bin\mintty.exe -e /bin/bash --login) and the
> > prompt looked odd.  It wasn't the PS1 value that I set in my .bashrc. It
> > also seemed to be saying that my current directory was "/", which is not
> my
> > homedir.
> >
> You might want to read the section in the cygwin user manual, especially
> https://www.cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping
>
> If you don't have /etc/passwd or /etc/group, cygwin will generate
> DOMAIN+USER entries dynamically each time you start cygwin (or per-boot)
> if you have cygwin processes started at boot.  The /etc/passwd and group
> files do not exist by default.
>
> If you want consistency -- same user names+id's with each boot and
> MS-Win compatible names, you may want to create /etc/passwd
> and /etc/group using mkpasswd, mkgroup and hand tuning.  It isn't
> suggested for most users, but it may be something you want.
>
>
I would most like to understand what changed to make this suddenly start
happening.

Also note the following:

$ mkpasswd -u  -d
:*:2993517:1049089:U-ITSERVICES\,S-1-5-21-2057499049-1289676208-1959431660-1944941:/home/:/bin/bash

--
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: Win7 system update hosed something in Cygwin

[David Karr]

On Fri, Aug 16, 2019 at 2:20 PM Andrey Repin wrote:

> Greetings, David Karr!
>
> >> > So, before this reboot, my Cygwin home directory has always been
> >> > "/home/", which has always resided at
> "c:\cygwin64\home\".
> >> > After the reboot, my Cygwin home directory is "/", which appears to
> >> > translate to "c:\cygwin64" (from "cygpath -w /").  However, according
> to
> >> > the rules listed in /etc/profille, I SHOULD be getting home set to
> >> > "c:/Users/", although I don't want that.
> >> >
> >> > Any other ideas?
> >>
> >>  1. cygcheck -srv? (include the compressed output to your reply)
> >>
> >>  2. getent passwd? (what home directory for your id?)
> >>
>
> > The first line of this output is this (with some minor elisions):
>
>
> >
> +User(1944941):*:2993517:2993517:U-\User(1944941),S-1-5-21-2057499049-1289676208-1959431660-1944941:/:/sbin/nologin
>
> Your machine is a domain member?
>

Apparently.


> > This does seem to correspond to having a homedir of "/".
>
> Not "correspond", but it exactly is.
>

Clearly, but I still don't know what changed to make this start happening.


> > I don't know what this looked like before.
>
>
> >>  3. /etc/nsswitch.conf? (db_home?)
>
>
> --
> With best regards,
> Andrey Repin
> Friday, August 16, 2019 23:31:58
>
> Sorry for my terrible english...
>
>

--
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: More on Win7 update messing up HOME

[David Karr]

On Fri, Aug 16, 2019 at 2:01 PM Quanah Gibson-Mount 
wrote:

>
>
> --On Saturday, August 17, 2019 12:28 AM +0300 Andrey Repin
> wrote:
>
> > Greetings, David Karr!
> >
> >>> > I wish I could get my own messages on this list, so I could add more
> >>> > information to my first note.
> >>>
> >>> Just reply to your own initial message. Or better yet, subscribe.
> >>>
> >
> >> I am subscribed.  I can't reply to my own initial message because I
> never
> >> receive my own postings, I only receive notes sent by other people.
> >
> > You WROTE it. No need to receive to reply to it.
>
> As a subscriber, I receive a copy of every mail I send to the list (and I
> prefer it that way).  Seems to be the default list setting.  Perhaps David
> changed his list preferences at some point or there was a different
> default
> setting for the list at the time he subscribed?  It's pretty common for
> this to be the default behavior for a mailing list.  For one thing, it
> ensures you know that your email to the list was actually delivered.
>

I have tried to find where this flag is set, but I've never found it. I
don't see it mentioned in the mailing list info.


> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>

--
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: More on Win7 update messing up HOME

[David Karr]

On Fri, Aug 16, 2019 at 11:43 AM Lee wrote:

> On 8/16/19, David Karr wrote:
> > On Fri, Aug 16, 2019 at 10:32 AM Hans-Bernhard Bröker wrote:
> >
> >> Am 16.08.2019 um 15:28 schrieb David Karr:
> >> > On Fri, Aug 16, 2019 at 3:50 AM Andrey Repin wrote:
> >>
> >> >> Do you have %HOME% variable set in your user environment?
> >> >> Do you have %HOMEDRIVE%/%HOMEPATH% variables defined to something
> >> >> unsettling?
> >>
> >> > I checked "Environment Variables" in control panel, and I'm not
> setting
> >> > anything beginning with "HOME" in either user or system variables.
> >>
> >> That check is not really useful, though.
> >>
> >> You need to look at the actual environment constructed for a user
> >> process, at run-time.  About the easiest is to start a Windows command
> >> shell (Start->Run "cmd") and look at the output of the "set" command.
> >>
> >> In cases of looking for names starting with some prefix, like here, you
> >> can narrow down the search:
> >>
> >> set HOME
> >>
> >
> > That just results in:
> >
> > HOMEDRIVE=C:
> > HOMEPATH=\Users\
> >
> > I detailed this in another reply, but this would fit one of those checks,
> > which should result in "C:\Users\", which is my Windows home
> > directory, which does exist.  I don't want it to use this, but it's not
> > anyway.  It's resulting in "/" as my Cygwin home.
>
> Have you checked /etc/nsswitch.conf yet?
> $ cat /etc/nsswitch.conf
> # /etc/nsswitch.conf
> #
> #This file is read once by the first process in a Cygwin process tree.
> #To pick up changes, restart all Cygwin processes.  For a description
> #see
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
> #
> # Defaults:
> # passwd:   files db
> # group:files db
> # db_enum:  cache builtin
> # db_home:  /home/%U
> # db_shell: /bin/bash
> # db_gecos: 
>

This matches the state of mine, where all the lines are commented out.


> Lee
>
> --
> 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
>
>

--
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: Win7 system update hosed something in Cygwin

[David Karr]

On Fri, Aug 16, 2019 at 11:22 AM Houder wrote:

> On Fri, 16 Aug 2019 16:58:09, Houder  wrote:
> > On Fri, 16 Aug 2019 06:40:28, David Karr  wrote:
> > > On Fri, Aug 16, 2019 at 2:01 AM Houder wrote:
> > ..
> >
> > > > Please study /etc/profile where it says "here is how HOME is set" ...
> > > >
> > >
> > > Ok. This says:
> > >
> > >   #  1) From existing HOME in the Windows environment, translated to a
> > > Posix path
> > >   #  2) from /etc/passwd, if there is an entry with a non empty
> directory
> > > field
> > >   #  3) from HOMEDRIVE/HOMEPATH
> > >   #  4) / (root)
> > >
> > > I just brought up a cmd shell and entered "set" and looked at the
> result.
> > >
> > > 1. I don't have a "HOME" variable setting.
> > > 2. /etc/passwd doesn't exist in Cygwin.
> > > 3. I DO have both HOMEDRIVE and HOMEPATH set, and that points to my
> Windows
> > > home directory, which DOES exist.
> > > 4. This is what I am getting.
> >
> > Perhaps comment in file is not complete? (is getent perhaps used?)
>
> Execute from a command prompt:
>
> \bin\env
>
> and observe that HOME is added to the environment by the cygwin1.dll ...
> (at the end of the listing/environment array)
>

Yes, it adds "HOME=/".


> Next, study
>
>  - https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping
>  - https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
>
> You should find the answer here; somewhere (/etc/nsswitch.conf?), you
> define
> HOME (db_home:?) ... that is why HOME is known to the cygwin1.dll.
>

All the lines in nsswitch.conf are commented out, so I assume they're not
active.


> Henri
>
> > > So, before this reboot, my Cygwin home directory has always been
> > > "/home/", which has always resided at
> "c:\cygwin64\home\".
> > > After the reboot, my Cygwin home directory is "/", which appears to
> > > translate to "c:\cygwin64" (from "cygpath -w /").  However, according
> to
> > > the rules listed in /etc/profille, I SHOULD be getting home set to
> > > "c:/Users/", although I don't want that.
> > >
> > > Any other ideas?
> >
> >  1. cygcheck -srv? (include the compressed output to your reply)
> >
> >  2. getent passwd? (what home directory for your id?)
> >
> >  3. /etc/nsswitch.conf? (db_home?)
> >
> > Henri
> >
> >
> > --
> > 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
> >
>
>
> --
> 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
>
>

--
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: Win7 system update hosed something in Cygwin

[David Karr]

On Fri, Aug 16, 2019 at 7:58 AM Houder wrote:

> On Fri, 16 Aug 2019 06:40:28, David Karr  wrote:
> > On Fri, Aug 16, 2019 at 2:01 AM Houder wrote:
> ..
>
> > > Please study /etc/profile where it says "here is how HOME is set" ...
> > >
> >
> > Ok. This says:
> >
> >   #  1) From existing HOME in the Windows environment, translated to a
> > Posix path
> >   #  2) from /etc/passwd, if there is an entry with a non empty directory
> > field
> >   #  3) from HOMEDRIVE/HOMEPATH
> >   #  4) / (root)
> >
> > I just brought up a cmd shell and entered "set" and looked at the result.
> >
> > 1. I don't have a "HOME" variable setting.
> > 2. /etc/passwd doesn't exist in Cygwin.
> > 3. I DO have both HOMEDRIVE and HOMEPATH set, and that points to my
> Windows
> > home directory, which DOES exist.
> > 4. This is what I am getting.
>
> Perhaps comment in file is not complete? (is getent perhaps used?)
>
> > So, before this reboot, my Cygwin home directory has always been
> > "/home/", which has always resided at "c:\cygwin64\home\".
> > After the reboot, my Cygwin home directory is "/", which appears to
> > translate to "c:\cygwin64" (from "cygpath -w /").  However, according to
> > the rules listed in /etc/profille, I SHOULD be getting home set to
> > "c:/Users/", although I don't want that.
> >
> > Any other ideas?
>
>  1. cygcheck -srv? (include the compressed output to your reply)
>
>  2. getent passwd? (what home directory for your id?)
>

The first line of this output is this (with some minor elisions):


+User(1944941):*:2993517:2993517:U-\User(1944941),S-1-5-21-2057499049-1289676208-1959431660-1944941:/:/sbin/nologin


This does seem to correspond to having a homedir of "/".

I don't know what this looked like before.


>  3. /etc/nsswitch.conf? (db_home?)
>
> Henri
>
>
> --
> 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
>
>

--
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: More on Win7 update messing up HOME

[David Karr]

On Fri, Aug 16, 2019 at 10:32 AM Hans-Bernhard Bröker wrote:

> Am 16.08.2019 um 15:28 schrieb David Karr:
> > On Fri, Aug 16, 2019 at 3:50 AM Andrey Repin wrote:
>
> >> Do you have %HOME% variable set in your user environment?
> >> Do you have %HOMEDRIVE%/%HOMEPATH% variables defined to something
> >> unsettling?
>
> > I checked "Environment Variables" in control panel, and I'm not setting
> > anything beginning with "HOME" in either user or system variables.
>
> That check is not really useful, though.
>
> You need to look at the actual environment constructed for a user
> process, at run-time.  About the easiest is to start a Windows command
> shell (Start->Run "cmd") and look at the output of the "set" command.
>
> In cases of looking for names starting with some prefix, like here, you
> can narrow down the search:
>
> set HOME
>

That just results in:

HOMEDRIVE=C:
HOMEPATH=\Users\

I detailed this in another reply, but this would fit one of those checks,
which should result in "C:\Users\", which is my Windows home
directory, which does exist.  I don't want it to use this, but it's not
anyway.  It's resulting in "/" as my Cygwin home.


> --
> 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
>
>

--
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: Win7 system update hosed something in Cygwin

[David Karr]

On Fri, Aug 16, 2019 at 2:01 AM Houder wrote:

> On Thu, 15 Aug 2019 18:28:09, David Karr  wrote:
> > I logged into my Win7 laptop and I saw it was having some connection
> > problems, so I decided to reboot.
> >
> > After the reboot I found that Cygwin had some basic problems.  I brought
> up
> > a mintty window (C:\cygwin64\bin\mintty.exe -e /bin/bash --login) and the
> > prompt looked odd.  It wasn't the PS1 value that I set in my .bashrc. It
> > also seemed to be saying that my current directory was "/", which is not
> my
> > homedir.
>
> Re. your subject title: not likely.
>

Cygwin was working fine.  I rebooted.  Cygwin broken.


> Please study /etc/profile where it says "here is how HOME is set" ...
>

Ok. This says:

  #  1) From existing HOME in the Windows environment, translated to a
Posix path
  #  2) from /etc/passwd, if there is an entry with a non empty directory
field
  #  3) from HOMEDRIVE/HOMEPATH
  #  4) / (root)

I just brought up a cmd shell and entered "set" and looked at the result.

1. I don't have a "HOME" variable setting.
2. /etc/passwd doesn't exist in Cygwin.
3. I DO have both HOMEDRIVE and HOMEPATH set, and that points to my Windows
home directory, which DOES exist.
4. This is what I am getting.

So, before this reboot, my Cygwin home directory has always been
"/home/", which has always resided at "c:\cygwin64\home\".
After the reboot, my Cygwin home directory is "/", which appears to
translate to "c:\cygwin64" (from "cygpath -w /").  However, according to
the rules listed in /etc/profille, I SHOULD be getting home set to
"c:/Users/", although I don't want that.

Any other ideas?


> Henri
>
> > I tried to cat out /etc/passwd, but there was no "passwd" (or "groups")
> in
> > /etc . I looked at the output of "env", and it does say that HOME is "/".
> >
> > When I saw this behavior, I tried rebooting again just in case, but it
> > didn't change.  I guess I'm going to try running the cygwin installer to
> > see if it will repair itself. I have no idea whether it would do 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
>
>

--
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: More on Win7 update messing up HOME

[David Karr]

On Fri, Aug 16, 2019 at 3:50 AM Andrey Repin wrote:

> Greetings, David Karr!
>
> > I wish I could get my own messages on this list, so I could add more
> > information to my first note.
>
> Just reply to your own initial message. Or better yet, subscribe.
>

I am subscribed.  I can't reply to my own initial message because I never
receive my own postings, I only receive notes sent by other people.


> > Running the installer again made no difference.  It still thinks my HOME
> is
> > "/".
>
> Do you have %HOME% variable set in your user environment?
> Do you have %HOMEDRIVE%/%HOMEPATH% variables defined to something
> unsettling?
>

I checked "Environment Variables" in control panel, and I'm not setting
anything beginning with "HOME" in either user or system variables.


> > I don't know what environment variables are set or inspected by cygwin.
> I
> > see that the "USERNAME" variable seems to have my expected value.
>
> > I tried running "mkpasswd -d" and grepping for my userid, and it was
> there
> > (along with many others).
>
> > I can "fix" the environment in the mintty shell by setting HOME to
> > "/home/" and then sourcing my .bashrc and .bash_profile. That
> > doesn't help my Emacs desktop shortcut, which uses "run2".
>
> > I noticed that when I do an "ls -lt" in my homedir, instead of the owner
> > and group of files being my simple uid, it's something like
> > "+User(1944941)" and "2993517" (group and user, respectively, I
> > believe).
>
> Please remove any /etc/{group,passwd} files and try again.
>

I have neither of those files.  That's what I'm saying.

--
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

More on Win7 update messing up HOME

[David Karr]

I wish I could get my own messages on this list, so I could add more
information to my first note.

Running the installer again made no difference.  It still thinks my HOME is
"/".

I don't know what environment variables are set or inspected by cygwin.  I
see that the "USERNAME" variable seems to have my expected value.

I tried running "mkpasswd -d" and grepping for my userid, and it was there
(along with many others).

I can "fix" the environment in the mintty shell by setting HOME to
"/home/" and then sourcing my .bashrc and .bash_profile. That
doesn't help my Emacs desktop shortcut, which uses "run2".

I noticed that when I do an "ls -lt" in my homedir, instead of the owner
and group of files being my simple uid, it's something like
"+User(1944941)" and "2993517" (group and user, respectively, I
believe).

--
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

Win7 system update hosed something in Cygwin

[David Karr]

I logged into my Win7 laptop and I saw it was having some connection
problems, so I decided to reboot.

After the reboot I found that Cygwin had some basic problems.  I brought up
a mintty window (C:\cygwin64\bin\mintty.exe -e /bin/bash --login) and the
prompt looked odd.  It wasn't the PS1 value that I set in my .bashrc. It
also seemed to be saying that my current directory was "/", which is not my
homedir.

I tried to cat out /etc/passwd, but there was no "passwd" (or "groups") in
/etc . I looked at the output of "env", and it does say that HOME is "/".

When I saw this behavior, I tried rebooting again just in case, but it
didn't change.  I guess I'm going to try running the cygwin installer to
see if it will repair itself. I have no idea whether it would do 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: Piping input from subprocess loses track of temp file

[David Karr]

On Sat, Jul 27, 2019 at 8:40 AM Ken Brown wrote:

> On 7/19/2019 2:27 PM, David Karr wrote:
> > I believe the relevant part of my cygwin version info is
> "3.0.7(0.338/5/3)"
> > (from uname -a output).
> >
> > I'm working on a script where one step executes a process where the input
> > is taking from a subprocess, like this:
> >
> >  someprocess <(cat $outfile | sed -e "s/${property}[
> > ]*=.*$/${property}=${newValue}/")  ...
> >
> > When I run this, I see:
> >
> >  error: error reading /dev/fd/62: The system cannot find the path
> > specified.
>
> I just ran into a possibly similar problem:
>
>https://cygwin.com/ml/cygwin/2019-07/msg00230.html,
>
> although in my case I could only reproduce it under X11.  Are you running
> under
> X11 when you see your problem?  And can you boil it down to a simple test
> case
> or, barring that, send your script and reproduction instructions?
>
> Ken
>

Well, what's curious is that I thought I was running under X11, but now I
see that I'm not running the server.

What's even stranger is that this isn't happening anymore, or at least it's
not happening today.  I guess that means there's some sort of race
condition in play here, which is really annoying.

I'm even running the exact same command line that I was running before
(that is, passing the same parameters to the script that calls the process
that had this 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

Piping input from subprocess loses track of temp file

[David Karr]

I believe the relevant part of my cygwin version info is "3.0.7(0.338/5/3)"
(from uname -a output).

I'm working on a script where one step executes a process where the input
is taking from a subprocess, like this:

someprocess <(cat $outfile | sed -e "s/${property}[
]*=.*$/${property}=${newValue}/")  ...

When I run this, I see:

error: error reading /dev/fd/62: The system cannot find the path
specified.

I tried running the exact same command line and script in Ubuntu 16.04, and
it works fine.

--
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?

[David Karr]

On Fri, Jul 12, 2019 at 8:20 AM Brian Inglis wrote:
>
> On 2019-07-11 15:20, David Karr wrote:
> > On Thu, Jul 11, 2019 at 12:56 PM David Karr wrote:
> > On Wed, Jul 10, 2019 at 4:04 PM Brian Inglis wrote:
> >     On 2019-07-10 16:15, David Karr wrote:
> > > On Wed, Jul 10, 2019 at 10:20 AM Brian Inglis wrote:
> >     > On 2019-07-10 10:55, David Karr wrote:
> > > > I've checked the user guide and the FAQ, and I can't find 
> > any
> > information
> > > > about how to start cron and verify that it's working.  I 
> > found
> > other blog
> > > > posts on other sites, but some of them are old.
> > >
> > > Did you run service setup script /bin/cron-config to set up 
> > the
> > service?
> > > When I ran that now, it says "Cron is already installed as a 
> > service under
> > > account ...", so I assume that means that I did.
> > > > I had installed cron, and I thought it was working, but now 
> > I
> > think that it
> > > > is not.  If I edit "~/crontab" and then run "crontab -l", it
> > lists the
> > > > changes I've made to jobs, so at least that is working.  The
> > real job I
> > > > have didn't appear to be doing what it was supposed to be 
> > doing,
> > so I added
> > > > a new trivial job that just appends output from "date" to a 
> > file
> > in my
> > > > homedir, and after the scheduled time of the job, the file 
> > was
> > not created.
> > >
> > > Messages from cron and other active services should be 
> > visible in
> > the Windows
> > > application event log if you have not set up a syslog service.
> > > I went through it, but I didn't see any indications of issues with
> > cron.  I'm
> > > not sure what to look for, or where in the event log interface.
> > > > This is the additional job I added:
> > > >
> > > > 40,42,44 * * * * date >> /home//date.txt
> > > >
> > > > I did find a "/var/log/cron.log", but it is empty, and the
> > modtime is from
> > > > a few months ago.
> > > >
> > > > One blog post I found talks about running "cygrunsrv -I 
> > cron -p
> > > > /usr/sbin/cron -a -D". I just did this, and it reports "The
> > specified
> > > > service already exists."
> > > >
> > > > This is my uname -a output:
> > > >
> > > > CYGWIN_NT-6.1 ... 3.0.3(0.338/5/3) 2019-03-09 19:12 
> > x86_64 Cygwi
> > > For a more Unix like and self contained Cygwin approach, 
> > install
> > syslog-ng, run
> > > service setup scripts /bin/cygserver-config 
> > /bin/syslog-ng-config
> > > /bin/cron-config, add service dependencies to start up in that
> > order, and you
> > > should see cron messages in /var/log/syslog if you run 
> > elevated:
> > you can also
> > > run chmod elevated to make /var/log/syslog world readable, or
> > setfacl to add
> > > user or group read ACLs.
> > > How do I add service dependencies to start up in a particular 
> > order?
> > In an elevated cmd or bash shell:
> > elevated > OR # sc config syslog-ng depend= cygserver
> > elevated > OR # sc config cron depend= syslog-ng/cygserver
> > N.B. the "=" is part of each keyword; multiple service dependencies 
> > are
> > separated by "/".
> > 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.
> > After doing all of this, I still can't get cron jobs to work, and I can't 
> > get
> > any info on why.
> > This is the current output from "crontab -l":
> > 0   0,12* 

Re: How to start and verify cron?

[David Karr]

On Thu, Jul 11, 2019 at 12: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.
>
> On Wed, Jul 10, 2019 at 4:04 PM Brian Inglis <
> brian.ing...@systematicsw.ab.ca> wrote:
>
>> On 2019-07-10 16:15, David Karr wrote:
>> > On Wed, Jul 10, 2019 at 10:20 AM Brian Inglis wrote:
>> > On 2019-07-10 10:55, David Karr wrote:
>> > > I've checked the user guide and the FAQ, and I can't find any
>> information
>> > > about how to start cron and verify that it's working.  I found
>> other blog
>> > > posts on other sites, but some of them are old.
>> >
>> > Did you run service setup script /bin/cron-config to set up the
>> service?
>> > When I ran that now, it says "Cron is already installed as a service
>> under
>> > account ...", so I assume that means that I did.
>> > > I had installed cron, and I thought it was working, but now I
>> think that it
>> > > is not.  If I edit "~/crontab" and then run "crontab -l", it
>> lists the
>> > > changes I've made to jobs, so at least that is working.  The real
>> job I
>> > > have didn't appear to be doing what it was supposed to be doing,
>> so I added
>> > > a new trivial job that just appends output from "date" to a file
>> in my
>> > > homedir, and after the scheduled time of the job, the file was
>> not created.
>> >
>> > Messages from cron and other active services should be visible in
>> the Windows
>> > application event log if you have not set up a syslog service.
>> > I went through it, but I didn't see any indications of issues with
>> cron.  I'm
>> > not sure what to look for, or where in the event log interface.
>> > > This is the additional job I added:
>> > >
>> > > 40,42,44 * * * * date >> /home//date.txt
>> > >
>> > > I did find a "/var/log/cron.log", but it is empty, and the
>> modtime is from
>> > > a few months ago.
>> > >
>> > > One blog post I found talks about running "cygrunsrv -I cron -p
>> > > /usr/sbin/cron -a -D". I just did this, and it reports "The
>> specified
>> > > service already exists."
>> > >
>> > > This is my uname -a output:
>> > >
>> > > CYGWIN_NT-6.1 ... 3.0.3(0.338/5/3) 2019-03-09 19:12 x86_64
>> Cygwi
>> > For a more Unix like and self contained Cygwin approach, install
>> syslog-ng, run
>> > service setup scripts /bin/cygserver-config /bin/syslog-ng-config
>> > /bin/cron-config, add service dependencies to start up in that
>> order, and you
>> > should see cron messages in /var/log/syslog if you run elevated:
>> you can also
>> > run chmod elevated to make /var/log/syslog world readable, or
>> setfacl to add
>> > user or group read ACLs.
>> > How do I add service dependencies to start up in a particular order?
>>
>> In an elevated cmd or bash shell:
>> elevated > OR # sc config syslog-ng depend= cygserver
>> elevated > OR # sc config cron depend= syslog-ng/cygserver
>> N.B. the "=" is part of each keyword; multiple service dependencies are
>> separated by "/".
>>
>
After doing all of this, I still can't get cron jobs to work, and I can't
get any info on why.

This is the current output from "crontab -l":


# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (crontab installed on Thu Jul 11 14:13:09 2019)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp
$)
0   0,12*   *   *   find /tmp/.logcache/ -type f -mtime
+6 -exec rm {} \;
14,15,16,17 *   *   *   *date >>
/home/dk068x/date.txt


I've tried editing that last one and changing the minutes to include
upcoming minutes, and then after those minutes, I check the results, and
there are none.  Nothing in cron.log or syslog-ng.log.

--
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?

[David Karr]

On Thu, Jul 11, 2019 at 1:23 PM Vince Rice 
wrote:

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

I typically try to avoid top-posting, but I'm pretty sure I won't be able
to do anything about the mailer 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: How to start and verify cron?

[David Karr]

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.

On Wed, Jul 10, 2019 at 4:04 PM Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

> On 2019-07-10 16:15, David Karr wrote:
> > On Wed, Jul 10, 2019 at 10:20 AM Brian Inglis wrote:
> > On 2019-07-10 10:55, David Karr wrote:
> > > I've checked the user guide and the FAQ, and I can't find any
> information
> > > about how to start cron and verify that it's working.  I found
> other blog
> > > posts on other sites, but some of them are old.
> >
> > Did you run service setup script /bin/cron-config to set up the
> service?
> > When I ran that now, it says "Cron is already installed as a service
> under
> > account ...", so I assume that means that I did.
> > > I had installed cron, and I thought it was working, but now I
> think that it
> > > is not.  If I edit "~/crontab" and then run "crontab -l", it lists
> the
> > > changes I've made to jobs, so at least that is working.  The real
> job I
> > > have didn't appear to be doing what it was supposed to be doing,
> so I added
> > > a new trivial job that just appends output from "date" to a file
> in my
> > > homedir, and after the scheduled time of the job, the file was not
> created.
> >
> > Messages from cron and other active services should be visible in
> the Windows
> > application event log if you have not set up a syslog service.
> > I went through it, but I didn't see any indications of issues with
> cron.  I'm
> > not sure what to look for, or where in the event log interface.
> > > This is the additional job I added:
> > >
> > > 40,42,44 * * * * date >> /home//date.txt
> > >
> > > I did find a "/var/log/cron.log", but it is empty, and the modtime
> is from
> > > a few months ago.
> > >
> > > One blog post I found talks about running "cygrunsrv -I cron -p
> > > /usr/sbin/cron -a -D". I just did this, and it reports "The
> specified
> > > service already exists."
> > >
> > > This is my uname -a output:
> > >
> > > CYGWIN_NT-6.1 ... 3.0.3(0.338/5/3) 2019-03-09 19:12 x86_64
> Cygwi
> > For a more Unix like and self contained Cygwin approach, install
> syslog-ng, run
> > service setup scripts /bin/cygserver-config /bin/syslog-ng-config
> > /bin/cron-config, add service dependencies to start up in that
> order, and you
> > should see cron messages in /var/log/syslog if you run elevated: you
> can also
> > run chmod elevated to make /var/log/syslog world readable, or
> setfacl to add
> > user or group read ACLs.
> > How do I add service dependencies to start up in a particular order?
>
> In an elevated cmd or bash shell:
> elevated > OR # sc config syslog-ng depend= cygserver
> elevated > OR # sc config cron depend= syslog-ng/cygserver
> N.B. the "=" is part of each keyword; multiple service dependencies are
> separated by "/".
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
>
> --
> 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
>
>

--
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?

[David Karr]

On Wed, Jul 10, 2019 at 10:20 AM Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

> On 2019-07-10 10:55, David Karr wrote:
> > I've checked the user guide and the FAQ, and I can't find any information
> > about how to start cron and verify that it's working.  I found other blog
> > posts on other sites, but some of them are old.
>
> Did you run service setup script /bin/cron-config to set up the service?
>

When I ran that now, it says "Cron is already installed as a service under
account ...", so I assume that means that I did.


> > I had installed cron, and I thought it was working, but now I think that
> it
> > is not.  If I edit "~/crontab" and then run "crontab -l", it lists the
> > changes I've made to jobs, so at least that is working.  The real job I
> > have didn't appear to be doing what it was supposed to be doing, so I
> added
> > a new trivial job that just appends output from "date" to a file in my
> > homedir, and after the scheduled time of the job, the file was not
> created.
>
> Messages from cron and other active services should be visible in the
> Windows
> application event log if you have not set up a syslog service.
>

I went through it, but I didn't see any indications of issues with cron.
I'm not sure what to look for, or where in the event log interface.


> > This is the additional job I added:
> >
> > 40,42,44 * * * * date >> /home//date.txt
> >
> > I did find a "/var/log/cron.log", but it is empty, and the modtime is
> from
> > a few months ago.
> >
> > One blog post I found talks about running "cygrunsrv -I cron -p
> > /usr/sbin/cron -a -D". I just did this, and it reports "The specified
> > service already exists."
> >
> > This is my uname -a output:
> >
> > CYGWIN_NT-6.1 ... 3.0.3(0.338/5/3) 2019-03-09 19:12 x86_64 Cygwi
> For a more Unix like and self contained Cygwin approach, install
> syslog-ng, run
> service setup scripts /bin/cygserver-config /bin/syslog-ng-config
> /bin/cron-config, add service dependencies to start up in that order, and
> you
> should see cron messages in /var/log/syslog if you run elevated: you can
> also
> run chmod elevated to make /var/log/syslog world readable, or setfacl to
> add
> user or group read ACLs.
>

How do I add service dependencies to start up in a particular order?


> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
>
> --
> 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
>
>

--
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

How to start and verify cron?

[David Karr]

I've checked the user guide and the FAQ, and I can't find any information
about how to start cron and verify that it's working.  I found other blog
posts on other sites, but some of them are old.

I had installed cron, and I thought it was working, but now I think that it
is not.  If I edit "~/crontab" and then run "crontab -l", it lists the
changes I've made to jobs, so at least that is working.  The real job I
have didn't appear to be doing what it was supposed to be doing, so I added
a new trivial job that just appends output from "date" to a file in my
homedir, and after the scheduled time of the job, the file was not created.

This is the additional job I added:

40,42,44 * * * * date >> /home//date.txt

I did find a "/var/log/cron.log", but it is empty, and the modtime is from
a few months ago.

One blog post I found talks about running "cygrunsrv -I cron -p
/usr/sbin/cron -a -D". I just did this, and it reports "The specified
service already exists."

This is my uname -a output:

CYGWIN_NT-6.1 ... 3.0.3(0.338/5/3) 2019-03-09 19:12 x86_64 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

Emacs seems to be dragging down other processes?

[David Karr]

I've recently been having general performance problems on my Win7 laptop,
mostly realized by very slow switches to workspaces (Dexpot).  I've been
watching processes using high cpu, and I'm trying to watch for processes
with high i/o, but I'm not as certain how to find those (I'm using Process
Explorer).  I finally discovered that when I kill my Cygwin Emacs process,
it clears up immediately.  When I restart Emacs, it's fine for a while, but
then it eventually slows down again, and then killing it clears it up
again. I've found other processes that are suspicious in terms of
performance, but none of those had as much of an impact as the Emacs
process.  Curiously, when I'm actually USING Emacs, I don't notice any
particular slowdown.

My Emacs process mostly just sits, without very much foreground activity.
I sometimes have pretty large file buffers, in the megabyte range.

I vaguely remember recently seeing some messages go by on the list about
perf problems with Cygwin Emacs.  I didn't read them at the time, as I
wasn't having an issue.

Cygwin 3.0.1(0.338/5/3); Emacs 26.1.

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

On Wed, Dec 5, 2018 at 4:20 PM Andrey Repin  wrote:

> Greetings, David Karr!
>
> > Sigh. What a mess. I can't get this to work.  It was easy enough when a
> > single script has to execute "kubectl", having "winpty" prefix that call,
> > but I'm trying to write a script that calls that other script, and even
> in
> > a pipeline.
>
> > If I have "winpty" prefix the call to the script that calls "kubectl", it
> > says:
>
> > winpty: error: cannot start '...': Not found in PATH
>
> Either
> kubectl(){ .../winpty ...\\kubectl }; readonly -f kubectl
>
> > When I changed it so it references the absolute path, it then says "%1 is
> > not a valid Win32 application. (error 0xc1)".  So, this makes it clear
> that
> > winpty can only directly execute Windows applications, which makes sense.
>
> > So how can I call a Windows application from more than just the top-level
> > script?
>
> or write a Cygwin wrapper for kubectl and place it where it is usually
> located
> on *NIX system.
> Do NOT add kubectl or winpty to Cygwin $PATH, since both are not Cygwin
> apps
> and their presence only confuses you.
>
> Wrapper would probably be more universal.
>

I don't see how any of this can help.  It appears that I can only "winpty"
a process if it's "at most one level deep", if that makes any sense.  I
tried writing a "kubectl" script and putting it in my path before the
Windows kubectl, and having the script execute that, and prefix the call
with "winpty".  It doesn't work if the call to "kubectl" is "deeper" in the
script chain.

What's even worse is that I didn't need "winpty" for all of the kubectl
subcommands, only "exec".  By now adding "winpty" as a prefix for all
kubectl subcommands, it messes up the output of things that just emit text.
I now have " [0K" ending all my output lines.


>
> --
> With best regards,
> Andrey Repin
> Thursday, December 6, 2018 3:09:46
>
> Sorry for my terrible english...
>
>

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

On Wed, Dec 5, 2018 at 11:44 AM cyg Simple  wrote:

> On 12/5/2018 1:33 PM, David Karr wrote:
> > On Wed, Dec 5, 2018 at 9:43 AM cyg Simple  wrote:
> >
> >>
> >> Your query got me interested in looking and I believe that winpty needs
> >> to be at the front of all the commands so that it can communicate with
> >> mintty properly.  To overcome the need to remember you could add an
> >> alias to execute the command; `alias FOO="winpty FOO"'.
> >>
> >
> > Sigh. What a mess. I can't get this to work.  It was easy enough when a
> > single script has to execute "kubectl", having "winpty" prefix that call,
> > but I'm trying to write a script that calls that other script, and even
> in
> > a pipeline.
> >
> > If I have "winpty" prefix the call to the script that calls "kubectl", it
> > says:
> >
> >  winpty: error: cannot start '...': Not found in PATH
> >
> > When I changed it so it references the absolute path, it then says "%1 is
> > not a valid Win32 application. (error 0xc1)".  So, this makes it clear
> that
> > winpty can only directly execute Windows applications, which makes sense.
> >
> > So how can I call a Windows application from more than just the top-level
> > script?
> >
>
> What does cygcheck say about your winpty?  You are using the Cygwin
> compiled version, correct?
>

By "say", I assume you mean the output from running "cygcheck winpty"?
This is what I get:

Found:
C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.exe
C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.exe
  C:\cygwin64\bin\cygwin1.dll
C:\Windows\system32\KERNEL32.dll
  C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
  C:\Windows\system32\ntdll.dll
  C:\Windows\system32\KERNELBASE.dll
  C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
  C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.dll
C:\Windows\system32\ADVAPI32.dll
  C:\Windows\system32\msvcrt.dll
C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll
C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll
  C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll
  C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll
  C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll
  C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll
  C:\Windows\system32\RPCRT4.dll
C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll
C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll
C:\Windows\system32\USER32.dll
  C:\Windows\system32\GDI32.dll
C:\Windows\system32\LPK.dll
  C:\Windows\system32\USP10.dll


>
> --
> cyg Simple
>
> --
> 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
>
>

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

On Wed, Dec 5, 2018 at 9:43 AM cyg Simple  wrote:

> On 12/5/2018 10:11 AM, David Karr wrote:
> > On Tue, Dec 4, 2018 at 12:52 PM Marco Atzeri 
> wrote:
> >
> >> Am 04.12.2018 um 21:41 schrieb David Karr:
> >>> "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)"
> >>>
> >>> I installed a version of "kubectl" for windows, and I use it
> extensively
> >> in
> >>> Cygwin bash for scripting command-line automation. In general, this
> works
> >>> perfectly fine. I even use the same scripting in a Linux VM.
> >>>
> >>> I'm seeing an issue with one script that works fine in the Linux VM,
> but
> >>> not in Cygwin.
> >>>
> >>> The command line is approximately this:
> >>>
> >>>kubectl exec pod -c container -i -t -- grep "string"
> >> stuff.properties
> >>> 2>&1 | sed -e 's/^propname=//'
> >>>
> >>> In Linux, this works perfectly fine.  In Cygwin, it says "stdout is
> not a
> >>> tty".
> >>>
> >>> I haven't updated my local Cygwin installation for quite a while. I'd
> >>> prefer not to, unless there is a strong chance this kind of thing would
> >> be
> >>> fixed.
> >>>
> >>
> >> as kubectl is not a Cygwin program, it is not aware of cygwin pty.
> >> You can try to use winpty to overcome the problem.
> >>
> >> https://github.com/rprichard/winpty
> >>
> >>
> >>
> > It turns out that not only had I already used winpty for similar
> > functionality, it was actually in place in the pipeline when I tried to
> do
> > this.  When I turned on debugging output, it showed that kubectl was
> > already being wrapped by winpty when it reported "stdout is not a tty".
> > However, this was one shell script wrapper deeper than I usually call it.
> > Does it matter whether winpty is called from the shell script I'm
> calling,
> > or from the script being called by the script I'm calling?
>
> Your query got me interested in looking and I believe that winpty needs
> to be at the front of all the commands so that it can communicate with
> mintty properly.  To overcome the need to remember you could add an
> alias to execute the command; `alias FOO="winpty FOO"'.
>

Sigh. What a mess. I can't get this to work.  It was easy enough when a
single script has to execute "kubectl", having "winpty" prefix that call,
but I'm trying to write a script that calls that other script, and even in
a pipeline.

If I have "winpty" prefix the call to the script that calls "kubectl", it
says:

winpty: error: cannot start '...': Not found in PATH

When I changed it so it references the absolute path, it then says "%1 is
not a valid Win32 application. (error 0xc1)".  So, this makes it clear that
winpty can only directly execute Windows applications, which makes sense.

So how can I call a Windows application from more than just the top-level
script?

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

On Tue, Dec 4, 2018 at 12:52 PM Marco Atzeri  wrote:

> Am 04.12.2018 um 21:41 schrieb David Karr:
> > "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)"
> >
> > I installed a version of "kubectl" for windows, and I use it extensively
> in
> > Cygwin bash for scripting command-line automation. In general, this works
> > perfectly fine. I even use the same scripting in a Linux VM.
> >
> > I'm seeing an issue with one script that works fine in the Linux VM, but
> > not in Cygwin.
> >
> > The command line is approximately this:
> >
> >   kubectl exec pod -c container -i -t -- grep "string"
> stuff.properties
> > 2>&1 | sed -e 's/^propname=//'
> >
> > In Linux, this works perfectly fine.  In Cygwin, it says "stdout is not a
> > tty".
> >
> > I haven't updated my local Cygwin installation for quite a while. I'd
> > prefer not to, unless there is a strong chance this kind of thing would
> be
> > fixed.
> >
>
> as kubectl is not a Cygwin program, it is not aware of cygwin pty.
> You can try to use winpty to overcome the problem.
>
> https://github.com/rprichard/winpty
>
>
>
It turns out that not only had I already used winpty for similar
functionality, it was actually in place in the pipeline when I tried to do
this.  When I turned on debugging output, it showed that kubectl was
already being wrapped by winpty when it reported "stdout is not a tty".
However, this was one shell script wrapper deeper than I usually call it.
Does it matter whether winpty is called from the shell script I'm calling,
or from the script being called by the script I'm calling?

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

On Tue, Dec 4, 2018 at 12:52 PM Marco Atzeri  wrote:

> Am 04.12.2018 um 21:41 schrieb David Karr:
> > "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)"
> >
> > I installed a version of "kubectl" for windows, and I use it extensively
> in
> > Cygwin bash for scripting command-line automation. In general, this works
> > perfectly fine. I even use the same scripting in a Linux VM.
> >
> > I'm seeing an issue with one script that works fine in the Linux VM, but
> > not in Cygwin.
> >
> > The command line is approximately this:
> >
> >   kubectl exec pod -c container -i -t -- grep "string"
> stuff.properties
> > 2>&1 | sed -e 's/^propname=//'
> >
> > In Linux, this works perfectly fine.  In Cygwin, it says "stdout is not a
> > tty".
> >
> > I haven't updated my local Cygwin installation for quite a while. I'd
> > prefer not to, unless there is a strong chance this kind of thing would
> be
> > fixed.
> >
>
> as kubectl is not a Cygwin program, it is not aware of cygwin pty.
> You can try to use winpty to overcome the problem.
>
> https://github.com/rprichard/winpty
>
>
>
>
Oh.  Senior moment.  I actually already knew that. In fact, I even have
another scripting element calling "exec" already using winpty.  Thanks for
the reminder.

--
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

Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

"CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)"

I installed a version of "kubectl" for windows, and I use it extensively in
Cygwin bash for scripting command-line automation. In general, this works
perfectly fine. I even use the same scripting in a Linux VM.

I'm seeing an issue with one script that works fine in the Linux VM, but
not in Cygwin.

The command line is approximately this:

 kubectl exec pod -c container -i -t -- grep "string" stuff.properties
2>&1 | sed -e 's/^propname=//'

In Linux, this works perfectly fine.  In Cygwin, it says "stdout is not a
tty".

I haven't updated my local Cygwin installation for quite a while. I'd
prefer not to, unless there is a strong chance this kind of thing would be
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: Any reason Cygwin might prevent kubectl exec from showing shell prompt?

[David Karr]

On Tue, Jul 31, 2018 at 1:34 PM, David Karr 
wrote:

> And I note that I tried running the same script from a Linux VM on my
> laptop, and it doesn't have this symptom, so it does seem to have something
> to do with Cygwin or Windows.
>
> On Tue, Jul 31, 2018 at 1:15 PM, David Karr 
> wrote:
>
>> On Tue, Jul 31, 2018 at 9:27 AM, Thomas Wolff  wrote:
>>
>>> Am 31.07.2018 um 18:15 schrieb David Karr:
>>>
>>>> I really have no idea if this is a Cygwin problem, just trying to
>>>> eliminate variables.
>>>>
>>>> I believe my Cygwin version is "2.9.0(0.318/5/3)" (from the uname
>>>> string).
>>>>
>>>>  From a mintty window, I use a variation of "kubectl exec" in a script
>>>> to
>>>> run a shell in a container in a pod.  It appears to run, and I can run
>>>> processes from that shell in the container, but the curious thing is
>>>> that I
>>>> never get a shell prompt from the container.  I thought I had gotten
>>>> this
>>>> to work before, in the same k8s cluster, but I'm not certain.
>>>>
>>> This may be an instance of the pty incompatibility issue of native
>>> Windows programs (which I assume kubectl to be).
>>> Try `winpty kubectl`, after installing winpty, that is.
>>> Maybe someone should put up a winpty cygwin package; maybe I should do
>>> it...
>>>
>>
>> I hope this isn't it.  This is really the only issue I have with running
>> kubectl in Cygwin.  It takes and outputs text perfectly fine.  I use pipes
>> for input and output with no issues.  When I run kubectl with winpty, it
>> changes the text encoding in ways I don't understand yet.
>>
>
Ok. It's a hack, but I guess it will work.  I execute kubectl with a shell
wrapper anyway, so now if "$1" == "exec", I prefix it with "winpty".  This
allows all the other operations to avoid that complexity, but still get a
shell prompt on exedc.


>>
>>
>>>
>>> The other curious thing I see is that if I execute "echo $PS1" in the
>>>> shell
>>>> in the container, it gives me a reasonable response ("\w \$"), but if I
>>>> instead do "env | grep PS1", it returns nothing.
>>>>
>>> You may have set PS1 in your .profile (or .bashrc) but not exported it
>>> into the environment (export PS1).
>>>
>>
>> I guess that makes sense. It appears to be irrelevant to my 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: Any reason Cygwin might prevent kubectl exec from showing shell prompt?

[David Karr]

And I note that I tried running the same script from a Linux VM on my
laptop, and it doesn't have this symptom, so it does seem to have something
to do with Cygwin or Windows.

On Tue, Jul 31, 2018 at 1:15 PM, David Karr 
wrote:

> On Tue, Jul 31, 2018 at 9:27 AM, Thomas Wolff  wrote:
>
>> Am 31.07.2018 um 18:15 schrieb David Karr:
>>
>>> I really have no idea if this is a Cygwin problem, just trying to
>>> eliminate variables.
>>>
>>> I believe my Cygwin version is "2.9.0(0.318/5/3)" (from the uname
>>> string).
>>>
>>>  From a mintty window, I use a variation of "kubectl exec" in a script to
>>> run a shell in a container in a pod.  It appears to run, and I can run
>>> processes from that shell in the container, but the curious thing is
>>> that I
>>> never get a shell prompt from the container.  I thought I had gotten this
>>> to work before, in the same k8s cluster, but I'm not certain.
>>>
>> This may be an instance of the pty incompatibility issue of native
>> Windows programs (which I assume kubectl to be).
>> Try `winpty kubectl`, after installing winpty, that is.
>> Maybe someone should put up a winpty cygwin package; maybe I should do
>> it...
>>
>
> I hope this isn't it.  This is really the only issue I have with running
> kubectl in Cygwin.  It takes and outputs text perfectly fine.  I use pipes
> for input and output with no issues.  When I run kubectl with winpty, it
> changes the text encoding in ways I don't understand yet.
>
>
>
>>
>> The other curious thing I see is that if I execute "echo $PS1" in the
>>> shell
>>> in the container, it gives me a reasonable response ("\w \$"), but if I
>>> instead do "env | grep PS1", it returns nothing.
>>>
>> You may have set PS1 in your .profile (or .bashrc) but not exported it
>> into the environment (export PS1).
>>
>
> I guess that makes sense. It appears to be irrelevant to my 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: Any reason Cygwin might prevent kubectl exec from showing shell prompt?

[David Karr]

On Tue, Jul 31, 2018 at 9:27 AM, Thomas Wolff  wrote:

> Am 31.07.2018 um 18:15 schrieb David Karr:
>
>> I really have no idea if this is a Cygwin problem, just trying to
>> eliminate variables.
>>
>> I believe my Cygwin version is "2.9.0(0.318/5/3)" (from the uname string).
>>
>>  From a mintty window, I use a variation of "kubectl exec" in a script to
>> run a shell in a container in a pod.  It appears to run, and I can run
>> processes from that shell in the container, but the curious thing is that
>> I
>> never get a shell prompt from the container.  I thought I had gotten this
>> to work before, in the same k8s cluster, but I'm not certain.
>>
> This may be an instance of the pty incompatibility issue of native Windows
> programs (which I assume kubectl to be).
> Try `winpty kubectl`, after installing winpty, that is.
> Maybe someone should put up a winpty cygwin package; maybe I should do
> it...
>

I hope this isn't it.  This is really the only issue I have with running
kubectl in Cygwin.  It takes and outputs text perfectly fine.  I use pipes
for input and output with no issues.  When I run kubectl with winpty, it
changes the text encoding in ways I don't understand yet.



>
> The other curious thing I see is that if I execute "echo $PS1" in the shell
>> in the container, it gives me a reasonable response ("\w \$"), but if I
>> instead do "env | grep PS1", it returns nothing.
>>
> You may have set PS1 in your .profile (or .bashrc) but not exported it
> into the environment (export PS1).
>

I guess that makes sense. It appears to be irrelevant to my 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

Any reason Cygwin might prevent kubectl exec from showing shell prompt?

[David Karr]

I really have no idea if this is a Cygwin problem, just trying to eliminate
variables.

I believe my Cygwin version is "2.9.0(0.318/5/3)" (from the uname string).

>From a mintty window, I use a variation of "kubectl exec" in a script to
run a shell in a container in a pod.  It appears to run, and I can run
processes from that shell in the container, but the curious thing is that I
never get a shell prompt from the container.  I thought I had gotten this
to work before, in the same k8s cluster, but I'm not certain.

The other curious thing I see is that if I execute "echo $PS1" in the shell
in the container, it gives me a reasonable response ("\w \$"), but if I
instead do "env | grep PS1", it returns nothing.

--
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

Issues with setting or not setting HOME environment variable

[David Karr]

I currently do not set the HOME environment variable.  I get the
impression you're not supposed to do that.  When I run a mintty shell,
it correctly puts me in "/home/", which is what I want.

I'm running into a problem with Eclipse egit, as I think it's looking
for the "HOME" environment variable to determine where the .gitconfig
file is. If it doesn't find "HOME" set, I have a feeling it's looking
for "HOMEDRIVE", which is set to something I can't easily control.

Is there some way I can set "HOME" to my Windows home location, but
still have Cygwin do the right thing and go to "/home/"?

--
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: Can't connect to ssh host with Emacs tramp

[David Karr]

On Fri, Jan 5, 2018 at 10:35 AM, George Prikhodko <gp1...@gmail.com> wrote:
> Hi,
>
> Have you tried to set in your ~/.emacs file ‘tramp-verbose’ variable?
> If not, then add to the file the following line:
>
> (setq tramp-verbose 6)
>
> In '*debug tramp/scp remote_host_name*' buffer you'll see all interactions
> between tramp, ssh and your remote host.

Well, that's odd.  I decided to get back to this, and now I see that
this is working perfectly fine.  The only thing I've changed is
setting this verbose variable to 6.  However, I then changed it back
to 1 and retested, and it's still working fine.

I'm confused.

> On Fri, Jan 5, 2018 at 10:37 AM, David Karr <davidmichaelk...@gmail.com>
> wrote:
>
>> On Thu, Jan 4, 2018 at 5:15 PM, Ken Brown <kbr...@cornell.edu> wrote:
>> > On 1/4/2018 5:42 PM, David Karr wrote:
>> >>
>> >> I've reviewed some of the Emacs tramp documentation, but I'm not sure
>> >> what the issue is.
>> >>
>> >> If I'm using Cygwin, I don't need the putty components for this, do I?
>> >
>> >
>> > No, I make ssh connections through Emacs tramp without putty.
>> >
>> >> When I attempt to open a text file in my homedir on a remote host,
>> >> which I can ssh to (passwordless) from the shell, it just times out.
>> >>
>> >> The *Messages* buffer shows this (fqhn is the hostname):
>> >> --
>> >> Tramp: Opening connection for fqhn using scp...
>> >> Tramp: Sending command ‘exec ssh   -o ControlMaster=auto -o
>> >> ControlPath='tramp.%C' -o ControlPersist=no -e none fqhn’
>> >> Tramp: Waiting for prompts from remote shell...
>> >> Timeout reached, see buffer ‘*tramp/scp fqhn*’ for details
>> >> Tramp: Waiting for prompts from remote shell...failed
>> >> Tramp: Opening connection for fqhn using scp...failed
>> >> ---
>> >>
>> >> There doesn't appear to be a buffer named "*tramp/scp fqhn*".
>> >
>> >
>> > Sorry, I don't know enough about tramp to diagnose this.  Maybe it would
>> > help if you would say exactly what commands you gave.  And does the
>> problem
>> > occur if you start with 'emacs -Q'?
>>
>> What "commands" am I giving?  All I'm trying to do is open a single
>> file on the remote host.
>>
>> I'm entering "//fqhn:/home//.bash_profile".
>>
>> I get different behavior using "emacs -Q".  I don't get a timeout
>> error, but I also don't think it even attempted to connect to the
>> remote box.  The editor view just opens with the given name, but it's
>> empty (it shouldn't be).  The "*Messages*" buffer doesn't indicate
>> that it ever tried to make a connection.  It also says "Use M-x
>> make-directory RET RET to create the directory and its parents".
>>
>> The other frustrating issue with my full Emacs configuration is that
>> when I enter the second forward slash, key response vastly, and I mean
>> vastly, slows down. I've gone through the tramp FAQ looking for
>> potential performance issues, but nothing has helped.
>>
>> --
>> 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
>>
>>
>
> --
> 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
>

--
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: Can't connect to ssh host with Emacs tramp

[David Karr]

On Thu, Jan 4, 2018 at 5:15 PM, Ken Brown <kbr...@cornell.edu> wrote:
> On 1/4/2018 5:42 PM, David Karr wrote:
>>
>> I've reviewed some of the Emacs tramp documentation, but I'm not sure
>> what the issue is.
>>
>> If I'm using Cygwin, I don't need the putty components for this, do I?
>
>
> No, I make ssh connections through Emacs tramp without putty.
>
>> When I attempt to open a text file in my homedir on a remote host,
>> which I can ssh to (passwordless) from the shell, it just times out.
>>
>> The *Messages* buffer shows this (fqhn is the hostname):
>> --
>> Tramp: Opening connection for fqhn using scp...
>> Tramp: Sending command ‘exec ssh   -o ControlMaster=auto -o
>> ControlPath='tramp.%C' -o ControlPersist=no -e none fqhn’
>> Tramp: Waiting for prompts from remote shell...
>> Timeout reached, see buffer ‘*tramp/scp fqhn*’ for details
>> Tramp: Waiting for prompts from remote shell...failed
>> Tramp: Opening connection for fqhn using scp...failed
>> ---
>>
>> There doesn't appear to be a buffer named "*tramp/scp fqhn*".
>
>
> Sorry, I don't know enough about tramp to diagnose this.  Maybe it would
> help if you would say exactly what commands you gave.  And does the problem
> occur if you start with 'emacs -Q'?

What "commands" am I giving?  All I'm trying to do is open a single
file on the remote host.

I'm entering "//fqhn:/home//.bash_profile".

I get different behavior using "emacs -Q".  I don't get a timeout
error, but I also don't think it even attempted to connect to the
remote box.  The editor view just opens with the given name, but it's
empty (it shouldn't be).  The "*Messages*" buffer doesn't indicate
that it ever tried to make a connection.  It also says "Use M-x
make-directory RET RET to create the directory and its parents".

The other frustrating issue with my full Emacs configuration is that
when I enter the second forward slash, key response vastly, and I mean
vastly, slows down. I've gone through the tramp FAQ looking for
potential performance issues, but nothing has helped.

--
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

Cygwin gimp can't paste image from clipboard on windows 7

[David Karr]

I recently set up a new laptop to replace an older one, and now
something that I had working before isn't working anymore.

I'm trying to copy an image to the clipboard and paste it into gimp.
The paste attempt from gimp now says that there's nothing in the
clipboard.

My "startxwin" command at startup is doing this:
"C:\cygwin64\bin\run.exe -p /usr/X11R6/bin XWin -multiwindow
-clipboard -silent-dup-error".

When I right-click on the xwin icon, it shows "Clipboard may use
PRIMARY selection" is checked.

What might I be doing wrong?

--
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

Can't connect to ssh host with Emacs tramp

[David Karr]

I've reviewed some of the Emacs tramp documentation, but I'm not sure
what the issue is.

If I'm using Cygwin, I don't need the putty components for this, do I?

When I attempt to open a text file in my homedir on a remote host,
which I can ssh to (passwordless) from the shell, it just times out.

The *Messages* buffer shows this (fqhn is the hostname):
--
Tramp: Opening connection for fqhn using scp...
Tramp: Sending command ‘exec ssh   -o ControlMaster=auto -o
ControlPath='tramp.%C' -o ControlPersist=no -e none fqhn’
Tramp: Waiting for prompts from remote shell...
Timeout reached, see buffer ‘*tramp/scp fqhn*’ for details
Tramp: Waiting for prompts from remote shell...failed
Tramp: Opening connection for fqhn using scp...failed
---

There doesn't appear to be a buffer named "*tramp/scp fqhn*".

--
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

Grep can't match characters before EOL marker without ^M

[David Karr]

My cygwin version appears to be "2.9.0(0.318/5/3)".

If I have a text file that has a line that ends with "abc", and I try
to grep for "abc$", it doesn't match.  I find that it does match "$"
and "abc^M$".

I've read some of the documentation about line endings in Cygwin.

I need to write some scripting that works on both Cygwin and Linux.
What do I need to do 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: Proper way to run emacs from desktop

[David Karr]

On Thu, Nov 2, 2017 at 9:29 AM, Jon Turney <jon.tur...@dronecode.org.uk> wrote:
> On 01/11/2017 21:57, David Karr wrote:
>>
>> On Wed, Nov 1, 2017 at 12:57 PM, Ken Brown <kbr...@cornell.edu> wrote:
>>>
>>> On 11/1/2017 1:08 PM, David Karr wrote:
>>>>
>>>> I install Cygwin every couple of years and then use it continuously
>>>> without updates between those installations.  I installed it on a new
>>>> laptop today, and I'm trying to work through issues.
>>>>
>>>> The current issue is running Emacs from the desktop.
>>>>
>>>> I had a shortcut working for a long time that does the following:
>>>> -
>>>> C:\cygwin64\bin\run2.exe --display 127.0.0.1:0.0
>>>> /usr/local/bin/emacs.xml
>>>> -
>
>
> Just '--display :0.0' is probably better, as it won't stop working when the
> Xserver is run without '-listen tcp'...

Sounds like a good idea, but I noticed that this change produces a
very odd side effect, and I've verified that going back makes it not
happen. I've tested going back and forth multiple times, with
repeatable results.

Normally, when I start emacs, the window appears in a particular
location, and with a particular height (and width, but I don't set
that).

I believe this is configured by the following lines in my .emacs file:
-
(set-frame-position (selected-frame) 0 0)
(set-frame-height (selected-frame) 60)
-

Setting the frame height to 60 results in a window that spans most of
the vertical space of my desktop.

Curiously, when I remove the "127.0.0.1" from the "display" option,
emacs starts up in the same location, but with about 2/3 of the
expected window height.  The window is easily expandable, but I'd
rather it be the height that I have configured initially.

Frankly, I find it hard to believe what I'm seeing, but I've gone back
and forth multiple times, and it's completely repeatable.  Could this
be caused by something odd in my X resources tree?

>>>> The "run2" application doesn't appear to exist.  I checked my notes,
>>>> and I can't tell whether I installed this from somewhere else the last
>>>> time I did this.
>>>
>>>
>>> Just install the run2 package.  It's still available.
>>
>>
>> Ok.  I find the search facility in setup somewhat confusing.  I
>> couldn't find it before. I found it now, and I've installed it.
>
>
> You can also search using e.g.
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=run2.exe=x86_64
>

--
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: Proper way to run emacs from desktop

[David Karr]

On Wed, Nov 1, 2017 at 12:57 PM, Ken Brown <kbr...@cornell.edu> wrote:
> On 11/1/2017 1:08 PM, David Karr wrote:
>>
>> I install Cygwin every couple of years and then use it continuously
>> without updates between those installations.  I installed it on a new
>> laptop today, and I'm trying to work through issues.
>>
>> The current issue is running Emacs from the desktop.
>>
>> I had a shortcut working for a long time that does the following:
>> -
>> C:\cygwin64\bin\run2.exe --display 127.0.0.1:0.0 /usr/local/bin/emacs.xml
>> -
>>
>> The "run2" application doesn't appear to exist.  I checked my notes,
>> and I can't tell whether I installed this from somewhere else the last
>> time I did this.
>
>
> Just install the run2 package.  It's still available.

Ok.  I find the search facility in setup somewhat confusing.  I
couldn't find it before. I found it now, and I've installed it.

Then I had to remember the other conversation we had last year about
creating "/usr/local/bin/emacs.xml".  Now all working.

Thanks.

--
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

Proper way to run emacs from desktop

[David Karr]

I install Cygwin every couple of years and then use it continuously
without updates between those installations.  I installed it on a new
laptop today, and I'm trying to work through issues.

The current issue is running Emacs from the desktop.

I had a shortcut working for a long time that does the following:
-
C:\cygwin64\bin\run2.exe --display 127.0.0.1:0.0 /usr/local/bin/emacs.xml
-

The "run2" application doesn't appear to exist.  I checked my notes,
and I can't tell whether I installed this from somewhere else the last
time I did this.

I tried changing "run2" to "run". This didn't fail.  It also didn't do anything.

What should I do 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: mintty window gets tilde characters "pressed" in it

[David Karr]

On Wed, Dec 14, 2016 at 1:33 PM, David Karr <davidmichaelk...@gmail.com> wrote:
> On Wed, Dec 14, 2016 at 12:06 PM, Thomas Wolff <t...@towo.net> wrote:
>> I've checked with Caffeine and traced mintty. It receives F15 key down, the
>> key up. Caffeine claims to send key up only but that's not true. Please
>> report this as a bug to Caffeine.
>
> Understood.  I just did that.  However, will that really make any
> difference? If mintty only receives the keyup event, will that make it
> ignore it entirely?

I think I have a solution. I've looked at the command line options for
caffeine many times, and I never noticed the "-useshift" option, which
makes it use the shift key instead of f15.  That should do the trick
for me. I'm testing it now, and it appears to be fine (and it also
doesn't appear to cause trouble if I'm typing while the event is
emitted).

--
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: mintty window gets tilde characters "pressed" in it

[David Karr]

On Wed, Dec 14, 2016 at 12:06 PM, Thomas Wolff  wrote:
> I've checked with Caffeine and traced mintty. It receives F15 key down, the
> key up. Caffeine claims to send key up only but that's not true. Please
> report this as a bug to Caffeine.

Understood.  I just did that.  However, will that really make any
difference? If mintty only receives the keyup event, will that make it
ignore it entirely?

> X11 does not seem to handle F13...F24 at all because they don't appear on a
> typical PC keyboard (that's my assumption), so it doesn't occur in xterm. It
> generates a ~ only in terminal applications because a number of key escape
> sequences end with ~.
>
> The key event from Caffeine can be distinguished from a real key event,
> because it does not include keyboard scancode information. So a workaround
> is possible in theory. I'm not sure though whether that's a good idea as
> there may be other applications that inject keys the same way, e.g. drivers
> of other input devices, like Braille.
> Opinions and information are appreciated.

--
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: mintty window gets tilde characters "pressed" in it

[David Karr]

On Mon, Dec 12, 2016 at 10:18 AM, David Karr <davidmichaelk...@gmail.com> wrote:
> Win7.  I believe my Cygwin version info is "2.5.2(0.297/5/3) 2016-06-23 
> 14:29".
>
> I've been annoyed for a while with a symptom in my mintty windows.  I
> will be typing along, or not, and suddenly a "~" character gets
> injected into the stream. It often is the only character at the
> prompt, so I can erase it and type my command, but it's really
> annoying when it appears while I'm typing. I was just reminded of it
> now when it injected the "~" right before I pressed enter on a
> "mkdir", so I had to then remove the dir I just created and recreate
> it.
>
> Is this something that Cygwin can control?

I've determined what "instigates" this, but I find that it only mainly
affects mintty and somewhat affects emacs. I've never seen a symptom
in any other application.

I use a tool called "Windows Caffeine" that is used to keep the
display awake.  It sends a "f15 key up" event every 59 seconds.  That
is what is producing the "~" character in the mintty window.  I've
also seen a symptom from this in Emacs, but it's harder to produce.
It's not as simple as just having a text buffer in focus. I haven't
been able to reliably produce it in Emacs, but the mintty symptom is
very reproducible.

--
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 window gets tilde characters "pressed" in it

[David Karr]

Win7.  I believe my Cygwin version info is "2.5.2(0.297/5/3) 2016-06-23 14:29".

I've been annoyed for a while with a symptom in my mintty windows.  I
will be typing along, or not, and suddenly a "~" character gets
injected into the stream. It often is the only character at the
prompt, so I can erase it and type my command, but it's really
annoying when it appears while I'm typing. I was just reminded of it
now when it injected the "~" right before I pressed enter on a
"mkdir", so I had to then remove the dir I just created and recreate
it.

Is this something that Cygwin can control?

--
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

procps doesn't show some processes that ProcessExplorer can see

[David Karr]

In an Emacs shell buffer, I'm running Maven, which runs some PaxExam
integration tests, which run instances of karaf, which is a Java
process.

When this is running, I can see the java processes in SysInternal's
ProcessExplorer.

If I open a mintty, whether run as an admin or not, and run "procps
-wwFAH" it doesn't show those java processes. I can see the java
process running Maven, but not the subprocesses.

Why might that be?

--
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: mintty shows some text in other than foreground color

[David Karr]

I've managed to resolve this.  I turned off color output in the cqlsh
config file. It doesn't provide a way that I can see to configure the
colors that are used, and black works perfectly fine for me.

On Fri, Sep 16, 2016 at 6:46 AM, James Darnley <james.darn...@gmail.com> wrote:
> On 2016-09-15 22:47, David Karr wrote:
>> When I run mintty, the background is white, and normal text is black.
>> This is fine.  However, there are some applications that are
>> displaying text in other colors, many of which are fine, but some apps
>> display some text in yellow, which on a white background is almost
>> unreadable.
>>
>> For instance, the display from Cassandra's "cqlsh" shows the results
>> of queries in black, purple (probably not quite right), and yellow.
>> The worst part is, it's using yellow for the column values.
>>
>> Is there any way to control this, in general (obviously, not just for
>> cqlsh output)?
>
> Set Mintty's yellow colour to be something legible against your chosen
> background colour.
>
> (Come to think of it, I should rebase my old GUI colour selection patch.
>  I probably should update Mintty anyway.  But all that would require
> effort.)
>
> P.S.  Sorry about mailing you directly David.
>

--
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 shows some text in other than foreground color

[David Karr]

When I run mintty, the background is white, and normal text is black.
This is fine.  However, there are some applications that are
displaying text in other colors, many of which are fine, but some apps
display some text in yellow, which on a white background is almost
unreadable.

For instance, the display from Cassandra's "cqlsh" shows the results
of queries in black, purple (probably not quite right), and yellow.
The worst part is, it's using yellow for the column values.

Is there any way to control this, in general (obviously, not just for
cqlsh output)?

--
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

Trouble running emacs on new box

[David Karr]

I had Cygwin running on an old box for a while.  I have a desktop
shortcut to run Emacs, using the following command line:
-
C:\cygwin64\bin\run2.exe --display 127.0.0.1:0.0 /usr/local/bin/emacs.xml


This was working fine.  I set this up quite a while ago, so I don't
quite remember the circumstances of the pieces of this.

I'm now setting up cygwin on a new box, with very similar
configuration. Unfortunately, setting up Cygwin is something I don't
do very often, and it's usually a year or more since the last time I
did it.  I've already reviewed the FAQ and User Guide for hints.

When I first tried this command line, it failed without any good error
messages.  I later realized that one good reason it's failing is that
"/usr/local/bin/emacs.xml" doesn't exist on the new box.  I looked at
this file on the old box, and it seems relatively simple, but is this
a file I'm supposed to create myself?  I don't remember doing 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: emacs won't run

[David Karr]

Are you running it from the desktop from run?  I discovered the same
thing.  One workaround that worked for me was to open a rxvt window
and then run emacs from that. However, an even better workaround was
simply using the w32 version and bypassing X entirely. When I
changed my run shortcut to run emacs-w32 instead, it works fine.

On Wed, Dec 4, 2013 at 1:20 AM, Andrea Venturoli m...@netfence.it wrote:
 Hello.

 Since a bit, emacs won't start under X: no error, no message, nothing. It
 just starts and exits after a while without doing anything.

 I can run emacs -nw fine.

 How can I diagnose this? Is there any log I can look into? Any utility?

  bye  Thanks
 av.

 --
 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


--
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: Were the Perl multithreading problems ever fixed?

[David Karr]

(Resending because it complained about my inadvertently using html.)

My Cygwin Perl is 5.14.2.  I don't have a link to a report.  I never
filed a bug report, but we had an email exchange about this starting
on 1/13/12.  My script is still having occasional problems, but it's
not dumping core.  I'll have to do some more debugging to see what I
can see.

On Mon, May 20, 2013 at 7:10 PM, Reini Urban rur...@x-ray.at wrote:
 On Mon, May 20, 2013 at 1:14 PM, KARR, DAVID wrote:
 Last year I had reported some problems with a Perl script that utilizes 
 multithreading.  I believe it was Reini Urban who told me that there were 
 known problems with Perl multithreading and that an ETA for a set of fixes 
 was not known yet.  Does anyone know if those particular Perl multithreading 
 issues have been dealt with in later Cygwin releases?  I'm still on 1.7.17.

 These were entirely perl related and not cygwin.
 And most of the known problems were fixed with the change from
 non-thread safe usemymalloc (perl internal malloc) to the thread-safe
 system malloc
 with 5.14.2.
 There are still minor thread problems within perl, but nothing dramatic.

 The upcoming 5.18.0 should have fixed more. Do you have a link to your
 report? So I can test it.
 --
 Reini Urban
 http://cpanel.net/   http://www.perl-compiler.org/

 --
 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


--
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: Is Cygwin X server causing ubuntu eclipse to copy to the clipboard on selection?

[David Karr]

On Thu, Jun 28, 2012 at 7:49 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote:
 On 25/06/2012 16:53, David Karr wrote:
 I just verified that I can easily configure Emacs to not copy to the
 clipboard on selection, and to replace the selection on yank.  It's
 unfortunate that I can't directly configure Eclipse to do this, but I
 would be surprised if they would have thought to implement this, as
 Eclipse normally works the way you expect on both Ubuntu and
 Windows.  It's only when displaying the Ubuntu window on Windows
 through Cygwin that it behaves unconventionally.

 I'm not sure what you are suggesting here, but changing the default behaviour
 of the Cygwin X server so it requires everyone who uses it to reconfigure
 their emacs is not an acceptable solution.

Certainly not.  It was just an observation.

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

Re: Is Cygwin X server causing ubuntu eclipse to copy to the clipboard on selection?

[David Karr]

On Mon, Jun 25, 2012 at 6:22 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote:
 On 23/06/2012 00:33, David Karr wrote:
 I run Eclipse on win7, and also Eclipse on Ubuntu, displaying the
 window on my Win7 box, using Cygwin.

 One annoyance I have with the latter is that when I select a region of
 text, it appears to automatically copy that region to the clipboard,
 instead of waiting for me to press Ctrl-C.

 I asked about this on the eclipse forums, and they said Ubuntu Eclipse
 doesn't do this, and it's likely being done by my X server.

 Yes, the X server is copying the selected text to the Windows clipboard.

 Let me try to explain why:

 X supports an arbitrary number of 'selections', the two of interest here are
 the PRIMARY selection (which conventionally contains some data which the user
 has selected) and the CLIPBOARD selection (which conventionally contains some
 data that the user has explicitly requested to be 'copied' to the clipboard)

 The Cygwin X server monitors these selections for changes, and makes text in
 the most recently changed one available for pasting from the Windows 
 clipboard.

It seems like you've just explained to me by using the word
conventionally that the behavior of the Cygwin X server doesn't
behave conventionally.

 So, if you select some text in eclipse after copying some text to the
 clipboard, you will get the selected text, not the copied text, when you paste
 in Windows.

 I can understand this behaviour is confusing to people who are expecting the X
 clipboard to behave like the Windows one.

 It has been suggested a few times that we should not monitor the PRIMARY
 selection, but some very popular X applications (such as xterm and emacs) only
 use the PRIMARY selection by default.  It's also been suggested that
 monitoring the PRIMARY selection should be configurable somehow, but I'm not
 sure that a global configuration option would lead to very useful behaviour.

I just verified that I can easily configure Emacs to not copy to the
clipboard on selection, and to replace the selection on yank.  It's
unfortunate that I can't directly configure Eclipse to do this, but I
would be surprised if they would have thought to implement this, as
Eclipse normally works the way you expect on both Ubuntu and
Windows.  It's only when displaying the Ubuntu window on Windows
through Cygwin that it behaves unconventionally.

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

Is Cygwin X server causing ubuntu eclipse to copy to the clipboard on selection?

[David Karr]

I run Eclipse on win7, and also Eclipse on Ubuntu, displaying the
window on my Win7 box, using Cygwin.

One annoyance I have with the latter is that when I select a region of
text, it appears to automatically copy that region to the clipboard,
instead of waiting for me to press Ctrl-C.

I asked about this on the eclipse forums, and they said Ubuntu Eclipse
doesn't do this, and it's likely being done by my X server.

I checked the Cygwin-X11 FAQ and the command-line options, and I don't
see anything that specifies this.

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

Re: Ubuntu scrollbars don't render in Cygwin

[David Karr]

On Thu, May 31, 2012 at 9:47 AM, David Karr davidmichaelk...@gmail.com wrote:
 I have an ubuntu 12.0.4 desktop.  I have a Win7 laptop running Cygwin. I can
 display windows from the Ubuntu box on the Win7 laptop using the Cygwin X
 server, but the window is somewhat degraded.  Specifically, scrollbars are
 not rendering properly.  I've used Ubuntu before, but this is the first time
 I've seen these odd scrollbar popups that are used in 12.04.  I'm guessing
 the Cygwin X server is having trouble rendering that for some reason.  In
 the Cygwin view, I see the slightly thicker vertical bar, but when I hover
 the mouse over it, nothing happens.

 I'm investigating whether I can configure Ubuntu to use normal scrollbars,
 but is there a way to get Cygwin's X server to display those funky
 scrollbars better?

I managed to fix Ubuntu's scrollbars so that it doesn't present this
problem.  The fix is documented at:
http://www.tuxgarage.com/2011/04/disable-overlay-scrollbars-in-ubuntu.html

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

Ubuntu scrollbars don't render in Cygwin

[David Karr]

I have an ubuntu 12.0.4 desktop.  I have a Win7 laptop running Cygwin.
I can display windows from the Ubuntu box on the Win7 laptop using the
Cygwin X server, but the window is somewhat degraded.  Specifically,
scrollbars are not rendering properly.  I've used Ubuntu before, but
this is the first time I've seen these odd scrollbar popups that are
used in 12.04.  I'm guessing the Cygwin X server is having trouble
rendering that for some reason.  In the Cygwin view, I see the
slightly thicker vertical bar, but when I hover the mouse over it,
nothing happens.

I'm investigating whether I can configure Ubuntu to use normal
scrollbars, but is there a way to get Cygwin's X server to display
those funky scrollbars better?

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

Can display remote X window from bash, but not from DOS window

[David Karr]

I have a Win7 laptop with Cygwin and a Ubuntu desktop box.  I can ssh
from the laptop with shared keys and X11 forwarding, so that I can run
a simple command line in a Bash shell on the Win7 box and it will open
up the window for the remote process on my Win7 box.

What I'm having trouble with is setting up a Win7 desktop shortcut
that will do this.

I have a simple Bash script called dt (stands for desktop) that
calls ssh and passes the scripts command line parameters to ssh.  As
I said, this works fine when I call it from a Bash shell window.

I wrote a DOS batch script that does something like this:

c:\cygwin\bin\bash -cl =pathprefix=/dt =remote command line=

This bombs with numerous errors.  This is the first one:

(STS:30397): GLib-GObject-WARNING **: invalid (NULL) pointer instance

What's the correct way to do this?

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

How to properly start xwin at windows seven startup?

[David Karr]

I've had an old version of Cygwin running on a WinXP laptop for quite
a while.  I made it run startxwin.bat on startup.  I'm now setting
up the latest Cygwin on a Win7 laptop.  The FAQ is saying to not use
the startxwin.bat file (as it doesn't exist anymore), and use the
exe file. However, it also says to not start it directly from Windows.
 It needs to be started from a login shell.  What is the proper way to
start the Xwin server at Windows startup?  I didn't see this in the
FAQ, and I didn't find any obvious answers in searches.

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

Re: How to properly start xwin at windows seven startup?

[David Karr]

On Thu, Feb 2, 2012 at 12:08 PM, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
 On Thu, 2012-02-02 at 09:49 -0800, David Karr wrote:
 I've had an old version of Cygwin running on a WinXP laptop for quite
 a while.  I made it run startxwin.bat on startup.  I'm now setting
 up the latest Cygwin on a Win7 laptop.  The FAQ is saying to not use
 the startxwin.bat file (as it doesn't exist anymore), and use the
 exe file. However, it also says to not start it directly from Windows.
  It needs to be started from a login shell.  What is the proper way to
 start the Xwin server at Windows startup?  I didn't see this in the
 FAQ, and I didn't find any obvious answers in searches.

 Presuming you want to start XWin in multiwindow mode, the xinit package
 installs an XWin Server shortcut into the Start Menu.  Copy this
 shortcut into your Startup folder and you should get the desired result.

That appeared to do the trick, thanks.

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

RE: How to avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Eric Blake
 Sent: Tuesday, June 23, 2009 9:04 AM
 To: cygwin@cygwin.com
 Subject: Re: How to avoid having shell scripts which fail from killing
 Emacs shell?
 
 David Karr dkarr at real.com writes:
 
 I'm not sure how complicated it needs to be.  My test case gathers
 a
couple
 of parameters and then calls a Java (JDK 1.6.0_14) class.
  
   I found that the key is whether the Java class reads from stdin or
 not.
 
  I just tried changing my script to instead just do a read with a
 prompt.
  This does not kill the shell at the end of the script.  When I do it in
  Java, it kills the shell at the end of the script.  Weird.
 
 Hmm.  JDK is a native windows app, not a cygwin app.  So maybe the key
 here is
 not just reading stdin, but passing stdin to a non-cygwin app.

That seems reasonable.  In the past, I believe I've seen references to
issues related to I/O interactions with non-cygwin apps.  Does that notion
give any one else a clue to why this might be happening, or how to mitigate
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: How to avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Matthias Andree
 Sent: Tuesday, June 23, 2009 4:13 AM
 To: cygwin@cygwin.com
 Subject: Re: How to avoid having shell scripts which fail from killing
 Emacs shell?
 
 David Karr schrieb:
  -Original Message-
  From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
 Behalf
  Of Ken Brown
  Sent: Monday, June 22, 2009 12:54 PM
  To: cygwin@cygwin.com
  Subject: Re: How to avoid having shell scripts which fail from killing
  Emacs shell?
 
  On 6/22/2009 3:38 PM, David Karr wrote:
  -Original Message-
  From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
  Behalf
  Of Ken Brown
  Sent: Monday, June 22, 2009 12:26 PM
  On 6/22/2009 10:53 AM, David Karr wrote:
  I've often been annoyed by shell scripts which fail for particular
  reasons, at which point it causes my Emacs shell buffer to get
 killed,
  with Process shell2 finished.
  I don't recall ever seeing this happen, but maybe I just don't
  remember.
Can you give me a simple test case?
  I'm not sure how complicated it needs to be.  My test case gathers a
  couple
  of parameters and then calls a Java (JDK 1.6.0_14) class.  The class
  throws
  an exception (file not found) in my test case (because I'm
 deliberately
  giving it parameters that will cause that).  If I give it parameters
  that
  will avoid the exception, then it doesn't kill the shell.
 
  Is that enough information to build a test case with?
  No.  I don't have JDK installed, and I don't have any idea how it
  interacts with cygwin processes.  If you can trigger the problem with a
  simple shell script that doesn't require JDK, I'll see if I can help.
  Or maybe someone on the list who does have JDK can suggest something
 for
  you to try.
 
  I was able to produce an additional clue by writing a custom class for
  testing this.
 
  I found that the key is whether the Java class reads from stdin or not.
 I
  built a first version that takes a filepath on the command line, and
 whether
  I get the class to throw an exception or not, it exits the script
 without
  killing the shell.  However, when I changed the class to also read a
 line of
  input from stdin, whether the filepath on the command line exists or not
  (i.e., whether the class throws an exception or not), it kills the shell
 at
  completion of the script.
 
  So, it has something to do with whether the sub-shell reads stdin or
 not.  I
  have no idea what that indicates, but I'm sure that must be useful
  information.
 
 Just a few pointers:
 
 Does the problem go away if the java command is enclosed in parentheses,
 so as
 to run it in a sub-shell?

No, I tried that earlier.  No difference.

 Are you using (perhaps in the emacs configuration somewhere) shell options
 like
 -e for the /outer/ shell?

No.

 Are you sourcing (. scriptname) rather than executing (scriptname)
 your scripts?

No.


--
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 avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of David Karr
 Sent: Monday, June 22, 2009 4:42 PM
 To: kbr...@cornell.edu; cygwin@cygwin.com
 Subject: RE: How to avoid having shell scripts which fail from killing
 Emacs shell?
 
  -Original Message-
  From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
  Of Ken Brown
  Sent: Monday, June 22, 2009 12:54 PM
  To: cygwin@cygwin.com
  Subject: Re: How to avoid having shell scripts which fail from killing
  Emacs shell?
 
  On 6/22/2009 3:38 PM, David Karr wrote:
   -Original Message-
   From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
  Behalf
   Of Ken Brown
   Sent: Monday, June 22, 2009 12:26 PM
   On 6/22/2009 10:53 AM, David Karr wrote:
   I've often been annoyed by shell scripts which fail for particular
   reasons, at which point it causes my Emacs shell buffer to get
 killed,
   with Process shell2 finished.
   I don't recall ever seeing this happen, but maybe I just don't
  remember.
 Can you give me a simple test case?
  
   I'm not sure how complicated it needs to be.  My test case gathers a
  couple
   of parameters and then calls a Java (JDK 1.6.0_14) class.  The class
  throws
   an exception (file not found) in my test case (because I'm
 deliberately
   giving it parameters that will cause that).  If I give it parameters
  that
   will avoid the exception, then it doesn't kill the shell.
  
   Is that enough information to build a test case with?
 
  No.  I don't have JDK installed, and I don't have any idea how it
  interacts with cygwin processes.  If you can trigger the problem with a
  simple shell script that doesn't require JDK, I'll see if I can help.
  Or maybe someone on the list who does have JDK can suggest something for
  you to try.
 
 I was able to produce an additional clue by writing a custom class for
 testing this.
 
 I found that the key is whether the Java class reads from stdin or not.  I
 built a first version that takes a filepath on the command line, and
 whether
 I get the class to throw an exception or not, it exits the script without
 killing the shell.  However, when I changed the class to also read a line
 of
 input from stdin, whether the filepath on the command line exists or not
 (i.e., whether the class throws an exception or not), it kills the shell
 at
 completion of the script.
 
 So, it has something to do with whether the sub-shell reads stdin or not.
 I
 have no idea what that indicates, but I'm sure that must be useful
 information.

I just tried changing my script to instead just do a read with a prompt.
This does not kill the shell at the end of the script.  When I do it in
Java, it kills the shell at the end of the script.  Weird.


--
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

How to avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

I've often been annoyed by shell scripts which fail for particular
reasons, at which point it causes my Emacs shell buffer to get killed,
with Process shell2 finished.

I think it's possible to code the scripts to use trap, which might avoid
this problem, but sometimes (most times, really) I can't change the script.
Is there some way to configure Bash/Cygwin, perhaps in the .emacs_bash
script to mitigate this, without significant tradeoffs?



--
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 avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Ken Brown
 Sent: Monday, June 22, 2009 12:26 PM
 To: cygwin@cygwin.com
 Subject: Re: How to avoid having shell scripts which fail from killing
 Emacs shell?
 
 On 6/22/2009 10:53 AM, David Karr wrote:
  I've often been annoyed by shell scripts which fail for particular
  reasons, at which point it causes my Emacs shell buffer to get killed,
  with Process shell2 finished.
 
 I don't recall ever seeing this happen, but maybe I just don't remember.
   Can you give me a simple test case?

I'm not sure how complicated it needs to be.  My test case gathers a couple
of parameters and then calls a Java (JDK 1.6.0_14) class.  The class throws
an exception (file not found) in my test case (because I'm deliberately
giving it parameters that will cause that).  If I give it parameters that
will avoid the exception, then it doesn't kill the shell.

Is that enough information to build a test case with?



--
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 avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Ken Brown
 Sent: Monday, June 22, 2009 12:54 PM
 To: cygwin@cygwin.com
 Subject: Re: How to avoid having shell scripts which fail from killing
 Emacs shell?
 
 On 6/22/2009 3:38 PM, David Karr wrote:
  -Original Message-
  From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
 Behalf
  Of Ken Brown
  Sent: Monday, June 22, 2009 12:26 PM
  On 6/22/2009 10:53 AM, David Karr wrote:
  I've often been annoyed by shell scripts which fail for particular
  reasons, at which point it causes my Emacs shell buffer to get killed,
  with Process shell2 finished.
  I don't recall ever seeing this happen, but maybe I just don't
 remember.
Can you give me a simple test case?
 
  I'm not sure how complicated it needs to be.  My test case gathers a
 couple
  of parameters and then calls a Java (JDK 1.6.0_14) class.  The class
 throws
  an exception (file not found) in my test case (because I'm deliberately
  giving it parameters that will cause that).  If I give it parameters
 that
  will avoid the exception, then it doesn't kill the shell.
 
  Is that enough information to build a test case with?
 
 No.  I don't have JDK installed, and I don't have any idea how it
 interacts with cygwin processes.  If you can trigger the problem with a
 simple shell script that doesn't require JDK, I'll see if I can help.
 Or maybe someone on the list who does have JDK can suggest something for
 you to try.

I was able to produce an additional clue by writing a custom class for
testing this.

I found that the key is whether the Java class reads from stdin or not.  I
built a first version that takes a filepath on the command line, and whether
I get the class to throw an exception or not, it exits the script without
killing the shell.  However, when I changed the class to also read a line of
input from stdin, whether the filepath on the command line exists or not
(i.e., whether the class throws an exception or not), it kills the shell at
completion of the script.

So, it has something to do with whether the sub-shell reads stdin or not.  I
have no idea what that indicates, but I'm sure that must be useful
information.


--
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 run GNU Emacs from Windows icon

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Ken Brown
 Sent: Thursday, June 18, 2009 11:35 AM
 To: cygwin@cygwin.com
 Subject: Re: How to run GNU Emacs from Windows icon
 
 On 6/4/2009 12:10 PM, David Karr wrote:
  emacs: Terminal type cygwin is not defined.
  My guess is that this is a terminfo issue.  Try installing the
 terminfo0
  package.
 
  Getting back to this, I already have terminfo0 installed.
 
 I think the cause of your problem with emacs-21 may have been found:
 
http://cygwin.com/ml/cygwin/2009-06/msg00615.html
 
 Anyway, I hope you're happily using emacs-23 now so that this is no
 longer relevant.  (emacs-23 depends on terminfo rather than terminfo0.)

It is working fine, but I have a feeling the solution I ended up using
probably would have worked in the regular version also.  My shortcut command
line is (paraphrased) rxvt bash emacs.  I'm not going to worry too much
about it at this point.

Thanks.


--
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: How to run GNU Emacs from Windows icon

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Andrew DeFaria
 Sent: Friday, June 05, 2009 8:03 PM
 To: cygwin@cygwin.com
 Subject: Re: How to run GNU Emacs from Windows icon
 
 David Karr wrote:
  -Original Message-
  From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
 Behalf
  Of Andrew DeFaria
  Sent: Friday, June 05, 2009 8:47 AM
  To: cygwin@cygwin.com
  Subject: Re: How to run GNU Emacs from Windows icon
 
  David Karr wrote:
  I now need to set up Windows desktop icons that can start these
  processes. I managed to get XEmacs working, with the following
  command line:
 
  C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/xemacs-21.4.22.exe
  Why the insistence on running bash? Why not simply run Xemacs? That's
  what I do at work and it works fine for me.
  It may not produce any difficult symptoms with XEmacs itself, but
  without that I don't get a normal login shell out of the box.
 And why do you require a normal login shell? Here's what I have for my
 shortcut that starts up XEmacs: C:\Cygwin\bin\run.exe xemacs. Nothing
 else is required. I don't need to login. I'm logged in already. I just
 need to edit files...
  Again, why run bash first then run emacs?
  Again, so I get a login shell. In any case, this has no effect on the
  symptom. I tried doing this without bash, and it fails in exactly the
  same way.
 You have not defined what exactly your symptom is WRT xemacs. You
 stated:
 
 I managed to get XEmacs working, with the following command line:
 
   C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/xemacs-21.4.22.exe
 
 
 Then went on to describe how it fails with emacs (not xemacs) because
 emacs and a problem with your terminal type. I would think that xemacs
 doesn't care as much about terminal type. Is xemacs failing with the
 same error about terminal type? What is TERM set to for you? (Me: it's
 set to cygwin).

Sorry I didn't make that clear, but it wasn't really relevant to this.
XEmacs is working fine with respect to basic startup from an icon.  I'm
having issues with the help window machinery, which doesn't have anything to
do with these problems.


--
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: How to run GNU Emacs from Windows icon

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Andrew DeFaria
 Sent: Friday, June 05, 2009 8:47 AM
 To: cygwin@cygwin.com
 Subject: Re: How to run GNU Emacs from Windows icon
 
 David Karr wrote:
  I now need to set up Windows desktop icons that can start these
  processes. I managed to get XEmacs working, with the following command
  line:
 
  C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/xemacs-21.4.22.exe
 Why the insistence on running bash? Why not simply run Xemacs? That's
 what I do at work and it works fine for me.

It may not produce any difficult symptoms with XEmacs itself, but without
that I don't get a normal login shell out of the box.

  However, when I try to do something similar for GNU Emacs, it fails
  immediately. When I tried running the analogous command from the DOS
  prompt, I got this:
 
  -
  C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/emacs.exe
  emacs: Terminal type cygwin is not defined.
  If that is not the actual type of terminal you have,
  use the Bourne shell command `TERM=... export TERM' (C-shell:
  `setenv TERM ...') to specify the correct type. It may be necessary
  to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well.
 Again, why run bash first then run emacs?

Again, so I get a login shell.  In any case, this has no effect on the
symptom.  I tried doing this without bash, and it fails in exactly the same
way.

Thanks.


--
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: How to run GNU Emacs from Windows icon

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Ken Brown
 Sent: Friday, June 05, 2009 11:37 AM
 To: cygwin@cygwin.com
 Subject: Re: How to run GNU Emacs from Windows icon
 
 On 6/5/2009 11:58 AM, David Karr wrote:
  C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/emacs.exe
  emacs: Terminal type cygwin is not defined.
  If that is not the actual type of terminal you have,
  use the Bourne shell command `TERM=... export TERM' (C-shell:
  `setenv TERM ...') to specify the correct type. It may be necessary
  to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well.
  Again, why run bash first then run emacs?
 
  Again, so I get a login shell.  In any case, this has no effect on the
  symptom.  I tried doing this without bash, and it fails in exactly the
 same
  way.
 
 I have a few other suggestions if you want to keep trying to track this
 down:
 
 1. Send cygcheck output (as an attachment) as requested at
 http://cygwin.com/problems.html

Attached.

 2. Try emacs -q to make sure there's nothing in your initialization
 file(s) causing the problem.

No difference.  Considering the failure happens even before the window comes
up, I would have been shocked if it made a difference.

 3. Try emacs 23:
 
http://sourceware.org/ml/cygwin/2009-05/msg00475.html
http://sourceware.org/ml/cygwin/2009-05/msg00635.html

I'll proceed with that.

Thanks.


cygcheck.out
Description: Binary data
--
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: How to run GNU Emacs from Windows icon

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Ken Brown
 Sent: Friday, June 05, 2009 11:37 AM
 To: cygwin@cygwin.com
 Subject: Re: How to run GNU Emacs from Windows icon
 
 On 6/5/2009 11:58 AM, David Karr wrote:
  C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/emacs.exe
  emacs: Terminal type cygwin is not defined.
  If that is not the actual type of terminal you have,
  use the Bourne shell command `TERM=... export TERM' (C-shell:
  `setenv TERM ...') to specify the correct type. It may be necessary
  to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well.
  Again, why run bash first then run emacs?
 
  Again, so I get a login shell.  In any case, this has no effect on the
  symptom.  I tried doing this without bash, and it fails in exactly the
 same
  way.
 
 I have a few other suggestions if you want to keep trying to track this
 down:
 
 3. Try emacs 23:
 
http://sourceware.org/ml/cygwin/2009-05/msg00475.html
http://sourceware.org/ml/cygwin/2009-05/msg00635.html

Ok, I've done some searching, but I can't figure out how to get this
package.  I've never installed experimental packages before.  The latest
available from setup.exe, even in experimental state, is 22.1-3.  I assume
I'm looking for -23.0.92-2?


--
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: How to run GNU Emacs from Windows icon

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Ken Brown
 Sent: Friday, June 05, 2009 2:04 PM
 To: cygwin@cygwin.com
 Subject: Re: How to run GNU Emacs from Windows icon
 
 On 6/5/2009 3:25 PM, David Karr wrote:
  1. Send cygcheck output (as an attachment) as requested at
  http://cygwin.com/problems.html
 
  Attached.
 
 Two things jump out at me.  First, it's clear from the environment
 variables that you ran cygcheck from a shell within emacs.  I don't
 think it matters in this case, but in general it's probably best not to
 do that, since you want to see the environment *before* starting emacs.
Emacs changes some of the variables.

Regenerated, and reattached.

 More importantly, I see this:
 
  CYGWIN = 'check_case:strict tty'
 
 I don't know whether this could be causing your problem, but the cygwin
 user's guide (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html) says
 the following:
 
 check_case:level - THIS OPTION IS DEPRECATED. Don't use it unless you
 know what you're doing and don't see any way around it. And even then,
 this option is error prone, slows down Cygwin and not well maintained.

Hmph.  When I read the documentation for a framework, I almost always go
directly to the PDF, if it's available.  The PDF doesn't say anything about
this being deprecated.  I wouldn't have used it if it had.  If I'm
interpreting the modification date on the file properly, this PDF hasn't
been regenerated in 5 years.

Looking at this also made me realize a silly mistake I was making, in that I
was setting CYGWIN in my .bashrc, not in my system env vars.  I fixed that,
and also removed check_case, but it had no obvious effect.

 On 6/5/2009 3:44 PM, David Karr wrote:
  Ok, I've done some searching, but I can't figure out how to get this
  package.  I've never installed experimental packages before.  The
 latest
  available from setup.exe, even in experimental state, is 22.1-3.  I
 assume
  I'm looking for -23.0.92-2?
 
 Just run setup.exe, locate the emacs packages, and repeatedly click on
 the version number in the New column.  It cycles through all of the
 choices, one of which should be 23.0.92-2.

Ah, yes.  It's been a while.  Proceeding.



cygcheck.out
Description: Binary data
--
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: How to run GNU Emacs from Windows icon

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Ken Brown
 Sent: Friday, June 05, 2009 11:37 AM
 To: cygwin@cygwin.com
 Subject: Re: How to run GNU Emacs from Windows icon
 
 On 6/5/2009 11:58 AM, David Karr wrote:
  C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/emacs.exe
  emacs: Terminal type cygwin is not defined.
  If that is not the actual type of terminal you have,
  use the Bourne shell command `TERM=... export TERM' (C-shell:
  `setenv TERM ...') to specify the correct type. It may be necessary
  to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well.
  Again, why run bash first then run emacs?
 
  Again, so I get a login shell.  In any case, this has no effect on the
  symptom.  I tried doing this without bash, and it fails in exactly the
 same
  way.
 
 I have a few other suggestions if you want to keep trying to track this
 down:
 
 1. Send cygcheck output (as an attachment) as requested at
 http://cygwin.com/problems.html
 
 2. Try emacs -q to make sure there's nothing in your initialization
 file(s) causing the problem.
 
 3. Try emacs 23:
 
http://sourceware.org/ml/cygwin/2009-05/msg00475.html
http://sourceware.org/ml/cygwin/2009-05/msg00635.html

Ok, I've installed Emacs 23.  The results are sort of better, but worse.
Running it now, which actually runs emacs-X11 through a link, looks like
emacs -nw.  It's definitely not using X11.  If I run it from a Bash prompt
in rxvt, it comes up fine (with the minor annoyance that setting the
frame-position at 0,0 doesn't mean the same thing as it did before), and the
fonts are definitely nicer. :)

 
 Ken
 
 --
 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/


--
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: How to run GNU Emacs from Windows icon

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Ken Brown
 Sent: Friday, June 05, 2009 11:37 AM
 To: cygwin@cygwin.com
 Subject: Re: How to run GNU Emacs from Windows icon
 
 3. Try emacs 23:
 
http://sourceware.org/ml/cygwin/2009-05/msg00475.html
http://sourceware.org/ml/cygwin/2009-05/msg00635.html

For now, I can at least hide most of the cruft by using this as my shortcut
command:

C:\cygwin\bin\rxvt.exe -geometry 1x1 -e /usr/bin/bash --login -c emacs

Along with hacking the frame-position to 4,26 (I imagine this will only be a
temporary problem).

This gives me a usable window without additional manual steps.

(Now I just have to find a reasonable Windows icon for it.)


--
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: How to run GNU Emacs from Windows icon

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Ken Brown
 Sent: Tuesday, June 02, 2009 4:52 AM
 To: cygwin@cygwin.com
 Subject: Re: How to run GNU Emacs from Windows icon
 
 On 6/2/2009 7:18 AM, Ken Brown wrote:
  On 6/2/2009 5:30 AM, Marc Girod wrote:
  I can also start a Cygwin window, and run GNU emacs there (with a -nw
  option).
  It starts, although doesn't work well. The keyboard bindings are weird
  for a
  start (e.g. C-x C-c gives in fact C-x C-g, which forces you to exit
  with M-x
  kill-emacs).
  I'm sure this was discussed already.
 
  You need to have 'tty' in your CYGWIN environment variable in order to
  prevent this from happening.  But even then, you'll find that many
  keystrokes don't work as expected.  If you want to run emacs in a
  terminal (rather than under X), you'll get much better results with
  mintty or rxvt.
 
 But none of this addresses the OP's original problem:
 
  emacs: Terminal type cygwin is not defined.
 
 My guess is that this is a terminfo issue.  Try installing the terminfo0
 package.

Getting back to this, I already have terminfo0 installed.

I tried Marc Girod's emacs.bat script from an earlier reply, but it doesn't
work for me because I already have an X server running.  What I really need
is something that gives me a regular separate Windows decorated frame, with
Emacs running inside.  I get that out of the box with XEmacs, but some
things work a little better in GNU Emacs, so I'm trying to get that working.


--
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: Unable to convert postscript to usable form, using either ps2pdf or gs

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of David Karr
 Sent: Monday, June 01, 2009 2:33 PM
 To: cygwin@cygwin.com
 Subject: Unable to convert postscript to usable form, using either ps2pdf
 or gs
 
 I have a generated postscript file (from trueprint) that I need to get
 into
 a usable form on Windows, so I can view it and print it.  I've tried both
 ps2pdf and gs, with no success so far.
 
 I first tried using ps2pdf.  This fails with:
 
 ---
 % ps2pdf tp.ps tp.pdf
 GPL Ghostscript 8.62:  Could not open temporary file
 /c/DOCUME~1/User/LOCALS~1/Temp/gs_dwvfJL
  Unable to open the initial device, quitting.
 ---

I have no idea why this matters, but I got this to work by just setting
TMPDIR=/tmp (which makes more sense anyway).



--
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/

How to run GNU Emacs from Windows icon

[David Karr]

I'm now to the point where I can run rxvt, and then from the spawned Bash
process I can run emacs and get a reasonable Emacs process going.  I can
do the same with xemacs.

I now need to set up Windows desktop icons that can start these processes.
I managed to get XEmacs working, with the following command line:

  C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/xemacs-21.4.22.exe

However, when I try to do something similar for GNU Emacs, it fails
immediately.  When I tried running the analogous command from the DOS
prompt, I got this:

-
C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/emacs.exe
emacs: Terminal type cygwin is not defined.
If that is not the actual type of terminal you have,
use the Bourne shell command `TERM=... export TERM' (C-shell:
`setenv TERM ...') to specify the correct type.  It may be necessary
to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well.
-

I've made some guesses on what terminal type it should be set to, but I
haven't gotten this to work.


--
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: Unable to convert postscript to usable form, using either ps2pdf or gs

[David Karr]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
 Of Matthias Andree
 Sent: Tuesday, June 02, 2009 12:40 AM
 To: David Karr; cygwin@cygwin.com
 Subject: Re: Unable to convert postscript to usable form, using either
 ps2pdf or gs
 
 Am 01.06.2009, 23:33 Uhr, schrieb David Karr dk...@real.com:
 
  I have a generated postscript file (from trueprint) that I need to get
  into a usable form on Windows, so I can view it and print it.  I've
  tried both
  ps2pdf and gs, with no success so far.
 
  I first tried using ps2pdf.  This fails with:
 
  ---
  % ps2pdf tp.ps tp.pdf
  GPL Ghostscript 8.62:  Could not open temporary file
  /c/DOCUME~1/User/LOCALS~1/Temp/gs_dwvfJL
   Unable to open the initial device, quitting.
  ---
 
  It isn't an obvious permissions problem, because I can touch that file
  with no problem.
 
 Confirm - with for instance type -a ps2pdf or which ps2pdf if you're
 really invoking the ps2pdf you believe you're invoking, and if not, fix
 your installation and/or the PATH variable (though Windows's dialogue).

Confirmed.

  I then tried just gs tp.ps, and that fails with this:
 
  --
  % gs tp.ps
  GPL Ghostscript 8.62 (2008-02-29)
  Copyright (C) 2008 Artifex Software, Inc.  All rights reserved.
  This software comes with NO WARRANTY: see the file PUBLIC for details.
  Loading NimbusMonL-Regu font from
  /usr/share/ghostscript/fonts/n022003l.pfb... 2449904 1067520 4774456
  3452340
 ...
  3456751
  1 done.
  GPL Ghostscript 8.62:  Could not open the file  .
  Error: /invalidfileaccess in --showpage--
  Operand stack:
 1   true
 
 Is the output file in use? You cannot overwrite open file because most
 (not all) applications lock their input files. A notable exception for PDF
 viewers is SumatraPDF.

I'm pretty certain it was not, as that was obviously a temporary file that
gs created without my intervention.

However, when I just tried it again, it magically worked.  This doesn't
really help me, though.  I still need ps2pdf to work, so I can make use of
the postscript.


--
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/