date:20110523

On May 20 17:09, Yaakov (Cygwin/X) wrote:
 The setup.exe download is still 2.738.  Could it be updated to 2.749
 to include jturney's recent bug fixes?

I'd like to fix the mintty issue first.

So, do we swtch to mintty as default terminal, yes or no?

If we switch to mintty we don't need the Cygwin.bat file anymore.  But,
shouldn't we keep it anyway for people who maintain some handmade symlink
to it?

If so, should we stick to the content of Cygwin.bat as is, or should
we change it to call mintty, too?

And who's going to create the patches?

Last but not least, shouldn't we add mintty to the Base package
anyway, independently of what we do to setup?


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

On 5/23/2011 7:50 AM, Corinna Vinschen wrote:
On May 20 17:09, Yaakov (Cygwin/X) wrote:
The setup.exe download is still 2.738. Could it be updated to 2.749
to include jturney's recent bug fixes?

I'd like to fix the mintty issue first.

So, do we swtch to mintty as default terminal, yes or no?

Uhm, maybe? :-)

Here's the deal: run the following program from the ncurses-demo package:
/usr/lib/ncurses/test/lrtest.exe
in a mintty terminal and bash-in-cmdbox, with the same UTF-8 $LANG
settings (I've tried C.UTF-8 and en_US.UTF-8). FWIW,
TERM=xterm-256color in mintty, and TERM=cygwin in bash-in-cmdbox.

In the former, I see pseudo-line drawing characters (e.g hyphens and
plus signs, etc), but in the latter I see real line draw characters.

Why?

acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,

e.g. the cygwin entry explicitly uses high codepoints for various line
draw stuff, (and cgywin's own terminal handling code does the magic to
replace them with unicode linedraw? or something?)

Now, according to a post from 2004 by T.E. Dickey (ncurses/terminfo
maintainer):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256446

non-wide ncurses relies on the acsc,
wide-curses has a kludge to recognize UTF-8 locales and an internal
table for line-drawing characters.

...which also has a suggested patch for putty, but it's not clear it was
ever adopted.

So...trying the wide variant
/usr/lib/ncursesw/test/lrtest.exe
I get the same behavior as before in mintty (e.g. no linedraw
chars)...so there goes that idea (maybe the 'kludge' has been removed
from libncursesw between 2004 and now).

My point: there are some things that don't yet seem to work right in
mintty, and I'm not really sure where the problem is.

1) does mintty need to do magic linedraw character rewriting,
replacing what APPEAR to be attempts to print line draw chars with
unicode linedraw glyphs? (ugh. heuristics. I hate heuristics. They
always guess wrong sometimes.)
2) do we need an explicit mintty terminfo entry, with a 'better' acsc
entry -- OTOH, it is *NOT* possible to put unicode values in the
terminfo src string, so that's probably a nonstarter, unless combined
with (1). (also: ugh. must propagate the entry to all server OSs to
which you want to ssh...push upstream to ncurses...wait years for
RHEL7.0 to adopt it...)
3) Maybe there is some magic combination of envvar TERM/LANG,
settings, mintty options, font choices, etc, that will make linedraw work?
4) bug (or misconfiguration) in cygwin ncurses- or ncursesw- ?
5) or punt. Who needs linedraw anyway.

I'm ok with #5...but just wanted to bring up the issue so the decision
is an informed one.

If we switch to mintty we don't need the Cygwin.bat file anymore. But,
shouldn't we keep it anyway for people who maintain some handmade symlink
to it?

yes.

If so, should we stick to the content of Cygwin.bat as is, or should
we change it to call mintty, too?

as-is. What if you really WANT to use cmdbox? How else can a
cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
And since that's the only real way to do so, we ought to provide the file.

And who's going to create the patches?

Well, my proposal is a one-liner in setup.exe: just change the target of
the shortcut created in the Start Menu.

Last but not least, shouldn't we add mintty to the Base package
anyway, independently of what we do to setup?

I think so.

However, if we do change setup.exe, then mintty should later be updated
to eliminate its postinstall/preremove scripts. We don't need TWO
shortcuts to the same proggie.

--
Chuck

Re: setup and mintty (was Re: New setup.exe release?)

On May 23 11:33, Charles Wilson wrote:
On 5/23/2011 7:50 AM, Corinna Vinschen wrote:
On May 20 17:09, Yaakov (Cygwin/X) wrote:
The setup.exe download is still 2.738. Could it be updated to 2.749
to include jturney's recent bug fixes?

I'd like to fix the mintty issue first.

So, do we swtch to mintty as default terminal, yes or no?

Uhm, maybe? :-)

In the former, I see pseudo-line drawing characters (e.g hyphens and
plus signs, etc), but in the latter I see real line draw characters.

Why?

acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,

e.g. the cygwin entry explicitly uses high codepoints for various line
draw stuff, (and cgywin's own terminal handling code does the magic to
replace them with unicode linedraw? or something?)

Something. I don't know how mintty works, but the Cygwin console knows
the switch to/from alternate charset command ESC [ 11 m, ESC [ 10
m. The alternate charset is always codepage 437 which has the line
drawing chars at known single-byte positions in the = 128 region.
This is apparently used by ncurses when running in a console window,
but perhaps not when running in mintty.

Whatever that is, I guess it may not be overly tricky to implement in
mintty as well, *if* somebody takes the time to report the problem.

My point: there are some things that don't yet seem to work right in
mintty, and I'm not really sure where the problem is.

What is the difference to the Cygwin console exactly? I'm sure, if you
look a bit below the surface, you will easily find bugs in the Cygwin
console implementation as well. It's all about getting bug reports or
even testcases. Just because there are bugs in mintty and the Cygwin
console doesn't mean both are unusable as default terminal.

Btw., why is it so bad to have ASCII replacement chars? They just
work, even if they look ugly to some people.

2) do we need an explicit mintty terminfo entry, with a 'better' acsc
entry

I don't think so. If at all, it's just some shortcoming in the current
implementation, something which can be fixed or added.

3) Maybe there is some magic combination of envvar TERM/LANG,
settings, mintty options, font choices, etc, that will make linedraw work?

Windows fonts are unicode anyway, and the line drawing chars are
part of the unicode codeset. I guess a translation table from
CP437 to unicode line drawing chars and support of the alternate
charset setting should do it.

If we switch to mintty we don't need the Cygwin.bat file anymore. But,
shouldn't we keep it anyway for people who maintain some handmade symlink
to it?

yes.

If so, should we stick to the content of Cygwin.bat as is, or should
we change it to call mintty, too?

You can simple create a Windows shortcut to bash.exe, edit it to
add a --login option, and that's all you really need.

And who's going to create the patches?

Well, my proposal is a one-liner in setup.exe: just change the target of
the shortcut created in the Start Menu.

I don't think it makes sense if the desktop shortcut and the menu entry
behave differently. The desktop shortcut is the first thing new users
see, and this shortcut should start mintty in the first place. Just
as the menu entry since they should do the same.

Last but not least, shouldn't we add mintty to the Base package
anyway, independently of what we do to setup?

I think so.

However, if we do change setup.exe, then mintty should later be updated
to eliminate its postinstall/preremove scripts. We don't need TWO
shortcuts to the same proggie.

I agree.

Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
On May 23 11:33, Charles Wilson wrote:
 as-is.  What if you really WANT to use cmdbox?  How else can a
 cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
  And since that's the only real way to do so, we ought to provide the file.
^^
Huh?

You can simple create a Windows shortcut to bash.exe, edit it to
add a --login option, and that's all you really need.

I agree, except for people who need to set the CYGWIN environment
variable for some reason.  You have to do that before running bash.

Maybe we should be looking into introducing a way to set the CYGWIN
environment variable in the global environment and adding c:\cygwin\bin
(or whatever) to the global PATH as well.

But, I am extemely in favor of making mintty the default terminal.  It
would present a much nicer end-user experience out-of-the-box even if
some pty stuff doesn't work quite right.

And, I can just imagine the blog entries now: Cygwin finally offers an
intelligent terminal interface - after ten years!

The only downside that I see is that Andy may ask to renegotiate his
contract.  I wouldn't be surprised if he asked to be paid double what
he's getting now, in fact.

cgf

Re: setup and mintty (was Re: New setup.exe release?)

On 5/23/2011 1:25 PM, Christopher Faylor wrote:
 Maybe we should be looking into introducing a way to set the CYGWIN
 environment variable in the global environment and adding c:\cygwin\bin
 (or whatever) to the global PATH as well.

I disagree.  I deliberately keep cygwin paths out of my global PATH, so
that I can switch between various separate cygwin installs, and various
MinGW/MSYS installs, without them all conflicting with each other.

If we DO change setup to muck with global %PATH%, then we need another
checkbox to opt out.  (BTW, whatever happened to that 'check box
persistence' patch?)

 But, I am extemely in favor of making mintty the default terminal.  It
 would present a much nicer end-user experience out-of-the-box even if
 some pty stuff doesn't work quite right.

Oh, sure, I'm not against that. I specifically said #5 was fine with me:
  5) or punt.  Who needs linedraw anyway.
which was my way of saying: sure, go ahead and make mintty the default.
If we really care about linedraw, we can fix it later -- and I wonder if
we really DO care about it.  It sounds like the consensus here is: we
don't care /much/, but PTC...

And that's fine.

 And, I can just imagine the blog entries now: Cygwin finally offers an
 intelligent terminal interface - after ten years!

Yep, that + unicode support is the most obvious user-visible improvement
in the 'new user experience' in a long time.  Maybe even since the
hallowed B19 - B20.1 transition /cue choirs of angels.

Most of the other great improvements aren't immediately obvious to the
new user...

 The only downside that I see is that Andy may ask to renegotiate his
 contract.  I wouldn't be surprised if he asked to be paid double what
 he's getting now, in fact.

Andy needs a tipjar -- and a plug on this page:
http://cygwin.com/donations.html

--
Chuck

Re: setup and mintty (was Re: New setup.exe release?)

On May 23 13:25, Christopher Faylor wrote:
 On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
 On May 23 11:33, Charles Wilson wrote:
  as-is.  What if you really WANT to use cmdbox?  How else can a
  cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
   And since that's the only real way to do so, we ought to provide the file.
 ^^
 Huh?
 
 You can simple create a Windows shortcut to bash.exe, edit it to
 add a --login option, and that's all you really need.
 
 I agree, except for people who need to set the CYGWIN environment
 variable for some reason.  You have to do that before running bash.
 
 Maybe we should be looking into introducing a way to set the CYGWIN
 environment variable in the global environment and adding c:\cygwin\bin
 (or whatever) to the global PATH as well.

I would really like to avoid that.  The question is, which CYGWIN
settings are really needed before an application starts?  Apart from the
debugging the Cygwin DLL scenario, the only one I can think of is the
tty setting, and that's about to go away.

IMHO it would be quite helpful if a setenv (CYGWIN, ...) or putenv
(CYGWIN=...) would change the CYGWIN settings for the calling process
as well.

Apart from that, maybe mintty could provide a CYGWIN environment
variable settings edit text in the properties dialog.

 The only downside that I see is that Andy may ask to renegotiate his
 contract.  I wouldn't be surprised if he asked to be paid double what
 he's getting now, in fact.

Uh oh.


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-23 Thread marco atzeri

On Mon, May 23, 2011 at 8:21 PM, Corinna Vinschen  wrote:
 On May 23 13:25, Christopher Faylor wrote:
 On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
 On May 23 11:33, Charles Wilson wrote:
  as-is.  What if you really WANT to use cmdbox?  How else can a
  cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
   And since that's the only real way to do so, we ought to provide the 
  file.
                     ^^
                     Huh?
 
 You can simple create a Windows shortcut to bash.exe, edit it to
 add a --login option, and that's all you really need.

 I agree, except for people who need to set the CYGWIN environment
 variable for some reason.  You have to do that before running bash.

 Maybe we should be looking into introducing a way to set the CYGWIN
 environment variable in the global environment and adding c:\cygwin\bin
 (or whatever) to the global PATH as well.

 I would really like to avoid that.

same. Different PATHS make me sane and I run cygwin from an external drive
not always connected.

 The question is, which CYGWIN
 settings are really needed before an application starts?  Apart from the
 debugging the Cygwin DLL scenario, the only one I can think of is the
 tty setting, and that's about to go away.

 IMHO it would be quite helpful if a setenv (CYGWIN, ...) or putenv
 (CYGWIN=...) would change the CYGWIN settings for the calling process
 as well.

 Apart from that, maybe mintty could provide a CYGWIN environment
 variable settings edit text in the properties dialog.

 The only downside that I see is that Andy may ask to renegotiate his
 contract.  I wouldn't be surprised if he asked to be paid double what
 he's getting now, in fact.

 Uh oh.


 Corinna

mintty as standard console will simplify a lot our life in supporting users,
so this proposal takes also my vote


Regards
Marco

Re: setup and mintty (was Re: New setup.exe release?)

On Mon, May 23, 2011 at 02:16:42PM -0400, Charles Wilson wrote:
On 5/23/2011 1:25 PM, Christopher Faylor wrote:
 Maybe we should be looking into introducing a way to set the CYGWIN
 environment variable in the global environment and adding c:\cygwin\bin
 (or whatever) to the global PATH as well.

I disagree.  I deliberately keep cygwin paths out of my global PATH, so
that I can switch between various separate cygwin installs, and various
MinGW/MSYS installs, without them all conflicting with each other.

If we DO change setup to muck with global %PATH%, then we need another
checkbox to opt out.

That's what I mean by a way.  I know that people will complain if you
can't opt out but I think most people would like to be able to type
bash in their Search programs and files box and have bash start
automatically.  This would also help squash the myth that you have to
start some sort of magical Cygwin environment to use a Cygwin program
like grep.

(BTW, whatever happened to that 'check box persistence' patch?)

I think I volunteered to make the final check boxes persistent but it is
of such little importance to me that it will probably never get done.  I
don't think there has been another patch presented otherwise.

 And, I can just imagine the blog entries now: Cygwin finally offers an
 intelligent terminal interface - after ten years!

Yep, that + unicode support is the most obvious user-visible improvement
in the 'new user experience' in a long time.  Maybe even since the
hallowed B19 - B20.1 transition /cue choirs of angels.

Most of the other great improvements aren't immediately obvious to the
new user...

The one thing that isn't clear is how this will affect the putty*
users whose blog entries claim this as the only solution to the problem
of the cygwin terminal.  Will this impact them?  I sure hope so.

 The only downside that I see is that Andy may ask to renegotiate his
 contract.  I wouldn't be surprised if he asked to be paid double what
 he's getting now, in fact.

Andy needs a tipjar -- and a plug on this page:
http://cygwin.com/donations.html

I'd be thrilled to add Andy to that page if he wants.  The same goes for
any maintainer.

cgf

Re: setup and mintty (was Re: New setup.exe release?)

On Mon, May 23, 2011 at 08:21:20PM +0200, Corinna Vinschen wrote:
On May 23 13:25, Christopher Faylor wrote:
 On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
 On May 23 11:33, Charles Wilson wrote:
  as-is.  What if you really WANT to use cmdbox?  How else can a
  cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
   And since that's the only real way to do so, we ought to provide the 
  file.
 ^^
 Huh?
 
 You can simple create a Windows shortcut to bash.exe, edit it to
 add a --login option, and that's all you really need.
 
 I agree, except for people who need to set the CYGWIN environment
 variable for some reason.  You have to do that before running bash.
 
 Maybe we should be looking into introducing a way to set the CYGWIN
 environment variable in the global environment and adding c:\cygwin\bin
 (or whatever) to the global PATH as well.

I would really like to avoid that.  The question is, which CYGWIN
settings are really needed before an application starts?  Apart from the
debugging the Cygwin DLL scenario, the only one I can think of is the
tty setting, and that's about to go away.

IMHO it would be quite helpful if a setenv (CYGWIN, ...) or putenv
(CYGWIN=...) would change the CYGWIN settings for the calling process
as well.

Well, unless you make that change, all of the other Cygwin environment
variables (not just tty) need to be set before the first Cygwin
process in a tree is started.  Parsing the CYGWIN environment variable
on the fly is trivial but I don't know for sure if there are some
settings which only work right when set during program initialization.

cgf

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-23 Thread Andy Koppe

On 23 May 2011 17:04, Corinna Vinschen wrote:
On May 23 11:33, Charles Wilson wrote:
Uhm, maybe? :-)

In the former, I see pseudo-line drawing characters (e.g hyphens and
plus signs, etc), but in the latter I see real line draw characters.

Why?

I suspect the reason is the terminfo settings for mintty (e.g. for
xterm-256color) specifies
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
(inherited via terminfo 'use' statements from xterm-basic), while the
terminfo settings for cygwin specify
acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,

e.g. the cygwin entry explicitly uses high codepoints for various line
draw stuff, (and cgywin's own terminal handling code does the magic to
replace them with unicode linedraw? or something?)

Whatever that is, I guess it may not be overly tricky to implement in
mintty as well, *if* somebody takes the time to report the problem.

Mintty does support that already. The feature was introduced by a
certain three-letter PC Unix company, and the Linux console supports
it too.

The DEC vtXXX series did not have that, however, which is why xterm
doesn't either. Instead, they have the DEC Special Character and Line
Drawing Set. When activated, character codes 0x60 to 0x7E map to
those special characters, as shown here:
http://vt100.net/docs/vt102-ug/table5-13.html. Mintty supports that
one too.

My point: there are some things that don't yet seem to work right in
mintty, and I'm not really sure where the problem is.

Chuck, what font are you using in mintty? It could just be that it
doesn't have glyphs for the relevant codepoints, in which case mintty
falls back to ASCII replacements. The default Lucida Console does have
the linedrawing glyphs needed for the vt100 set.

If it's not that, then the xterm terminfo entry would indeed need a closer look.

You can test support for the CP437 alternate charset, the vt100
graphics, and also direct Unicode line drawing by catting the attached
file created by Thomas Wolff.

Andy

xgraphics
Description: Binary data

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-23 Thread Andy Koppe

On 23 May 2011 12:50, Corinna Vinschen wrote:
 On May 20 17:09, Yaakov (Cygwin/X) wrote:
 The setup.exe download is still 2.738.  Could it be updated to 2.749
 to include jturney's recent bug fixes?

 I'd like to fix the mintty issue first.

 So, do we swtch to mintty as default terminal, yes or no?

 If we switch to mintty we don't need the Cygwin.bat file anymore.  But,
 shouldn't we keep it anyway for people who maintain some handmade symlink
 to it?

Yes, I think so.

 If so, should we stick to the content of Cygwin.bat as is, or should
 we change it to call mintty, too?

Better not, so as not to change people's existing setup. And because
it would flash up a console for the .bat.

 And who's going to create the patches?

I suppose that should be me, but my spare time is rather limited at
the moment and I still owe a patch or two for other things.

 Last but not least, shouldn't we add mintty to the Base package
 anyway, independently of what we do to setup?

Seems sensible.

Further all this, if the change to mintty as the default is going
ahead, there's the question of what the desktop shortcut should do and
what it should be called.

What it should do:
1) Invoke the user's default shell as set in /etc/passwd as a login
shell. (This is what the mintty start menu shortcut currently does)
2) Invoke bash as a login shell.

What it should be called:
a) mintty: Few are going to know what that is.
b) Cygwin Bash Shell: That's the current name of course. Not
compatible with option 1 above.
c) Cygwin Shell: Shell-neutral, but encourages the confusion between
terminal and shell.
d) Cygwin Terminal: Linux desktops usually have Terminal entries
in their menus.
e) something else?

I also think the console's start menu entry in the Cygwin folder
should be kept, perhaps with a new name. Console vs Terminal?

Andy

Re: setup and mintty (was Re: New setup.exe release?)

On Mon, May 23, 2011 at 09:14:15PM +0100, Andy Koppe wrote:
What it should be called:
a) mintty: Few are going to know what that is.
b) Cygwin Bash Shell: That's the current name of course. Not
compatible with option 1 above.
c) Cygwin Shell: Shell-neutral, but encourages the confusion between
terminal and shell.
d) Cygwin Terminal: Linux desktops usually have Terminal entries
in their menus.
e) something else?

I also think the console's start menu entry in the Cygwin folder
should be kept, perhaps with a new name. Console vs Terminal?

I think Cygwin Terminal makes sense.  As you say, Linux has something
similar.  Linux doesn't call it Linux Terminal because it doesn't have
to, of course.

cgf

Re: setup and mintty (was Re: New setup.exe release?)

On 5/23/2011 3:42 PM, Andy Koppe wrote:
On 23 May 2011 17:04, Corinna Vinschen wrote:
On May 23 11:33, Charles Wilson wrote:
In the former, I see pseudo-line drawing characters (e.g hyphens and
plus signs, etc), but in the latter I see real line draw characters.

Whatever that is, I guess it may not be overly tricky to implement in
mintty as well, *if* somebody takes the time to report the problem.

Mintty does support that already. The feature was introduced by a
certain three-letter PC Unix company, and the Linux console supports
it too.

Yes, I had thought that you'd put some work in that, which is (one
reason) I was confused.

My point: there are some things that don't yet seem to work right in
mintty, and I'm not really sure where the problem is.

/emily litellaNever mind.
http://www.hulu.com/watch/2364/saturday-night-live-weekend-update-emily-litella-on-violins-on-tv

Yep, works fine with Lucida Console. I was using Consolas, which IMO
looks better...but yep, it appears to be missing the glyphs -- although
rumor has it that MS added the glyphs in their W7 version of this font.
Since I'm running Vista and XP, well... I probably knew that at one
point. Maybe.

If it's not that, then the xterm terminfo entry would indeed need a closer
look.

You can test support for the CP437 alternate charset, the vt100
graphics, and also direct Unicode line drawing by catting the attached
file created by Thomas Wolff.

Neat. Do we have a list of good fonts for mintty, or is it basically
just Lucida Console + Courier New?

Maybe when I get home I'll test out a few...

Consolas
Andale Mono
Courier New
Lucida Console
Vera Sans Mono (or DejaVu LGC Sans)
Droid Sans Mono
Inconsolata
...

--
Chuck

RE: setup and mintty (was Re: New setup.exe release?)

2011-05-23 Thread Buchbinder, Barry (NIH/NIAID) [E]

Christopher Faylor sent the following at Monday, May 23, 2011 1:26 PM
Maybe we should be looking into introducing a way to set the CYGWIN
environment variable in the global environment and adding c:\cygwin\bin
(or whatever) to the global PATH as well.

http://cygwin.com/ml/cygwin/2010-01/msg00977.html

Still Just a suggestion, not a request.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

src/winsup/cygwin ChangeLog fhandler_process.cc

2011-05-23 Thread corinna

CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org  2011-05-23 08:53:25

Modified files:
winsup/cygwin  : ChangeLog fhandler_process.cc 

Log message:
* fhandler_process.cc (thread_info::fill_if_match): Reformat.
(format_process_maps): Ditto.  Fetch pointer to procinfo structure
from mapped process.  Print info about global shared Cygwin regions.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5365r2=1.5366
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_process.cc.diff?cvsroot=srcr1=1.99r2=1.100

src/winsup/mingw ChangeLog include/time.h

2011-05-23 Thread ironhead

CVSROOT:/cvs/src
Module name:src
Changes by: ironh...@sourceware.org 2011-05-23 20:04:12

Modified files:
winsup/mingw   : ChangeLog 
winsup/mingw/include: time.h 

Log message:
2011-05-23  Chris Sutcliffe  ir0nh...@users.sourceforge.net

* include/time.h (daytime, timezone, tzname): Rework guards to expose 
when
compiles with __STRICT_ANSI__.

Thanks to Felipe Contreras for the report.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog.diff?cvsroot=srcr1=1.474r2=1.475
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/mingw/include/time.h.diff?cvsroot=srcr1=1.17r2=1.18

src/winsup/mingw ChangeLog

2011-05-23 Thread ironhead

CVSROOT:/cvs/src
Module name:src
Changes by: ironh...@sourceware.org 2011-05-23 20:10:41

Modified files:
winsup/mingw   : ChangeLog 

Log message:
Fix typo in ChangeLog of previous commit

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog.diff?cvsroot=srcr1=1.475r2=1.476

src/winsup/cygwin ChangeLog errno.cc

2011-05-23 Thread ericb

CVSROOT:/cvs/src
Module name:src
Changes by: er...@sourceware.org2011-05-23 20:43:06

Modified files:
winsup/cygwin  : ChangeLog errno.cc 

Log message:
strerror: match recent glibc changes

* errno.cc (strerror): Print unknown errno as int.
(__xpg_strerror_r): Likewise, and don't clobber strerror buffer.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5366r2=1.5367
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/errno.cc.diff?cvsroot=srcr1=1.82r2=1.83

src/winsup/cygwin ChangeLog cygtls.h

2011-05-23 Thread ericb

CVSROOT:/cvs/src
Module name:src
Changes by: er...@sourceware.org2011-05-23 21:03:06

Modified files:
winsup/cygwin  : ChangeLog cygtls.h 

Log message:
* cygtls.h (strerror_buf): Resize to allow '-'.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5367r2=1.5368
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygtls.h.diff?cvsroot=srcr1=1.69r2=1.70

Re: Improvements to fork handling (2/5)

On May 22 14:42, Ryan Johnson wrote:
 On 21/05/2011 9:44 PM, Christopher Faylor wrote:
 On Wed, May 11, 2011 at 02:31:37PM -0400, Ryan Johnson wrote:
 Hi all,
 
 This patch has the parent sort its dll list topologically by
 dependencies. Previously, attempts to load a DLL_LOAD dll risked pulling
 in dependencies automatically, and the latter would then not benefit
 from the code which encourages them to land in the right places.  The
 dependency tracking is achieved using a simple class which allows to
 introspect a mapped dll image and pull out the dependencies it lists.
 The code currently rebuilds the dependency list at every fork rather
 than attempt to update it properly as modules are loaded and unloaded.
 Note that the topsort optimization affects only cygwin dlls, so any
 windows dlls which are pulled in dynamically (directly or indirectly)
 will still impose the usual risk of address space clobbers.
 This seems CPU and memory intensive during a time for which we already
 know is very slow.  Is the benefit really worth it?  How much more robust
 does it make forking?
 Topological sorting is O(n), so there's no asymptotic change in
 performance. Looking up dependencies inside a dll is *very* cheap
 (2-3 pointer dereferences per dep), and all of this only happens for
 dynamically-loaded dlls. Given the number of calls to
 Virtual{Alloc,Query,Free} and LoadDynamicLibraryEx which we make, I
 would be surprised if the topsort even registered.  That said, it is
 extra work and will slow down fork.
 
 I have not been able to test how much it helps, but it should help
 with the test case Jon Turney reported with python a while back [1].
 In fact, it was that example which made me aware of the potential
 need for a topsort in the first place.
 
 In theory, this should completely eliminate the case where us
 loading one DLL pulls in dependencies automatically (= uncontrolled
 and at Windows' whim). The problem would manifest as a DLL which
 loads in the same wrong place repeatedly when given the choice,
 and for which we would be unable to VirtualAlloc the offending spot
 (because the dll in question has non-zero refcount even after we
 unload it, due to the dll(s) that depend on it. 

There might be a way around this.  It seems to be possible to tweak
the module list the PEB points to so that you can unload a library
even though it has dependencies.  Then you can block the unwanted
space and call LoadLibrary again.  See (*) for a discussion how
you can unload the exe itself to reload another one.  Maybe that's
something we can look into as well.  ObNote:  Of course, if we
could influnce the address at which a DLL gets loaded right from the
start, it would be the preferrable solution.


Corinna

(*) http://www.blizzhackers.cc/viewtopic.php?p=4332690

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

Re: __xpg_strerror_r should not clobber strerror buffer

On 05/21/2011 07:35 PM, Christopher Faylor wrote:
 On Sat, May 21, 2011 at 07:26:37PM -0600, Eric Blake wrote:
 POSIX says that no other function in the standard should clobber the
 strerror buffer.  Our strerror_r is a GNU extension, so it can get away
 with clobbering the buffer (but if we wanted to fix it, we would have to
 separate _my_tls.locals.strerror_buf into two different buffers).
 perror() is still broken, but that needs to be fixed in newlib.  But
 __xpg_strerror_r, which is our POSIX strerror_r variant, has to be fixed
 in cygwin.

 Meanwhile, glibc just patched strerror this week to print negative
 errnum as a negative 32-bit int, rather than as a positive unsigned
 long; cygwin should do likewise.

 2011-05-21  Eric Blake  ebl...@redhat.com

  * errno.cc (strerror): Print unknown errno as int.
  (__xpg_strerror_r): Likewise, and don't clobber strerror buffer.
 
 Looks good.  Please check in.

Pushed.

Just for the record, I'm having a problem self-building cygwin right
now, from what looks like mingw issues:

/home/eblake/src/winsup/utils/mingw gcc-4 -B./ -shared
-Wl,--image-base,0x6FBC -Wl,--entry,_DllMainCRTStartup@12 mthr.o
mthr_init.o mingwthrd.def -Lmingwex -o mingwm10.dll
mingwex/libmingwex.a(strtodnrp.o): In function `strtod':
/home/eblake/src/build/i686-pc-cygwin/winsup/mingw/mingwex/../../../../../winsup/mingw/include/stdlib.h:315:
multiple definition of `_strtod'
...
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
warning: cannot find entry symbol _DllMainCRTStartup@12; defaulting to
6fbc1000
ertr01.o:(.rdata+0x0): undefined reference to
`__pei386_runtime_relocator'
collect2: ld returned 1 exit status
make[3]: *** [mingwm10.dll] Error 1
make[3]: Leaving directory
`/home/eblake/src/build/i686-pc-cygwin/winsup/mingw'

How do we go about getting that resolved?

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: __xpg_strerror_r should not clobber strerror buffer

On 05/23/2011 02:45 PM, Eric Blake wrote:
 On 05/21/2011 07:35 PM, Christopher Faylor wrote:
 On Sat, May 21, 2011 at 07:26:37PM -0600, Eric Blake wrote:
 POSIX says that no other function in the standard should clobber the
 strerror buffer.  Our strerror_r is a GNU extension, so it can get away
 with clobbering the buffer (but if we wanted to fix it, we would have to
 separate _my_tls.locals.strerror_buf into two different buffers).

Shoot.  This introduced an off-by-one buffer overrun.  I'm pushing this
followup.  Meanwhile, do we want a second buffer, so that the GNU
strerror_r won't clobber the strerror buffer?

+++ b/winsup/cygwin/ChangeLog
@@ -2,6 +2,7 @@

* errno.cc (strerror): Print unknown errno as int.
(__xpg_strerror_r): Likewise, and don't clobber strerror buffer.
+   * cygtls.h (strerror_buf): Resize to allow '-'.

 2011-05-23  Corinna Vinschen  cori...@vinschen.de

diff --git a/winsup/cygwin/cygtls.h b/winsup/cygwin/cygtls.h
index 4d4306b..f911a6c 100644
--- a/winsup/cygwin/cygtls.h
+++ b/winsup/cygwin/cygtls.h
@@ -109,7 +109,7 @@ struct _local_storage
   } select;

   /* strerror */
-  char strerror_buf[sizeof (Unknown error 4294967295)];
+  char strerror_buf[sizeof (Unknown error -2147483648)];

   /* times.cc */
   char timezone_buf[20];


-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: __xpg_strerror_r should not clobber strerror buffer

On Mon, May 23, 2011 at 02:45:43PM -0600, Eric Blake wrote:
Just for the record, I'm having a problem self-building cygwin right
now, from what looks like mingw issues:

/home/eblake/src/winsup/utils/mingw gcc-4 -B./ -shared
-Wl,--image-base,0x6FBC -Wl,--entry,_DllMainCRTStartup@12 mthr.o
mthr_init.o mingwthrd.def -Lmingwex -o mingwm10.dll
mingwex/libmingwex.a(strtodnrp.o): In function `strtod':
/home/eblake/src/build/i686-pc-cygwin/winsup/mingw/mingwex/../../../../../winsup/mingw/include/stdlib.h:315:
multiple definition of `_strtod'
...
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
warning: cannot find entry symbol _DllMainCRTStartup@12; defaulting to
6fbc1000
ertr01.o:(.rdata+0x0): undefined reference to
`__pei386_runtime_relocator'
collect2: ld returned 1 exit status
make[3]: *** [mingwm10.dll] Error 1
make[3]: Leaving directory
`/home/eblake/src/build/i686-pc-cygwin/winsup/mingw'

How do we go about getting that resolved?

I sent email to ironh34d regarding the strtod error after you mentioned
this on irc.  I added an extern in front of the strtod definition in
stdlib.h and that allowed mingw to build but I don't know if it is the
right fix or not.

cgf

Re: __xpg_strerror_r should not clobber strerror buffer

On Mon, May 23, 2011 at 02:52:12PM -0600, Eric Blake wrote:
On 05/23/2011 02:45 PM, Eric Blake wrote:
 On 05/21/2011 07:35 PM, Christopher Faylor wrote:
 On Sat, May 21, 2011 at 07:26:37PM -0600, Eric Blake wrote:
 POSIX says that no other function in the standard should clobber the
 strerror buffer.  Our strerror_r is a GNU extension, so it can get away
 with clobbering the buffer (but if we wanted to fix it, we would have to
 separate _my_tls.locals.strerror_buf into two different buffers).

Shoot.  This introduced an off-by-one buffer overrun.  I'm pushing this
followup.  Meanwhile, do we want a second buffer, so that the GNU
strerror_r won't clobber the strerror buffer?

+++ b/winsup/cygwin/ChangeLog
@@ -2,6 +2,7 @@

   * errno.cc (strerror): Print unknown errno as int.
   (__xpg_strerror_r): Likewise, and don't clobber strerror buffer.
+  * cygtls.h (strerror_buf): Resize to allow '-'.

Please don't send ChangeLog diffs.

The patch is approved.  I don't know if I care whether strerror_r
clobbers strerror.

Thanks.

cgf

fix perror POSIX compliance

This depends on the newlib patch:
http://sourceware.org/ml/newlib/2011/msg00215.html

In fact, if that patch goes in, then this one is required to avoid a
link failure; this one can probably go in first but makes no difference
to perror without the newlib patch.

 winsup/cygwin/ChangeLog|6 +++
 winsup/cygwin/cygtls.h |1 +
 winsup/cygwin/errno.cc |   43 ---
 winsup/cygwin/tlsoffsets.h |   82
++--
 4 files changed, 78 insertions(+), 54 deletions(-)

2011-05-23  Eric Blake  ebl...@redhat.com

* cygtls.h (strerror_r_buf): New buffer.
* errno.cc (strerror): Move guts...
(_strerror_r): ...to new function demanded by newlib.
(strerror_r): Don't clobber strerror buffer.
(_user_strerror): Drop unused declaration.
* tlsoffsets.h: Regenerate.

diff --git a/winsup/cygwin/cygtls.h b/winsup/cygwin/cygtls.h
index 6359e7c..a1642b1 100644
--- a/winsup/cygwin/cygtls.h
+++ b/winsup/cygwin/cygtls.h
@@ -110,6 +110,7 @@ struct _local_storage

   /* strerror errno.cc */
   char strerror_buf[sizeof (Unknown error -2147483648)];
+  char strerror_r_buf[sizeof (Unknown error -2147483648)];

   /* times.cc */
   char timezone_buf[20];
diff --git a/winsup/cygwin/errno.cc b/winsup/cygwin/errno.cc
index aa311b7..f3b925e 100644
--- a/winsup/cygwin/errno.cc
+++ b/winsup/cygwin/errno.cc
@@ -360,8 +360,6 @@ seterrno (const char *file, int line)
   seterrno_from_win_error (file, line, GetLastError ());
 }

-extern char *_user_strerror _PARAMS ((int));
-
 static char *
 strerror_worker (int errnum)
 {
@@ -373,22 +371,38 @@ strerror_worker (int errnum)
   return res;
 }

-/* strerror: convert from errno values to error strings.  Newlib's
-   strerror_r returns  for unknown values, so we override it to
-   provide a nicer thread-safe result string and set errno.  */
+/* Newlib requires this override for perror and friends to avoid
+   clobbering strerror() buffer, without having to differentiate
+   between strerror_r signatures.  This function is intentionally not
+   exported, so that only newlib can use it.  */
 extern C char *
-strerror (int errnum)
+_strerror_r (struct _reent *, int errnum, int internal, int *errptr)
 {
   char *errstr = strerror_worker (errnum);
   if (!errstr)
 {
-  __small_sprintf (errstr = _my_tls.locals.strerror_buf, Unknown
error %d,
-   errnum);
-  errno = _impure_ptr-_errno = EINVAL;
+  errstr = internal ? _my_tls.locals.strerror_r_buf
+: _my_tls.locals.strerror_buf;
+  __small_sprintf (errstr, Unknown error %d, errnum);
+  if (errptr)
+*errptr = EINVAL;
 }
   return errstr;
 }

+/* strerror: convert from errno values to error strings.  Newlib's
+   strerror_r returns  for unknown values, so we override it to
+   provide a nicer thread-safe result string and set errno.  */
+extern C char *
+strerror (int errnum)
+{
+  int error = 0;
+  char *result = _strerror_r (NULL, errnum, 0, error);
+  if (error)
+set_errno (error);
+  return result;
+}
+
 /* Newlib's string.h provides declarations for two strerror_r
variants, according to preprocessor feature macros.  However, it
returns  instead of Unknown error ..., so we override both
@@ -396,10 +410,13 @@ strerror (int errnum)
 extern C char *
 strerror_r (int errnum, char *buf, size_t n)
 {
-  char *error = strerror (errnum);
-  if (strlen (error) = n)
-return error;
-  return strcpy (buf, error);
+  int error = 0;
+  char *errstr = _strerror_r (NULL, errnum, 1, error);
+  if (error)
+set_errno (error);
+  if (strlen (errstr) = n)
+return errstr;
+  return strcpy (buf, errstr);
 }

 extern C int
diff --git a/winsup/cygwin/tlsoffsets.h b/winsup/cygwin/tlsoffsets.h
index 4e459df..3ef7963 100644
--- a/winsup/cygwin/tlsoffsets.h
+++ b/winsup/cygwin/tlsoffsets.h
@@ -1,6 +1,6 @@
 //;# autogenerated:  Do not edit.

-//; $tls::sizeof__cygtls = 3984;
+//; $tls::sizeof__cygtls = 4012;
... // rest of generated file patch elided

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: CYGWIN=tty round 2

On Sun, May 22, 2011 at 09:53:12PM -0500, Yaakov (Cygwin/X) wrote:
On Sun, 2011-05-22 at 17:19 -0400, Christopher Faylor wrote:
I don't think we saw anyone step forward with a valid reason why they
needed to use CYGWIN=tty over something like mintty.

I've summarized the thread where Corinna asked why people used
CYGWIN=tty over CYGWIN=notty below.

I don't see any showstoppers here so unless people can provide specific
examples of how this change would cause hardwhip, we'll be removing
CYGWIN=tty in a snapshot near you soon.

I could add XWin:

http://sourceware.org/bugzilla/show_bug.cgi?id=9763

And once again, using mintty is a solution.

Since mintty is the solution to so many of these scenarios, shouldn't
we make it the default terminal (IOW add mintty to Base and replace the
Cygwin.bat shortcut with mintty's)?  The status quo just encourages
people to use a deficient terminal without any idea that a better one
exists.

I may be missing something but I don't see how the above is not a bug.
The symptom was mentioned in the previous thread.  Unless xwin.exe goes
out of its way to reattach to its calling console (by doing something
similar to what setup.exe does) there is no stdout/stderr to write to.
Windows resets the stdin/stdout/stderr of Windows GUI apps which are run
from a console.

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

Re: CYGWIN=tty round 2

2011-05-23 Thread Sven Köhler

Am 22.05.2011 23:19, schrieb Christopher Faylor:
 mintty

I have the feeling, you should make mintty default :-)
(for startup menu shortcuts, etc.)


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

Re: CYGWIN=tty round 2

2011-05-23 Thread David Sastre

On Mon, May 23, 2011 at 11:35:40AM +0200, Sven Köhler wrote:
 Am 22.05.2011 23:19, schrieb Christopher Faylor:
  mintty
 
 I have the feeling, you should make mintty default :-)
 (for startup menu shortcuts, etc.)

http://cygwin.com/ml/cygwin-apps/2010-05/msg00082.html

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56


signature.asc
Description: Digital signature

Re: CYGWIN=tty round 2

2011-05-23 Thread Andy Koppe

On 23 May 2011 03:53, Yaakov wrote:
 I've summarized the thread where Corinna asked why people used CYGWIN=tty
 over CYGWIN=notty below.

 I don't see any showstoppers here so unless people can provide specific
 examples of how this change would cause hardwhip, we'll be removing
 CYGWIN=tty in a snapshot near you soon.

 I could add XWin:

 http://sourceware.org/bugzilla/show_bug.cgi?id=9763

For some reason which I have yet to investigate, XWin requires a tty to
the log to the terminal.  That means it will output to terminal in VTs,
but will not work in ordinary cmd/bash shells without setting
CYGWIN=tty; instead you will see a cmd window briefly flashing on screen
when launched.

The reason is that XWin.exe is built with -Wl,--subsystem,windows (or
-mwindows, which implies it), which allows it to be invoked directly
from a shortcut or the Run.. dialog without popping up a console or
requiring a console hiding hack. (It's the same for mintty.)

The downside is that Windows also won't hook it up to the parent
process's console, even if there is one, and hence there's nowhere for
Cygwin to hook the standard file descriptors up to.

Having said that, XP introduced the AttachConsole() function, which
allows hooking up to the parent's console by pasing
'ATTACH_PARENT_PROCESS' as the paremeter. It would be very nice if the
Cygwin DLL could try that (followed by CreateFile(CONIN$/CONOUT$,
...)) when GetStdHandle returns an invalid handle while initialising
the standard file descriptors.

Andy

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

Re: CYGWIN=tty round 2

On May 23 12:49, Andy Koppe wrote:
 The reason is that XWin.exe is built with -Wl,--subsystem,windows (or
 -mwindows, which implies it), which allows it to be invoked directly
 from a shortcut or the Run.. dialog without popping up a console or
 requiring a console hiding hack. (It's the same for mintty.)
 
 The downside is that Windows also won't hook it up to the parent
 process's console, even if there is one, and hence there's nowhere for
 Cygwin to hook the standard file descriptors up to.
 
 Having said that, XP introduced the AttachConsole() function, which
 allows hooking up to the parent's console by pasing
 'ATTACH_PARENT_PROCESS' as the paremeter.

That doesn't work as expected.  I found that GetStdHandle does not
return INVALID_HANDLE_VALUE.  Rather, the handle looks like a normal
console handle.  Calling GetFileType then returns FILE_TYPE_UNKNOWN
and GetLastError () returns ERROR_INVALID_HANDLE.  I used that to
add this code:

Index: dtable.cc
===
RCS file: /cvs/src/src/winsup/cygwin/dtable.cc,v
retrieving revision 1.221
diff -u -p -r1.221 dtable.cc
--- dtable.cc   5 May 2011 22:30:53 -   1.221
+++ dtable.cc   23 May 2011 15:35:49 -
@@ -282,7 +282,10 @@ dtable::init_std_file_from_handle (int f
   char name[NT_MAX_PATH];
   name[0] = '\0';
   if (ft == FILE_TYPE_UNKNOWN  GetLastError () == ERROR_INVALID_HANDLE)
-/* can't figure out what this is */;
+{
+  if (AttachConsole (-1) || GetLastError () == ERROR_ACCESS_DENIED)
+   dev = *console_dev;
+}
   else if (ft == FILE_TYPE_PIPE)
 {
   int rcv = 0, len = sizeof (int);

In thoery that should attach to the console and open the console
handles for stdin/out/err.

The effect:

- Started from CMD, XWin prints log output to the console.

- Started from bash or tcsh, no output.

- Mintty doesn't start at all.

That doesn't look overly promising.  It might be better if XWin itself
tries the AttachConsole/CreateFile(CONOUT$) thingy instead, otherwise
we might end up with some overly complex startup code(*) just for the
benefit of a single application.


Corinna


(*) Insert which already is overly complex here.

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

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

Error building run2 from source package in win7

2011-05-23 Thread David Sastre

Hello,

This error shows up when trying to build run2-0.4.0-1-src on

CYGWIN_NT-6.1 win7 1.7.10s(0.244/5/3) 20110510 19:08:34 i686 Cygwin

cc1: warnings being treated as errors
/usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c: In function 
'run2_strtol':
/usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c:423:3: error: 
passing argument 3 of '__assert_func' discards qualifiers from pointer target 
type
/usr/include/assert.h:41:6: note: expected 'char *' but argument is of type 
'const char *'
make[1]: *** [util.lo] Error 1

Any other info I could provide?

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56


signature.asc
Description: Digital signature

Re: Error building run2 from source package in win7

On 05/23/2011 11:17 AM, David Sastre wrote:
 Hello,
 
 This error shows up when trying to build run2-0.4.0-1-src on
 
 CYGWIN_NT-6.1 win7 1.7.10s(0.244/5/3) 20110510 19:08:34 i686 Cygwin
 
 cc1: warnings being treated as errors
 /usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c: In function 
 'run2_strtol':
 /usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c:423:3: 
 error: passing argument 3 of '__assert_func' discards qualifiers from pointer 
 target type
 /usr/include/assert.h:41:6: note: expected 'char *' but argument is of type 
 'const char *'

The signature in assert.h uses 'const char *'; I would have to suspect
that somewhere in your build process you have a stray:

#define const

getting in the way, and that this is thus a bug in the run2 sources and
not in cygwin headers.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: CYGWIN=tty round 2

[sorry.  I don't seem to be able to send a typo-free message lat3ly.]
On Mon, May 23, 2011 at 02:02:04AM -0400, Christopher Faylor wrote:
On Sun, May 22, 2011 at 09:53:12PM -0500, Yaakov (Cygwin/X) wrote:
On Sun, 2011-05-22 at 17:19 -0400, Christopher Faylor wrote:
I don't think we saw anyone step forward with a valid reason why they
needed to use CYGWIN=tty over something like mintty.

I've summarized the thread where Corinna asked why people used
CYGWIN=tty over CYGWIN=notty below.

I don't see any showstoppers here so unless people can provide specific
examples of how this change would cause hardwhip, we'll be removing
CYGWIN=tty in a snapshot near you soon.

I could add XWin:

http://sourceware.org/bugzilla/show_bug.cgi?id=9763

And once again, using mintty is a solution.

Since mintty is the solution to so many of these scenarios, shouldn't
we make it the default terminal (IOW add mintty to Base and replace the
Cygwin.bat shortcut with mintty's)?  The status quo just encourages
people to use a deficient terminal without any idea that a better one
exists.

I may be missing something but I don't see how the above is not a bug.
  is a bug.

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

Re: Error building run2 from source package in win7

On 5/23/2011 1:22 PM, Eric Blake wrote:
 On 05/23/2011 11:17 AM, David Sastre wrote:
 cc1: warnings being treated as errors
 /usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c: In 
 function 'run2_strtol':
 /usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c:423:3: 
 error: passing argument 3 of '__assert_func' discards qualifiers from 
 pointer target type
 /usr/include/assert.h:41:6: note: expected 'char *' but argument is of type 
 'const char *'
 
 The signature in assert.h uses 'const char *'; I would have to suspect
 that somewhere in your build process you have a stray:
 
 #define const
 
 getting in the way,

I think this is the only possibility, because...

 and that this is thus a bug in the run2 sources and
 not in cygwin headers.

...the code does this:

int
run2_strtol(char *arg, long *value)
{
  char *endptr;
  int errno_save = errno;

  assert(arg!=NULL);

However, the stringization of the expression 'arg!=NULL' is passed as
arg #4 (and the expression itself doesn't appear in the argument list of
__assert_func at all; see definition below).  Anyway, the #3 argument of
__assert_func is __ASSERT_FUNC:

# define assert(__e) ((__e) ? (void)0 : \
   __assert_func (__FILE__, __LINE__, \
   __ASSERT_FUNC, #__e))

and __ASSERT_FUNC is defined as
__PRETTY_FUNCTION__
__func__
or  __FUNCTION__
depending on the compiler and various flags.  Now, since these are
built-ins, the signature is fixed: they are all const char*.  So the
only way you could get this warning/error is if assert.h is messed up
somehow...e.g. as Eric suggests, because an earlier header has #defined
const away before the following decl in assert.h is parsed:

void _EXFUN(__assert_func, (const char *, int, const char *,
  const char *) _ATTRIBUTE ((__noreturn__)));




Now, where could a #define const occur?

$ find ${run2_srcdir} -type f |\
  xargs grep const | grep define | grep '#'
./configure:$as_echo #define const /**/ confdefs.h

...more checking...Ah, this is part of the configure macro AC_C_CONST.

hmm...maybe the OP should check his generated config.h file for the
offending def.  If it's there, a quick look inside config.log should
tell you why 'checking for an ANSI C-conforming const' is reporting 'no'.

--
Chuck

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

Re: CYGWIN=tty round 2

2011-05-23 Thread Angelo Graziosi


Following this thread and the similar

  http://cygwin.com/ml/cygwin-apps/2011-05/msg00041.html

I want to flag that this:

/cygdrive/c/WINDOWS/system32/runas.exe /user:pippo 'C:\cygwin-2\bin\bash 
--login -i'


works in a dos-like shell (Cygwin.bat) but not in mintty. Is there some 
trick to do the job also in mintty?


Thanks,
Angelo.

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

RE: CYGWIN=tty round 2

2011-05-23 Thread Fahlgren, Eric

Angelo Graziosi wrote:
 /cygdrive/c/WINDOWS/system32/runas.exe /user:pippo 'C:\cygwin-2\bin\bash 
 --login -i'

 works in a dos-like shell (Cygwin.bat) but not in mintty. Is there some trick 
 to do the job also in mintty?

Angelo,

I'm not completely sure about what you are trying to do, but this works for me 
to get a shell running under the proper user:

$ cat bldmgr.bat
 runas /user:proddev\bldmgr c:\cygwin\bin\mintty.exe -

Eric Fahlgren

RE: CYGWIN=tty round 2

2011-05-23 Thread Angelo Graziosi


Hi Eric,


but this works for me to get a shell running under the proper user:

runas /user:proddev\bldmgr c:\cygwin\bin\mintty.exe -


yes, also for me, but *only* from Cygwin.bat shell not from MinTTY: here 
it asks for password and return the prompt without waiting for password 
typing.


I would like to start MinTTY, running under the proper user, from MinTTY 
and not from Cygwin.bat.


Ciao,
Angelo.

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

Re: CYGWIN=tty round 2