Re: hostname: : Bad address apprers on Cygwin_x86_64

[Marco Atzeri]

On 12/05/2014 11:35, Tatsuro MATSUOKA wrote:

Hello

Executing Cygwin.bat on  Cygwin_x86_64, a message "hostname: : Bad address" 
before representation of the prompt like:


hostname: : Bad address

Tatsu@Tatsu-PC ~
$
*

What is wrong with my system?

Tatsuro



Hi Tatsuro,
eventually nothing specific of your system.
Could you trace which command is giving that output ?

Marco





--
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 do start a cygwin shell session from a script ?

[Timothy Madden]

Hello

I have a CMake build script for my application, that among other
things tries to build libvpx (open-source video codec, see
webmproject.org).

libvpx library v1.3.0 compiles fine by hand when I open a cygwin
terminal from the Windows start menu and type in the needed
`configure`; `make` and `make install` commands.

But when I try to invoke the cygwin shell from my build script, to run
the same 3 commands with the -lc option to sh.exe (same command line),
something happens and the build commands no longer work like in the
real mintty terminal. Then my build fails.

I believe there is something in the cygwin shell session or
environment that I do not know how to set right when invoking
$(CYGWIN_DIR)/bin/sh from my CMake script.

Is there a way for me to start a cygwin shell session from the build
script, that is identical to the one that opens in the mintty terminal
from the start menu, and run some commands there ?

I checked the environment variables and umask in the mintty terminal
and in a /bin/sh session that I launch, they are the same in both
cases. I tried using /bin/sh, /bin/bash, /bin/dash, with both --login
and -c options. But the automated build always fails, and the manual
build works.

Thank you,
Timothy Madden

--
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: interactive hg (mercurial) using ssh is getting "authentication failures" to sourceforge

[Andrey Repin]

Greetings, Ernie Rael!

> At the end of this post, there is experimental evidence that the ssh is
> disasociated from the tty in the when spawned by hg.

> NOTE: hg is a Win7 command, not compiled with the cygwin dll.

Don't you see anything suspicious here?


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 12.05.2014, <15:20>

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: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Houder]

> At my place I have installed both versions of Cygwin (i.e. 32-bits and 
> 64-bits) -- of course,
> in different places.  As "some" of you will have the "same" setup, I would 
> like you to confirm
> the following (UNexpected, to me) result:
>
>  - I canNOT invoke regedit from 64-bits bash (Yes, I can if bash has been 
> invoked in ELEVATED mode)
>  - I can invoke regedit from 64-bits bash (not elevated) as follows: cygstart 
> regedit
>  - however, I can invoke regedit from 32-bits bash (not elevated) ...
>  - likewise, I can invoke regedit from 64-bits cmd (not elevated) ...
>
> By UNexpected result I mean: I cannot explain why I canNOT invoke regedit 
> from 64-bits bash ...
>
> My installation in general:
>
>  - stand-alone installation (i.e. not connected to a domain)
>  - standard passwd and group files
>  - nsswitch.conf: passwd: file, group: files, db_enum: files

Hi Chris,

Thanks for the input!

Of course, it is not really a problem, that regedit cannot be invoked from 
Cygwin, as it can
be invoked from the Windows interface ...

However, in some of the "harder" cases of using Gygwin, one needs to have a 
"mental" model of
how Cygwin "integrates" with Windows (is my belief) ... and as far I understand 
the matter, I
was surprised to find that I could not invoke regedit from bash.

Consequently, I decided to investigate why I got the denial (64-bits Cygwin) at 
my end.

First of all, some more info about my "environment":

 - I am using Cygwin from Windows 7 ...
 - I am using Cygwin from an administrative account ...
 - furthermore, using secpol.msc, I have set the ConsentPromptBehaviorAdmin 
field in

   HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System (key in 
registry)

   to zero, meaning 'elevate without prompting'
   (default: 5, meaning 'prompt for consent for non-Windows binaries)

Note: secpol.msc: security settings > local policies > security options > User 
Account Control: \
Behavior of the elevation prompt for administrators in Admin Approval Mode

As result of doing that, I am still able to "elevate" using a Standard User 
Account (as far as I
can remember), while am I able to "elevate" using the Administrative Account 
without being asked
for consent ...

Back to the issue I started with (back to my investigation).

Using the event viewer (Windows), I have been able to "connect" the denial, 
reported by 64-bits
bash, with error 'ERROR_ELEVATION_REQUIRED'.

Note: event viewer: applications and services logs > microsoft > windows > uac 
> operational

Each time I got the denial, an entry was being added to this particular log.

Searching the internet, it got the understanding, that this (new) error value 
is not handled as it
should be handled ... as far as I understand, the user should be (normally) be 
asked for consent.

Not handled correctly where? 64-bits bash? 64-bits Cygwin? I cannot tell.

Strangely enough, all of the following invocations of regedit were succesful at 
my place:

64-@@ cmd /c 'c:\Windows\regedit'
64-@@ cygstart /drv/c/Windows/regedit
64-@@ /drv/e/Cygwin/bin/bash -c /drv/c/Windows/regedit

Note:
 - in all of the above cases, 64-bits regedit is being invoked
 - specifying /drv/c/Windows/SysWOW64/regedit invokes 32-bits regedit 
(successful)
 - and, as I reported before, regedit can be invoked as "usual" from 64-bits 
bash if bash has been
   "elevated"

Btw, using a Standard User Account, regedit can be invoked from 64-bits bash as 
"usual" ...

As you will notice, invocation of regedit using cygstart (from 64-bit bash) 
does NOT fail. As far
as I know, cygstart makes use of the "ShellExecute" API i.s.o. the 
"CreateProcess ?" API ...
Searching the internet again, it was suggested to me, that the "ShellExecute" 
API, different from
the other API I mentioned above, takes "appropriate" action in case of 
ERROR_ELEVATION_REQUIRED.

Another issue you might run into ...

I was surprised to find, that 32-bits bash reported /drv/c/Windows/regedit.exe 
as a different file,
compared to what 64-bits bash reported.

Note: 32-bits cmd and 64-bits cmd report c:/Windows/regedit.exe as the SAME 
file. Which, of course,
made me wonder ...

Searching the internet again, I got the understanding, that there has been been 
a time in which a
request for c:/Windows/regedit.exe was redirected to 
c:/Windows/SysWOW64/regedit.exe (in case of a
32-bits application).

As far as I can tell, this redirection no longer applies (meaning, as far as 
can tell, MS changed
its mind here).

My findings and questions in a nutshell:

 - by "default" 64-bits regedit is succesfully invoked from 64-bits cmd, and 
32-bits regedit from
   32-bits cmd.
 - both 32-bits cmd and 64-bits cmd list the 64-bits regedit in c:/Windows

 - ... basically, "by default" the same should happen if regedit is invoked 
from bash ...
- why does "64-bits Cygwin" (bash?) fail on the invocation of regedit?
 - 32-bits Cygwin (using bash) shows a "32-bits" regedit in /drv/c/Windows
- does "32-bits Cyg

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Andrey Repin]

Greetings, Houder!

> Another issue you might run into ...

> I was surprised to find, that 32-bits bash reported 
> /drv/c/Windows/regedit.exe as a different file,
> compared to what 64-bits bash reported.

No surprise here. To reach 64-bit regedit (and other utilities) from 32-bit
application, you have to address it through %SystemRoot%\Sysnative path.

> Note: 32-bits cmd and 64-bits cmd report c:/Windows/regedit.exe as the SAME
> file. Which, of course, made me wonder ...

I wonder, how do you check that?

> Searching the internet again, I got the understanding, that there has been
> been a time in which a request for c:/Windows/regedit.exe was redirected to
> c:/Windows/SysWOW64/regedit.exe (in case of a 32-bits application).

> As far as I can tell, this redirection no longer applies (meaning, as far as
> can tell, MS changed its mind here).

How did you found that?


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 12.05.2014, <16:34>

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: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Corinna Vinschen]

On May 12 14:20, Houder wrote:
> Of course, it is not really a problem, that regedit cannot be invoked from 
> Cygwin, as it can
> be invoked from the Windows interface ...
> 
> However, in some of the "harder" cases of using Gygwin, one needs to have a 
> "mental" model of
> how Cygwin "integrates" with Windows (is my belief) ... and as far I 
> understand the matter, I
> was surprised to find that I could not invoke regedit from bash.
> 
> Consequently, I decided to investigate why I got the denial (64-bits Cygwin) 
> at my end.
> 
> First of all, some more info about my "environment":
> 
>  - I am using Cygwin from Windows 7 ...
>  - I am using Cygwin from an administrative account ...
>  - furthermore, using secpol.msc, I have set the ConsentPromptBehaviorAdmin 
> field in
> 
>HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System (key in 
> registry)
> 
>to zero, meaning 'elevate without prompting'

Doesn't matter.  The problem is that elevating is a special procedure,
requiring a special form of ShellExecuteEx function, which doesn't
integrate well with the requirements of POSIX fork/exec.  Therefore
Cygwin never calls ShellExecuteEx to fork/exec an application, rather it
calls CreateProcess/CreateProcessAsUser, both of which don't provide a
way to elevate a process.  Therefore, to elevate a process from a Cygwin
shell, the shell must already run elevated (e.g., right click on "Cygwin
Terminal" -> "Run as Administrator...").

What's really annoying:  RegEdit's mainfest does not request "asAdmin"
rights.  Rather it only requests "MaximumAllowed".  One would think this
means that a CreateProcess call would simply continue with the current
permissions of the user.  Not so, unfortunately.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgp6gthqUWebm.pgp
Description: PGP signature

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Shaddy Baddah]

Hi,

On 2014-05-12 22:50+1000, Corinna Vinschen wrote:

On May 12 14:20, Houder wrote:

Of course, it is not really a problem, that regedit cannot be invoked from 
Cygwin, as it can
be invoked from the Windows interface ...

However, in some of the "harder" cases of using Gygwin, one needs to have a 
"mental" model of
how Cygwin "integrates" with Windows (is my belief) ... and as far I understand 
the matter, I
was surprised to find that I could not invoke regedit from bash.

Consequently, I decided to investigate why I got the denial (64-bits Cygwin) at 
my end.

First of all, some more info about my "environment":

  - I am using Cygwin from Windows 7 ...
  - I am using Cygwin from an administrative account ...
  - furthermore, using secpol.msc, I have set the ConsentPromptBehaviorAdmin 
field in

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System (key in 
registry)

to zero, meaning 'elevate without prompting'


Doesn't matter.  The problem is that elevating is a special procedure,
requiring a special form of ShellExecuteEx function, which doesn't
integrate well with the requirements of POSIX fork/exec.  Therefore
Cygwin never calls ShellExecuteEx to fork/exec an application, rather it
calls CreateProcess/CreateProcessAsUser, both of which don't provide a
way to elevate a process.  Therefore, to elevate a process from a Cygwin
shell, the shell must already run elevated (e.g., right click on "Cygwin
Terminal" -> "Run as Administrator...").

What's really annoying:  RegEdit's mainfest does not request "asAdmin"
rights.  Rather it only requests "MaximumAllowed".  One would think this
means that a CreateProcess call would simply continue with the current
permissions of the user.  Not so, unfortunately.


I am not sure which Edition it started in, but I believe regedit opens
as the invoking user from Windows 8.1 at least (perhaps 8, I have a
vague recollection).

--
Regards,
Shaddy


--
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: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Corinna Vinschen]

On May 12 23:00, Shaddy Baddah wrote:
> On 2014-05-12 22:50+1000, Corinna Vinschen wrote:
> >On May 12 14:20, Houder wrote:
> >>  - furthermore, using secpol.msc, I have set the 
> >> ConsentPromptBehaviorAdmin field in
> >>
> >>HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System (key in 
> >> registry)
> >>
> >>to zero, meaning 'elevate without prompting'
> >
> >Doesn't matter.  The problem is that elevating is a special procedure,
> >requiring a special form of ShellExecuteEx function, which doesn't
> >integrate well with the requirements of POSIX fork/exec.  Therefore
> >Cygwin never calls ShellExecuteEx to fork/exec an application, rather it
> >calls CreateProcess/CreateProcessAsUser, both of which don't provide a
> >way to elevate a process.  Therefore, to elevate a process from a Cygwin
> >shell, the shell must already run elevated (e.g., right click on "Cygwin
> >Terminal" -> "Run as Administrator...").
> >
> >What's really annoying:  RegEdit's mainfest does not request "asAdmin"
> >rights.  Rather it only requests "MaximumAllowed".  One would think this
> >means that a CreateProcess call would simply continue with the current
> >permissions of the user.  Not so, unfortunately.
> 
> I am not sure which Edition it started in, but I believe regedit opens
> as the invoking user from Windows 8.1 at least (perhaps 8, I have a
> vague recollection).

Not on my Windows 8.1.  Here's the excerpt from regedit's manifest:

  "\r\n"
  "\r\n"
  "\r\n"
  "\r\n"
  "\r\n"
  "\r\n"
  "\r\n"

Ok, so it's called "highestAvailable", not "MaximumAllowed", but you
get the idea.  If I call regedit from the non-elevated command line
I get:

  $ regedit
  /cygdrive/c/WINDOWS/regedit: Permission denied.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgp2uIbhySLVC.pgp
Description: PGP signature

Re: interactive hg (mercurial) using ssh is getting "authentication failures" to sourceforge

[Ernie Rael]

On 5/12/2014 4:20 AM, Andrey Repin wrote:

Greetings, Ernie Rael!


At the end of this post, there is experimental evidence that the ssh is
disasociated from the tty in the when spawned by hg.
NOTE: hg is a Win7 command, not compiled with the cygwin dll.

Don't you see anything suspicious here?

Right you are. After I posted, I realized I hadn't clearly stated my 
questions. This could be something about my setup, but... I've only just 
joined this mailing list; I don't have an historical perspective.


Is this expected behavior? If so, any idea what changed over the last 6 
- 9 months? Was this a conscious change in behavior?


I'd been using this setup for years; the old behavior, which gives a 
higher degree of interoperability (at least in this case), is certainly 
natural. If the Win program didn't do anything explicit to disassociate 
from the tty, why shouldn't it work? Does windows have a concept of 
controlling tty? Is there something mercurial/python could, as a native 
app, that would get this to work?


I know little about windows' internals. I understand that even though it 
used to work, that it may have been a 'fortunate" accident.


-ernie

--
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: Update CoreUtils

[Eric Blake]

On 05/11/2014 10:42 AM, Steven Penny wrote:
> current Cygwin version is 8.15
> http://cygwin.com/packages/x86_64/coreutils
> 
> 8.16 was released over 2 years ago
> http://ftp.gnu.org/gnu/coreutils
> 
> MSYS2 is already using 8.22
> http://github.com/Alexpux/MSYS2-packages/blob/master/coreutils/PKGBUILD
> 
> Can we get an update? I can create a build if needed.

I haven't relinquished maintainership of this package yet.  It's still
on my list of things to build, when I get a moment (although free time
has been a bit sparse as of late with the birth of my daughter last month).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Update CoreUtils

[Eric Blake]

On 05/11/2014 01:10 PM, Thomas Wolff wrote:
> 
> Am 11.05.2014 18:42, schrieb Steven Penny:
>> current Cygwin version is 8.15
>> http://cygwin.com/packages/x86_64/coreutils
>>
>> 8.16 was released over 2 years ago
>> http://ftp.gnu.org/gnu/coreutils
>>
>> MSYS2 is already using 8.22
>> http://github.com/Alexpux/MSYS2-packages/blob/master/coreutils/PKGBUILD
>>
>> Can we get an update? I can create a build if needed.
> The current version of `expand` is not UTF-8 aware (and thus garbles
> output).
> If that's fixed upstream (which I don't know), I would strongly
> appreciate an update, too.

Upstream does not handle multibyte locales very well.  It is a much
bigger problem than just expand, and while some distros like Fedora have
provided downstream hacks that attempt to provide UTF-8, I am not very
willing to port them to cygwin if they aren't in a shape to push
upstream first (particularly since cygwin's wchar_t is a different width
than glibc, and therefore the downstream patches for Linux may fail to
work on cygwin without a lot of tweaking).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

screen on 64-bit mangles mintty/buffer

[Shaddy Baddah]

Hi,

This is a problem that I noticed some time last year, so I apologise for
sitting on it for so long. I actually started drafting a number of
emails to report but never committed.

The problem only occurs with screen on 64-bit Cygwin. The 32-bit appears
to work correctly. The problem is that when screen is run in mintty, it
seems to exclude the bottom line, reducing the actual size of the
buffer. Further, something goes awry at the top. So that if you run
emacs -nw or less from within, scrolling via the keys acts very
strangely.

If you detach or simply exit the screen session, the problem carries on
on the mintty you are left with.

You can resolve this by resizing the window (and back). Everything then
returns to normal.

It is interesting to me that the problem also occurs if I ssh into the
64-bit Cygwin install via Putty. However, the problem only occurs from
within the screen session. When you detach or exit, the original Putty
session/buffer is uncorrupted.

My foolishness in not reporting this as soon as I detected it is that
my attempts to bisect/rollback to a period where my recollection
suggests the problem did not exist, have not succeeded. In other words,
my tests indicate this has been around since screen was built and
released for 64-bit Cygwin.

I was hoping to understand the terminal handling and suggest a fix, but
it is a little bit beyond my capability at the moment. Any help would
be appreciated (I usually quarantine one mintty which I use for managing
a handful of screen sessions to work around the problem).

--
Regards,
Shaddy

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

Has anyone built Linux Firefox on cygwin?

[tednolan]

I would like to have a "native" X11 cygwin Firefox.  Has anyone been able
to build this?

As I recall, it was a bear to build even under Linux, and when I started
trying to do it under cygwin a few months ago I went down a rathole
somewhere and never did get anything working before I had to move on.

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

Re: screen on 64-bit mangles mintty/buffer

[Corinna Vinschen]

On May 13 00:57, Shaddy Baddah wrote:
> Hi,
> 
> This is a problem that I noticed some time last year, so I apologise for
> sitting on it for so long. I actually started drafting a number of
> emails to report but never committed.
> 
> The problem only occurs with screen on 64-bit Cygwin. The 32-bit appears
> to work correctly. The problem is that when screen is run in mintty, it
> seems to exclude the bottom line, reducing the actual size of the
> buffer. Further, something goes awry at the top. So that if you run
> emacs -nw or less from within, scrolling via the keys acts very
> strangely.
> 
> If you detach or simply exit the screen session, the problem carries on
> on the mintty you are left with.

This sounds like a mintty issue, not a Cygwin DLL issue.  The Cygwin DLL
only provides the pseudo tty communication channel.  The interpretation
of the escape sequences is done in the terminal emulator.

Unfortunately I have not read anything from the mintty maintainer, Andy
Koppe, since mid-2013, neither here nor on the mintty mailing list.
There was also no upstream mintty release since April 2013.  I have
tried to contact Andy a couple of days ago but didn't get a reply yet.
I hope he's well.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpEXyKFWbIhP.pgp
Description: PGP signature

Re: Has Lucida Console disappeared?

[Warren Young]

On 5/12/2014 08:37, Doug Lewan wrote:


Since updating Cygwin on Friday I (i.e. emacs, etc.) don't find the
Lucida Console fonts.

Have they really disappeared?

And how would I verify their removal? I can find lots of information
about packages currently installed, but nothing more historical.


As far as I know, Lucida Console does not come with any Cygwin package, 
it is part of Windows, up through Windows XP.  It is not a free font:


http://www.microsoft.com/typography/fonts/font.aspx?FMID=1262

From Vista (?) forward, Windows uses Consolas for that purpose.

Sometimes to get native fonts to work in Cygwin apps, you have to build 
font files, which may not have been done in your new installation.  The 
assumption here is that you're talking about Emacs on X11, not console 
emacs in MinTTY.


If MinTTY can't find the font, check in Notepad or similar.  If Lucida 
Console isn't there, either, Cygwin's setup.exe probably didn't remove 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: screen on 64-bit mangles mintty/buffer

[Andrew Schulman]

Hi Shaddy.

> Hi,
> 
> This is a problem that I noticed some time last year, so I apologise for
> sitting on it for so long. I actually started drafting a number of
> emails to report but never committed.
> 
> The problem only occurs with screen on 64-bit Cygwin. The 32-bit appears
> to work correctly. The problem is that when screen is run in mintty, it
> seems to exclude the bottom line, reducing the actual size of the
> buffer. Further, something goes awry at the top. So that if you run
> emacs -nw or less from within, scrolling via the keys acts very
> strangely.
> 
> If you detach or simply exit the screen session, the problem carries on
> on the mintty you are left with.
> 
> You can resolve this by resizing the window (and back). Everything then
> returns to normal.
> 
> It is interesting to me that the problem also occurs if I ssh into the
> 64-bit Cygwin install via Putty. However, the problem only occurs from
> within the screen session. When you detach or exit, the original Putty
> session/buffer is uncorrupted.

OK.  This sounds like the same problem as:  

http://cygwin.com/ml/cygwin/2014-01/msg00223.html

Actually that report is sort of the opposite problem:  all of the
scrolling is down in the bottom line.  But it sure sounds like the same
thing.

The details of what people report vary.  For me, scrolling ends up all
down in the bottom line, and resizing the window doesn't fix it.

I also see the problem only in 64-bit.  It works fine in 32-bit.

I have found one reliable workaround, at least for me:  The problem only
happens if I start screen from my .bash_profile.  If I start it from the
command line, it works fine.  I don't know yet why that is, but it's a
clue.  Probably an environment difference.

Are you using the latest screen release, 4.2.1?  Please send output of
cygcheck -svr.

> My foolishness in not reporting this as soon as I detected it is that
> my attempts to bisect/rollback to a period where my recollection
> suggests the problem did not exist, have not succeeded. In other words,
> my tests indicate this has been around since screen was built and
> released for 64-bit Cygwin.
> 
> I was hoping to understand the terminal handling and suggest a fix, but
> it is a little bit beyond my capability at the moment. Any help would
> be appreciated (I usually quarantine one mintty which I use for managing
> a handful of screen sessions to work around the problem).

No problem, thanks for reporting.  Corinna suggests that it's a mintty
problem.  Is that more likely than a screen problem?  I don't know.  If
it is a screen problem, I don't have the skills to offer a fix - all I
can do is report it to the screen-users list.

Andrew


--
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: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Houder]

Hi Andrey,

>> Another issue you might run into ...
>
>> I was surprised to find, that 32-bits bash reported 
>> /drv/c/Windows/regedit.exe as a different file,
>> compared to what 64-bits bash reported.
>
> No surprise here. To reach 64-bit regedit (and other utilities) from 32-bit
> application, you have to address it through %SystemRoot%\Sysnative path.

Hold on. I wrote '/drv/c/Windows/regedit.exe' (irrespective of its bit-ness).

BUT! See bottom of this message.

>
>> Note: 32-bits cmd and 64-bits cmd report c:/Windows/regedit.exe as the SAME
>> file. Which, of course, made me wonder ...
>
> I wonder, how do you check that?

C:\Users\Henri> dir /tc /4 c:\Windows\regedit.exe   # using 32-bits cmd
 Volume in drive C has no label.
 Volume Serial Number is 12F0-A5C0

 Directory of c:\Windows

14-07-2009  01:27   427.008 regedit.exe

C:\Users\Henri> dir /tc /4 c:\Windows\regedit.exe   # using 64-bits cmd
 Volume in drive C has no label.
 Volume Serial Number is 12F0-A5C0

 Directory of c:\Windows

14-07-2009  01:27   427.008 regedit.exe

Size and date/time of creation are the same.

>> Searching the internet again, I got the understanding, that there has been
>> been a time in which a request for c:/Windows/regedit.exe was redirected to
>> c:/Windows/SysWOW64/regedit.exe (in case of a 32-bits application).
>
>> As far as I can tell, this redirection no longer applies (meaning, as far as
>> can tell, MS changed its mind here).
>
> How did you found that?

For instance, here

http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx

it said
Access to %windir%\regedit.exe is redirected to 
%windir%\SysWOW64\regedit.exe (in case of
32-bits application)

The current situation on my W7 does NOT agree with the above statement.

Henri

-
Here it shows that 32-bits Cygwin "sees" (i.c. ls, stat) a different file at 
/drv/c/Windows ...

Using my 32-bits Cygwin installation (DOS-box, bash) at e:/Cygwin

@@ ls -l /drv/c/Windows/regedit
-rwxrwx---+ 2 TrustedInstaller TrustedInstaller 398336 Jul 14  2009 
/drv/c/Windows/regedit
@@ stat /drv/c/Windows/regedit
  File: `/drv/c/Windows/regedit'
  Size: 398336  Blocks: 392IO Block: 65536  regular file
Device: 12f0a5c0h/317760960dInode: 281474976748756  Links: 2
Access: (0770/-rwxrwx---)  Uid: (4294967294/TrustedInstaller)   Gid: 
(4294967294/TrustedInstaller)
Access: 2009-07-14 01:17:08.803392200 +0200
Modify: 2009-07-14 03:14:30.45700 +0200
Change: 2014-05-11 18:34:40.326326000 +0200
 Birth: 2009-07-14 01:17:08.803392200 +0200

Using my 64-bits Cygwin installation (DOS-box, bash) at e:/Cygwin64:

64-@@ ls -l /drv/c/Windows/regedit
-rwxrwx---+ 2 TrustedInstaller TrustedInstaller 427008 Jul 14  2009 
/drv/c/Windows/regedit
64-@@ stat /drv/c/Windows/regedit
  File: `/drv/c/Windows/regedit'
  Size: 427008  Blocks: 420IO Block: 65536  regular file
Device: 12f0a5c0h/317760960dInode: 281474976726615  Links: 2
Access: (0770/-rwxrwx---)  Uid: (4294967294/TrustedInstaller)   Gid: 
(4294967294/TrustedInstaller)
Access: 2009-07-14 01:27:10.125698800 +0200
Modify: 2009-07-14 03:39:29.63900 +0200
Change: 2014-05-11 18:35:26.892407800 +0200
 Birth: 2009-07-14 01:27:10.125698800 +0200

Note:
 - 32-bits Cygwin invokes 64-bits regedit in case of /drv/c/Windows/regedit
   (yes, different from the one it "sees" (i.c. ls, stat) !
 - 32-bits Cygwin invokes 32-bits regedit in case of 
/drv/c/Windows/SysWOW64/regedit
 - in case of /drv/c/Windows/System32/regedit: dito
 - /drv/c/Windows/SysNative/regedit: does NOT exist!
   (the 64-bits version only lives in c:/Windows)

=


--
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: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Houder]

Hi Corinna,

Thank you for sharing your expert knowledge!

>> Consequently, I decided to investigate why I got the denial (64-bits Cygwin) 
>> at my end.
>>
>> First of all, some more info about my "environment":
>>
>>  - I am using Cygwin from Windows 7 ...
>>  - I am using Cygwin from an administrative account ...
>>  - furthermore, using secpol.msc, I have set the ConsentPromptBehaviorAdmin 
>> field in
>>
>>HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System (key in 
>> registry)
>>
>>to zero, meaning 'elevate without prompting'
>
> Doesn't matter.  The problem is that elevating is a special procedure,
> requiring a special form of ShellExecuteEx function, which doesn't
> integrate well with the requirements of POSIX fork/exec.  Therefore
> Cygwin never calls ShellExecuteEx to fork/exec an application, rather it
> calls CreateProcess/CreateProcessAsUser, both of which don't provide a
> way to elevate a process.  Therefore, to elevate a process from a Cygwin
> shell, the shell must already run elevated (e.g., right click on "Cygwin
> Terminal" -> "Run as Administrator...").
>
> What's really annoying:  RegEdit's mainfest does not request "asAdmin"
> rights.  Rather it only requests "MaximumAllowed".  One would think this
> means that a CreateProcess call would simply continue with the current
> permissions of the user.  Not so, unfortunately.

Interesting! I can assure you that I am UNfamiliar grounds here :-)

But how do you explain, that I can invoke regedit from 32-bits Cygwin, using
an UNelevated bash?
(both /drv/c/Windows/regedit and /drv/c/Windows/SysWOW64/regedit)

(Sorry, I will look into that myself :-)

Henri

-
@ stat_uac
The values of the fields are currently:

 1. ConsentPromptBehaviorAdmin 0x0
 2. ConsentPromptBehaviorUser  0x1
 3. EnableInstallerDetection   0x1
 4. EnableLUA  0x1
 5. EnableSecureUIAPaths   0x1
 6. EnableUIADesktopToggle 0x0
 7. EnableVirtualization   0x0
 8. PromptOnSecureDesktop  0x1
 9. ValidateAdminCodeSignatures0x0
10. FilterAdministratorToken   0x0
@@

=


--
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: Has Lucida Console disappeared?

[Doug Lewan]

Thanks. That would certainly explain things. (I did a Windows brand update 
about the same time.)

,Douglas
Douglas Lewan
Shubert Ticketing
(201) 489-8600 ext 224

LISP: The most intelligent way to misuse a computer.


> -Original Message-
> On
> Behalf Of Warren Young
> Sent: Monday, 2014 May 12 12:39
> To: Cygwin-L
> Subject: Re: Has Lucida Console disappeared?
> 
> On 5/12/2014 08:37, Doug Lewan wrote:
> >
> > Since updating Cygwin on Friday I (i.e. emacs, etc.) don't find the
> > Lucida Console fonts.
> >
> 
> As far as I know, Lucida Console does not come with any Cygwin package,
> it is part of Windows, up through Windows XP.  It is not a free font:
> 
>  http://www.microsoft.com/typography/fonts/font.aspx?FMID=1262
> 
>  From Vista (?) forward, Windows uses Consolas for that purpose.
> 


--
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: Has Lucida Console disappeared?

[Ken Brown]

On 5/12/2014 10:37 AM, Doug Lewan wrote:

Hi,

Since updating Cygwin on Friday I (i.e. emacs, etc.) don't find the Lucida 
Console fonts.


If you're trying to use Windows fonts within emacs-X11, that temporarily 
doesn't work because of a recent change in the fontconfig package:


  http://cygwin.com/ml/cygwin-xfree/2014-05/msg9.html

You will be able to do it again as soon as Yaakov releases the new 
package he mentions in the above announcement.


Ken

--
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: interactive hg (mercurial) using ssh is getting "authentication failures" to sourceforge

[Larry Hall (Cygwin)]

On 05/12/2014 09:21 AM, Ernie Rael wrote:

On 5/12/2014 4:20 AM, Andrey Repin wrote:

Greetings, Ernie Rael!


At the end of this post, there is experimental evidence that the ssh is
disasociated from the tty in the when spawned by hg.
NOTE: hg is a Win7 command, not compiled with the cygwin dll.

Don't you see anything suspicious here?


Right you are. After I posted, I realized I hadn't clearly stated my
questions. This could be something about my setup, but... I've only just
joined this mailing list; I don't have an historical perspective.

Is this expected behavior? If so, any idea what changed over the last 6 - 9
months? Was this a conscious change in behavior?

I'd been using this setup for years; the old behavior, which gives a higher
degree of interoperability (at least in this case), is certainly natural. If
the Win program didn't do anything explicit to disassociate from the tty,
why shouldn't it work? Does windows have a concept of controlling tty? Is
there something mercurial/python could, as a native app, that would get this
to work?

I know little about windows' internals. I understand that even though it
used to work, that it may have been a 'fortunate" accident.


I believe the point that Andrey's making is that 'hg' being a Windows
native app is significant in your workflow.  When you wander into the
area that involves ttys, there are more restrictions on what will work.
Windows doesn't have ttys and Cygwin emulates them.  Mixing tools
which don't understand ttys with those that emulate them is not a
recipe for success, even if things work OK in some situations.  Your
simplest route to a solution may be to just use the Cygwin version
of 'hg'.


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Houder]

Hi Shaddy,

> I am not sure which Edition it started in, but I believe regedit opens
> as the invoking user from Windows 8.1 at least (perhaps 8, I have a
> vague recollection).

Once more, for everyone's benefit :-)

Using _MY_ W7 (ConsentPromptBehaviorAdmin field set to zero) ...

 = Using "my" administrator account

 - from 32-bits cmd (unelevated): regedit opens
 - from 64-bits cmd (unelevated): dito

 - from 32-bits bash (unelevated): dito
 - from 64-bits bash (unelevated): execution denied <
 - from 64-bits bash (elevated): regedit opens

 = Using an standard user account

 - regedit opens in all cases (w/o requiring consent)

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

Re: How do start a cygwin shell session from a script ?

[Larry Hall (Cygwin)]

On 05/12/2014 06:12 AM, Timothy Madden wrote:

Hello

I have a CMake build script for my application, that among other
things tries to build libvpx (open-source video codec, see
webmproject.org).

libvpx library v1.3.0 compiles fine by hand when I open a cygwin
terminal from the Windows start menu and type in the needed
`configure`; `make` and `make install` commands.

But when I try to invoke the cygwin shell from my build script, to run
the same 3 commands with the -lc option to sh.exe (same command line),
something happens and the build commands no longer work like in the
real mintty terminal. Then my build fails.

I believe there is something in the cygwin shell session or
environment that I do not know how to set right when invoking
$(CYGWIN_DIR)/bin/sh from my CMake script.

Is there a way for me to start a cygwin shell session from the build
script, that is identical to the one that opens in the mintty terminal
from the start menu, and run some commands there ?

I checked the environment variables and umask in the mintty terminal
and in a /bin/sh session that I launch, they are the same in both
cases. I tried using /bin/sh, /bin/bash, /bin/dash, with both --login
and -c options. But the automated build always fails, and the manual
build works.


What's the error and from where?

I think you are on the right track to look at environment differences.
If you're sure there are no longer any differences between the sessions
invoked through CMake and manually, I'd suspect something surrounding
CMake.  Do you have the same problem using Cygwin's CMake?


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Has Lucida Console disappeared?

[Doug Lewan]

Ken,

Yet another reasonable element in the picture. Thanks!

,Douglas
Douglas Lewan
Shubert Ticketing
(201) 489-8600 ext 224

LISP: The most intelligent way to misuse a computer.


> -Original Message-
> On
> Behalf Of Ken Brown
> Sent: Monday, 2014 May 12 14:12
> Subject: Re: Has Lucida Console disappeared?
> 
> 
> If you're trying to use Windows fonts within emacs-X11, that
> temporarily
> doesn't work because of a recent change in the fontconfig package:
> 
>http://cygwin.com/ml/cygwin-xfree/2014-05/msg9.html
> 
> You will be able to do it again as soon as Yaakov releases the new
> package he mentions in the above announcement.
> 
> Ken


--
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: Update CoreUtils

[Steven Penny]

On Mon, May 12, 2014 at 9:52 AM, Eric Blake wrote:
> I haven't relinquished maintainership of this package yet.  It's still
> on my list of things to build, when I get a moment (although free time
> has been a bit sparse as of late with the birth of my daughter last month).

Frankly I dont see how you can hold maintainer and not even update once a year.
Between

- coreutils
- bash
- git
- lack of a real package manager

all being way out of date I have already switched to MSYS2 once. The only reason
I came back is they still havent fixed the jacked mount points

C:/msys64 on /usr
C:/msys64 on /

while Cygwin correctly does

C:/cygwin64/bin on /usr/bin
C:/cygwin64/lib on /usr/lib
C:/cygwin64 on /

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

[ANNOUNCEMENT] Updated: stunnel 5.01-1, 4.56-2

[Andrew Schulman]

A new version of stunnel, 5.01-1, is available in the Cygwin
distribution.  This is a new upstream release.

A new Cygwin release of the previous version, 4.56-2, is also available.
This release has no source or packaging changes, but the package has
been rebuilt against OpenSSL 1.0.1g, for those who want to continue
using the previous version.

Stunnel is a program that allows you to encrypt arbitrary TCP
connections inside SSL (Secure Sockets Layer). Stunnel can allow you to
secure non-SSL aware daemons and protocols (like POP, IMAP, LDAP, etc)
by having Stunnel provide the encryption, requiring no changes to the
daemon's code.

Andrew E. Schulman


***


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com_at_cygwin.com

If you need more information on unsubscribing, start reading here: 

http://cygwin.com/lists.html#subscribe-unsubscribe

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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: gnuplot caca terminal work on Cygwin-x86 but not Cygwin-x86_64

[Tatsuro MATSUOKA]

--- On Mon, 2014/5/12, Corinna Vinschen  wrote:

> On May 12 16:51, Tatsuro MATSUOKA wrote:
> > I have downdoaded x86_64/cygwin1-20140509.dll.xz and execute gnuplot on gdb
> 
> First, are you shure this is running under the snapshot?  what does
> `uname -a' print when called right before the below gdb call?
> 
> > $ gdb src/gnuplot
> > 
> > Reading symbols from 
> > /cygdrive/e/usr/Tatsu/cyg64work/gnuplotcvs/build/src/gnuplot...done.
> > (gdb) r
> > Starting program: 
> > /cygdrive/e/usr/Tatsu/cyg64work/gnuplotcvs/build/src/gnuplot
> > [New Thread 9176.0x2614]
> > [New Thread 9176.0x1494]
> > 
> >         G N U P L O T
> >         Version 5.0 patchlevel alpha    last modified 2014-05-11
> > 
> >         Copyright (C) 1986-1993, 1998, 2004, 2007-2014
> >         Thomas Williams, Colin Kelley and many others
> > 
> >         gnuplot home:     http://www.gnuplot.info
> >         mailing list:     gnuplot-b...@lists.sourceforge.net
> >         faq, bugs, etc:   type "help FAQ"
> >         immediate help:   type "help"  (plot window: hit 'h')
> > 
> > Terminal type set to 'qt'
> > gnuplot> plot sin(x)
> > [New Thread 9176.0x1b50]
> > [New Thread 9176.0x269c]
> > [New Thread 9176.0x2780]
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x7782a5a0 in vsprintf_s () from 
> > /cygdrive/c/Windows/system32/ntdll.dll
> > (gdb) bt
> > #0  0x7782a5a0 in vsprintf_s ()
> >    from /cygdrive/c/Windows/system32/ntdll.dll
> > 
> > Is this information helpful?
> 

> First, are you shure this is running under the snapshot?  what does
> `uname -a' print when called right before the below gdb call?

I have mis-operated. I have copied snapshot cywin1.dll to Cygwin_x86 but not 
Cygwin_x86_64.  I corrected makatake and found :

$ gdb src/gnuplot
GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
..
Reading symbols from 
/cygdrive/e/usr/Tatsu/cyg64work/gnuplotcvs/build/src/gnuplot...done.
(gdb) r
Starting program: /cygdrive/e/usr/Tatsu/cyg64work/gnuplotcvs/build/src/gnuplot
[New Thread 5892.0x478]
warning: the debug information found in "/usr/lib/debug//usr/bin/cygwin1.dbg" 
does not match "/usr/bin/cygwin1.dll" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/usr/bin/cygwin1.dbg" 
does not match "/usr/bin/cygwin1.dll" (CRC mismatch).

[New Thread 5892.0x788]
[New Thread 5892.0xc1c]

G N U P L O T
Version 5.0 patchlevel alphalast modified 2014-05-11

Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others

gnuplot home: http://www.gnuplot.info
mailing list: gnuplot-b...@lists.sourceforge.net
faq, bugs, etc:   type "help FAQ"
immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot> plot sin(x)
[New Thread 5892.0xba4]
[New Thread 5892.0x41c]
[New Thread 5892.0x142c]
[New Thread 5892.0x10ec]
[Thread 5892.0x10ec exited with code 0]
[New Thread 5892.0xae0]
[New Thread 5892.0x1a68]
[New Thread 5892.0x1bf0]
Could not connect to gnuplot_qt "qtgnuplot3112" . Starting a new one

Warning: slow font initializationgnuplot> Quit
(gdb) Undefined command: "rq".  Try "help".
(gdb) Undefined command: "q2".  Try "help".
(gdb) A debugging session is active.


Segmentation fault is no longer happned.
The behavior similar to that happened at Cygwin_x86.

Anyway thanks your advise.

# On Ubuntu 12.04 LTS 64bit, gnuplot qt terminal works without problem.

Regards

Tatsuro


--
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: hostname: : Bad address apprers on Cygwin_x86_64

[Tatsuro MATSUOKA]

--- On Mon, 2014/5/12, Marco Atzeri  wrote:
> On 12/05/2014 11:35, Tatsuro MATSUOKA wrote:
> > Hello
> >
> > Executing Cygwin.bat on  Cygwin_x86_64, a message "hostname: : Bad address" 
> > before representation of the prompt like:
> >
> > 
> > hostname: : Bad address
> >
> > Tatsu@Tatsu-PC ~
> > $
> > *
> >
> > What is wrong with my system?
> >
> > Tatsuro
> >
> 
> Hi Tatsuro,
> eventually nothing specific of your system.
> Could you trace which command is giving that output ?
> 
> Marco

Hello

I have installed the snapshot of cygwin1.dll () for Cygwin_x86_64 in order to 
debug the gnuplot qt terminal error.
http://cygwin.1069669.n5.nabble.com/gnuplot-caca-terminal-work-on-Cygwin-x86-but-not-Cygwin-x86-64-td108246.html

$ uname -a
CYGWIN_NT-6.1 Tatsu-PC 1.7.30s(0.272/5/3) 20140509 14:29:33 x86_64 Cygwin

Using the snapshot cygwin1.dll, the message "hostname: : Bad address" 
disappeared.

Regards

Tatsuro

--
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: gnuplot caca terminal work on Cygwin-x86 but not Cygwin-x86_64

[Tatsuro MATSUOKA]

Hello

Sorry I am confused. Here is the post concerning with caca terminal but not
qt terminal of gnuplot on Cygwin_x86_64.

$ gdb src/gnuplot
GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)

(gdb) r

[New Thread 1840.0x81c]
[New Thread 1840.0x149c]

G N U P L O T
Version 5.0 patchlevel alphalast modified 2014-05-11 

Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others

gnuplot home: http://www.gnuplot.info
mailing list: gnuplot-b...@lists.sourceforge.net
faq, bugs, etc:   type "help FAQ"
immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot> set term caca
Terminal type set to 'caca'
Options are 'enhanced size 80, 25 background rgb "white" color noinverted t
blocks'
gnuplot> plot sin(x)
[New Thread 1840.0x904]
[Thread 1840.0x904 exited with code 0]
[New Thread 1840.0x1830]
[New Thread 1840.0x1b00]
X Error of failed request:  BadValue (integer parameter out of range for
oon)
  Major opcode of failed request:  1 (X_CreateWindow)
  Value in failed request:  0x0
  Serial number of failed request:  4149
  Current serial number in output stream:  4150
Gnuplot not exited using gp_exit(). Exit handlers may not work correctly!
[Thread 1840.0x81c exited with code 1]
[Thread 1840.0x1830 exited with code 1]
[Thread 1840.0x149c exited with code 1]
[Inferior 1 (process 1840) exited with code 01]
(gdb) bt
No stack.

Any suggestions?




--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/gnuplot-caca-terminal-work-on-Cygwin-x86-but-not-Cygwin-x86-64-tp108246p108567.html
Sent from the Cygwin list mailing list archive at Nabble.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

[ANNOUNCEMENT] Updated: w32api-headers-3.1.0-2

[JonY]

New release for both 32bit and 64bit Cygwin:

w32api-headers-3.1.0-2

This update contains some correction and updates for the GL headers.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the
format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.





signature.asc
Description: OpenPGP digital signature

Re: Update CoreUtils

[Christopher Faylor]

On Mon, May 12, 2014 at 04:33:06PM -0500, Steven Penny wrote:
>On Mon, May 12, 2014 at 9:52 AM, Eric Blake wrote:
>> I haven't relinquished maintainership of this package yet.  It's still
>> on my list of things to build, when I get a moment (although free time
>> has been a bit sparse as of late with the birth of my daughter last month).
>
>Frankly I dont see how you can hold maintainer and not even update once a year.
>Between
>
>- coreutils
>- bash
>- git
>- lack of a real package manager
>
>all being way out of date I have already switched to MSYS2 once. The only 
>reason
>I came back is they still havent fixed the jacked mount points
>
>C:/msys64 on /usr
>C:/msys64 on /
>
>while Cygwin correctly does
>
>C:/cygwin64/bin on /usr/bin
>C:/cygwin64/lib on /usr/lib
>C:/cygwin64 on /

Frankly, please give MSYS2 another try.  We'd all appreciate it.

cgf

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