Re: Cygwin 1.7.1-1 - problem with non-blocking socket IO

[Corinna Vinschen]

On Dec 29 01:11, Larry Hall (Cygwin) wrote:
> On 12/29/2009 01:07 AM, Uri Simchoni wrote:
> >Thanks for the quick response. Could you post the patch?
> 
> See the cygwin-cvs mailing list for applied patches to Cygwin.  In this case:
> 

Tonight (yes, unfortunately) it occured to me that the patch isn't quite
correct, yet.  I haven't much time, what with vacation and all that, but
I know what has to be changed.  I'll come up with a better solution in
the next couple of days.


Corinna

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

Re: setup 1.7.1 hangs on 000-cygwin-post-install.sh

[Taras Tielkes]

Frank Fesevur  users.sourceforge.net> writes:

> Didn't help either. I upgraded at home without any problem. I haven't
> got a clue how to get cygwin back on my system 

I'm experiencing the same problems.
Fortunately, the "legacy install" (aka 1.5) works like a charm.

hth,
-tt



--
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: gcc4[1.7] printf treats differently a string constant and a character array

[Rodrigo Medina]

>2009/12/28 Andy Koppe:
>...
>Ah, the problem actually is that your program is missing a call to
>setlocale(LC_CTYPE, "") to switch to the locale and character set
>specified in the environment...

That worked!, but what that means is that if one wants to
use any locale other than C.UTF-8, one has, not only to compile again the
programs , but also to modify them. Perhaps the best thing to do
is to read the LC_ALL variable from the environment and then call
setlocale. 

Thanks
RM



--
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: gcc4[1.7] printf treats differently a string constant and a character array

[Andy Koppe]

2009/12/29 Rodrigo Medina:
>>Ah, the problem actually is that your program is missing a call to
>>setlocale(LC_CTYPE, "") to switch to the locale and character set
>>specified in the environment...
>
> That worked!, but what that means is that if one wants to
> use any locale other than C.UTF-8, one has, not only to compile again the
> programs , but also to modify them. Perhaps the best thing to do
> is to read the LC_ALL variable from the environment and then call
> setlocale.

setlocale(LC_CTYPE, "") already does that. It tries to read LC_ALL,
LC_CTYPE, and LANG, in that order, and only if none of them are set it
falls back to the default locale: C.UTF-8.

'char' string constants with non-ASCII characters are not a good idea
if the program is supposed to work with different charsets, because
they're encoded in one particular charset, namely that of your editor.

In that case you need to use wchar_t strings instead, for example:

#include 
#include 

int main(void) {
  setlocale(LC_CTYPE, "");
  wprintf(L"Øl\n");
}

You also need to ensure that gcc's character set matches the source
file's; otherwise gcc won't encode the wide string correctly.

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: gcc4[1.7] printf treats differently a string constant and a character array

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Andy Koppe on 12/28/2009 11:17 PM:
>>> I am using LC_ALL=es_VE.ISO-8859-15.

So you told gcc which charset to use for those non-ASCII characters, which
resulted in raw 8-bit bytes.  puts is required to work transparently on
bytes, but printf is specified as a mix between bytes (arguments matching
%s) and characters (the format string itself, and arguments matching %ls).

> 
> Ah, the problem actually is that your program is missing a call to
> setlocale(LC_CTYPE, "") to switch to the locale and character set
> specified in the environment. In fact, since your program contains
> hard-coded ISO-8859-15 strings, you should probably do
> setlocale(LC_CTYPE, ".ISO-8859-15").

Well, as long as you are running it on your machine, with
LC_ALL=es_VE.ISO-8859-15 in the environment, then setlocale(LC_ALL,"")
will pick up the same charset as what gcc hard-coded into your app.  But
yes, by using 8-bit bytes in your string, you have married your executable
to a particular locale, and it is no longer portable to machines using a
different charset.  To be more portable, you would want to use some
iconv() conversions (or look into using gettext() for translation catalogs).

> 
> Without a setlocale call, programs use the "C" locale, and on Cygwin
> 1.7 that implies the UTF-8 character set. Those single accented
> ISO-8859-15 characters are invalid when interpreted as UTF-8, so
> printf halts there. The accented character pairs like "á", meanwhile,
> happen to be valid UTF-8, so they get through.
> 
> I couldn't find specific text about invalid bytes in the POSIX printf
> spec,

http://www.opengroup.org/onlinepubs/9699919799/functions/fprintf.html

"all forms of fprintf() shall fail if:

[EILSEQ]
[CX] A wide-character code that does not correspond to a valid
character has been detected."

> It's talking about "characters" rather than "bytes" there, which I
> think does leave the behaviour for invalid bytes undefined,

It's actually well-defined - non-characters in the format string MUST make
printf fail.  However, it raises the issue of whether the failure must
occur without any output, or only upon detection of the first invalid
character whether or not prior characters and % directives have been acted
upon.  I think the standard is silent on that point, making it a QoI issue.

Remember, POSIX states that any use in a character context of bytes with
the 8th-bit set is specifically undefined in the C locale (whether that be
C.ASCII or C.UTF-8).  Using accented characters (which result in bytes
with the 8th-bit set, whether you use UTF-8 or ISO-8859-15) falls into
that category, so the bug is in your program for expecting sane results
while not changing the locale away from C.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAks6AkYACgkQ84KuGfSFAYCcZwCfSqNz9qdjxEBXHMwtPJ+8bx9T
6S4AoJlgfarKywPgDH6TY3Zy16/3jc1K
=YRTJ
-END PGP SIGNATURE-

--
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: gcc4[1.7] printf treats differently a string constant and a character array

[Andy Koppe]

2009/12/29 Eric Blake:
>> I couldn't find specific text about invalid bytes in the POSIX printf
>> spec,
>
> http://www.opengroup.org/onlinepubs/9699919799/functions/fprintf.html
>
> "all forms of fprintf() shall fail if:
>
> [EILSEQ]
>    [CX] A wide-character code that does not correspond to a valid
> character has been detected."

The issue wasn't with wide characters, but invalid multibyte chars.
But anyway, we're agreed that printf is right to bail out.


> Remember, POSIX states that any use in a character context of bytes with
> the 8th-bit set is specifically undefined in the C locale (whether that be
> C.ASCII or C.UTF-8).

I very much disagree with that. C.ASCII and C.UTF-8 are different
locales from plain "C", and the whole point of the explicitly stated
charset is to define the meaning of bytes beyond 7-bit ASCII.

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: No go after update to 1.7.1

[Bernd Bartmann]

On Mon, Dec 28, 2009 at 11:30 AM, Bernd Bartmann wrote:
> On Mon, Dec 28, 2009 at 12:31 AM, Christopher Faylor
>  wrote:
>> I'd suggest at this point that you run sysinternals procmon to see if
>> you can figure out why bash isn't starting.  You might also try running
>> with a trimmed down PATH.
>
> Setting the PATH to C:\cygwin\bin only doesn't help either. So I tried
> procmon to monitor what bash is actually doing. As it seems it stops
> because it can't find /etc/passwd and /etc/fstab which indeed are
> missing. Shouldn't they have been created during the setup process?
> Also, /etc does not contain any files just some sub-directories:
>
> alternatives
> defaults
> fonts
> postinstall
> preremove
> profile.d
> setup
> terminfo
>
> I've attached the procmon log for the bash start test in .csv format
> for your inspection. Maybe also of interest is /var/log/setup.log.

No one? No more ideas?

Best regards,
Bernd.

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

[Patch] chere-1.1-1: fix uninstall from Control Panel

[Christian Franke]

Uninstalling a chere item from Control Panel does not work if 
C:\cygwin\bin is not in Windows default PATH.

The attached patch fixes this.

Christian

--- chere-1.1-1	2009-01-29 23:15:52.00100 +0100
+++ chere	2009-12-29 14:09:58.046875000 +0100
@@ -707,7 +707,7 @@ create_uninstall_item()
   # even after the cygwin directory is wiped :(
   if $REGTOOL add $1 ; then
$REGTOOL -s set $1/DisplayName \"$CPH_DESC\"
-   $REGTOOL -s set $1/UnInstallString \"$ASH_EXE -c \\\"/bin/chere $UINST_ARG -u -s $2\\\"\"
+   $REGTOOL -s set $1/UnInstallString \"$ASH_EXE -c \\\"PATH=/bin /bin/chere $UINST_ARG -u -s $2\\\"\"
   else
echo $0 Error: Couldn\'t modify HKLM hive.
echo Control Panel uninstall will not be available.

--
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: gcc4[1.7] printf treats differently a string constant and a character array

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Andy Koppe on 12/29/2009 6:30 AM:
>> Remember, POSIX states that any use in a character context of bytes with
>> the 8th-bit set is specifically undefined in the C locale (whether that be
>> C.ASCII or C.UTF-8).
> 
> I very much disagree with that. C.ASCII and C.UTF-8 are different
> locales from plain "C", and the whole point of the explicitly stated
> charset is to define the meaning of bytes beyond 7-bit ASCII.

Point taken: an explicit "C.UTF-8" is a request of a specific charset
along with C semantics (such as no translation of output messages,
posix-mandated formatting for time and money, ...), but because the
charset is explicit, the use of 8-bit bytes is well-defined in our
implementation (and since POSIX does not specify C.UTF-8, you've already
left the realm of portability and gone into implementation-defined).

But my point remains: an explicit "C" is specified to be charset-agnostic,
so a portable program requesting "C" should not be expecting any
particular behavior of 8-bit bytes in character contexts.  Programs that
use LC_ALL=C to try to get 8-bit transparency from character contexts are
flat-out non-portable.  They get other well-defined benefits on 8-bit
bytes (such as sorting by strcmp instead of strcoll, fixed-format
messages, ...), but only insofar as those 8-bit bytes are in byte contexts
rather than character contexts.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAks6Bw0ACgkQ84KuGfSFAYByhQCZAWbgggdJm5KBtBfNm9ElHmJN
p14AoMoKgy2XxhNqnV/KxuFVyttbp+m6
=eLYn
-END PGP SIGNATURE-

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

"update-desktop-database" seems to not work anymore.

[Claude Sylvain]

Hello,

- Just to report that "update-desktop-database" seems to not work
  correctly on Cygwin 1.7.1.  It was working on Cygwin 1.5.x.

- Furthermore, I notice the following things:

- On Cygwin, when calling "update-desktop-database" without parameter,
  "update-desktop-database" exit silently!?
  On a Slackware 12.1 GNU/Linux machine, calling
  "update-desktop-database" without parameter make it display
  the following message "No directories in update-desktop-database
  search path could be processed and updated."

- On Cygwin and on a Slackware 12.1 GNU/Linux machine, there is no
  "man" page for "update-desktop-database".

- On Cygwin, "update-desktop-database" do not display help when
  calling it with "-?" or "--help" parameters.
  These parameters work correctly on a Slackware 12.1 GNU/Linux
  machine.

- On Cygwin, "update-desktop-database" seems to always return a
  a value of "127".
  On a Slackware 12.1 GNU/Linux machine, "update-desktop-database"
  return a value of "1" when it fail.


- Remarks:
- This problem make installation to fail when doing "make install"
  on some projects; like "geda-gaf" project.

- The workaround I used to get rid of that problem is to replace the
  call to "update-desktop-database" by something like "ls" in the
  "Makefile" created by the autotools.

- Cygwin "setup" do not show any "update-desktop-database" package!?
  So, it is difficult to go further more in the evaluation/resolution
  of that problem.


From a Cygwin user.
Claude


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

Re: [ANNOUNCEMENT] Updated: cygutils-1.4.2-1

[Andy Koppe]

2009/12/29 Charles Wilson:
> TODO (call for patches):
> 
> * Update lpr.cc and mkshortcut.c to use cygwin-1.7 cygwin_conv_path
>  instead of deprecated cygwin_conv_to_win32_path.

I'll have a go at mkshortcut.

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: No go after update to 1.7.1

[Bernd Bartmann]

Obviously my last post didn't make it through the mailing list
probably because of a .csv attachment. So, here's the original text
again:

Setting the PATH to C:\cygwin\bin only doesn't help either. So I tried
procmon to monitor what bash is actually doing. As it seems it stops
because it can't find /etc/passwd and /etc/fstab which indeed are
missing. Shouldn't they have been created during the setup process?
Also, /etc does not contain any files just some sub-directories:

alternatives
defaults
fonts
postinstall
preremove
profile.d
setup
terminfo

As mailing list doesn't seem to like the procmon log in .csv format
I'll not attach it again. I can send it to a private email address by
request.

Best regards,
Bernd.

--
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-desktop-database" seems to not work anymore.

[Larry Hall (Cygwin)]

On 12/29/2009 10:21 AM, Claude Sylvain wrote:

 - Cygwin "setup" do not show any "update-desktop-database" package!?
   So, it is difficult to go further more in the evaluation/resolution
   of that problem.


cygcheck -p update-desktop-database

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

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: No go after update to 1.7.1

[Larry Hall (Cygwin)]

On 12/29/2009 10:57 AM, Bernd Bartmann wrote:

Obviously my last post didn't make it through the mailing list
probably because of a .csv attachment. So, here's the original text
again:

Setting the PATH to C:\cygwin\bin only doesn't help either. So I tried
procmon to monitor what bash is actually doing. As it seems it stops
because it can't find /etc/passwd and /etc/fstab which indeed are
missing. Shouldn't they have been created during the setup process?
Also, /etc does not contain any files just some sub-directories:

alternatives
defaults
fonts
postinstall
preremove
profile.d
setup
terminfo



So this means your installation isn't proceeding properly.  Could be failed
postinstall scripts, perhaps as a result of bash not being able to run.
You can check out '/var/log/setup.log.full' for some insights.  Also, I think
it's time to start considering the possible effects of BLODA
.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

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: Fwd: No go after update to 1.7.1

[Dave Korn]

[  Cc'ing the list back in now, FTR.  ]

Bernd Bartmann wrote:
>> Looks like your post didn't make it through to the list; there's nothing in
>> the archive for your message with ID
>> <6c18a4f0912280230k601eca9me32c056e09117...@mail.gmail.com>.  Probably
>> something somewhere down the line thought a .csv attachment was suspicious,
>> malicious, spammy-looking or overly-large, so I'm writing off-list to ask for
>> a copy.  Can't promise it'll show anything, but I'll take a look.
> 
>  Thanks Dave for pointing this out. Below you'll find my original
> post. Hopefully the attachments will arrive as well.

  We have a suspect:

> "11:09:08,3362588","bash.exe","3396","CreateFileMapping","C:\Programme\BitDefender\BitDefender
>  2010\Active Virus Control\midas32-v2_58\PLUGIN_NT.M32","SUCCESS","SyncType: 
> SyncTypeOther"

  That's listed on BLODA.  You may be able to work around by following the
rebase advice discussed in these threads:

"BitDefender again"
  http://www.cygwin.com/ml/cygwin/2009-08/threads.html#00771
  http://www.cygwin.com/ml/cygwin/2009-09/threads.html#9

"Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes"
  http://cygwin.com/ml/cygwin/2009-12/threads.html#00159

(I left a question unanswered in one of those threads about what the effects
of relocating the cygwin1 dll to a low base address could be; the brief answer
would be "largely theoretical, unless you're the type who does massive number
crunching with huge arrays in fortran, or similar".)

cheers,
  DaveK

--
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: No go after update to 1.7.1

[Claude Sylvain]

Bernd Bartmann wrote:

>
> procmon to monitor what bash is actually doing. As it seems it stops
> because it can't find /etc/passwd and /etc/fstab which indeed are
> missing. Shouldn't they have been created during the setup process?
> Also, /etc does not contain any files just some sub-directories:
>

- Last week I installed (using setup.exe) Cygwin 1.7.1, and none of
  the problems that you describe above appear.

- This lead me to think that you have not configured "setup.exe" correctly.
  Either you choose a mirror site that do not contain all Cygwin element, or
  you have not selected the packages correctly.

- When I have installed Cygwin 1.7.1, I have done the following things:

- Renamed the old Cygwin (1.5.x) directory "C:\cygwin" as
  "C:\cygwin_old".  Just be able to recover by personnal
  data, later.

- Downloaded the latest version Cygwin "setup.exe" in a
  newly created temporary directory.

- Launched "setup.exe", and configure it something like:
- Selected "ftp://mirrors.kernel.org"; as the mirror site.
  Note: Some mirrors sites seems to do not have all necessary
  Cygwin packages to make a good installation!?  But the
  one mentionned above is a good choice.

- Selected all the packages, by choosing "install" on "all"
  in "Category" field.
  Note: As stated in
  "http://cygwin.com/cygwin-ug-net/index.html";, this make a
  huge installation.  But, everything is there!


Hope it will help.

From a Cygwin user.
Claude.


--
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-desktop-database" seems to not work anymore.

[Cesar Strauss]

Claude Sylvain wrote:


- Just to report that "update-desktop-database" seems to not work
  correctly on Cygwin 1.7.1.


update-desktop-database.exe seems to be affected by a bug in Cygwin's 
libtool.


See:
Libtool: Generated manifests need execute permission
http://article.gmane.org/gmane.os.cygwin/110870

When compiling update-desktop-database.exe, libtool first creates a 
wrapper executable with the same name, for internal purposes. To defeat 
UAC, it also creates a manifest file. Unfortunately, it fails to set the 
execute bit, so the wrapper is non-functional. As a result, the libtool 
wrapper ends up being installed and packaged, instead of the real program.


For a detailed description and test case, see the post referenced above.


- This problem make installation to fail when doing "make install"
  on some projects; like "geda-gaf" project.


Coincidentally, it was the very project that lead me to investigate the 
issue.



- The workaround I used to get rid of that problem is to replace the
  call to "update-desktop-database" by something like "ls" in the
  "Makefile" created by the autotools.


Just use ./configure --disable-update-xdg-database

Cesar




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

cygpath and spaces in filenames when reading from a file

[Jon Beniston]

Hi,

cygpath can read a list of paths to convert from a file, when started with
-file. However, how do you specify paths with spaces in them in this mode?
It seems quoting the path or using \ doesn't seem to work. E.g:

$cygpath --windows --file -
"/usr/local/my dir/"
"\usr\local\my
dir\"

$ cygpath --windows --file -
/usr/local/my\ dir/
C:\cygwin\usr\local\my\
dir\

Cheers,
Jon





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

Re: Fwd: No go after update to 1.7.1

[Bernd Bartmann]

On Tue, Dec 29, 2009 at 6:05 PM, Dave Korn wrote:
>  We have a suspect:
>
>> "11:09:08,3362588","bash.exe","3396","CreateFileMapping","C:\Programme\BitDefender\BitDefender
>>  2010\Active Virus Control\midas32-v2_58\PLUGIN_NT.M32","SUCCESS","SyncType: 
>> SyncTypeOther"
>
>  That's listed on BLODA.  You may be able to work around by following the
> rebase advice discussed in these threads:
>
> "BitDefender again"
>  http://www.cygwin.com/ml/cygwin/2009-08/threads.html#00771
>  http://www.cygwin.com/ml/cygwin/2009-09/threads.html#9
>
> "Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes"
>  http://cygwin.com/ml/cygwin/2009-12/threads.html#00159
>
> (I left a question unanswered in one of those threads about what the effects
> of relocating the cygwin1 dll to a low base address could be; the brief answer
> would be "largely theoretical, unless you're the type who does massive number
> crunching with huge arrays in fortran, or similar".)

Dave, thanks a lot! I followed the advice to rebase the cygwin1.dll
and now I get a bash shell prompt. So indeed the combination of cygwin
and BitDefender 2010 is the root cause of the problem.

Now how to go on to get the cygwin installation fixed? As Larry
pointed out - because bash could not be run during the setup process
the postinstall scripts couldn't be run.
Shall I just reinstall all packages but the core cygwin package?

Also, it is not entirely clear to me if cygwin or BitDefender is to
blame for the problem. Is there work going on to address this issue
from the cygwin side? Should I contact BitDefender about the problem?
I would regret it if cygwin can't be installed by Joe User on a system
that has BitDefender 2010 installed as well.

Best regards,
Bernd.

--
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: git stopped working with 1.7.1

[Kevin Layer]

David Antliff  wrote:

>> > It may be a 64-bit issue, so I'll try a 32-bit machine, if I can
>> > scrounge one up.
>> 
>> We are using WinXP 32-bit and have not seen this problem (yet). It
>> would be really helpful (to me at least) to know whether you can
>> reproduce the issue with 32-bit Windows...
>> 
>> I imagine there are a fair number of people using git in Cygwin
>> because the Windows alternatives (msys, etc) do not provide a
>> POSIX-like toolchain environment. Using Cygwin also allows scripts
>> around git to operate on Linux with no modifications. That is why we
>> use Cygwin anyway, and Cygwin + git is very important to us, FWIW.

I just tried 32-bit Windows XP Pro.  I upgraded from 1.5.25 and
installed git (it wasn't previously on that machine).  Failed the same
way.

Kevin

--
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: Fwd: No go after update to 1.7.1

[Dave Korn]

Bernd Bartmann wrote:

> Now how to go on to get the cygwin installation fixed? As Larry
> pointed out - because bash could not be run during the setup process
> the postinstall scripts couldn't be run.
> Shall I just reinstall all packages but the core cygwin package?

  Take a look in /etc/postinstall.  If you see lots of files named "*.sh",
then you can simply re-run setup.exe and click right through it without
changing any of the settings from last time and it will finish off running any
scripts that it didn't do last time.  OTOH, if you see only lots of files
named "*.sh.done", that means it somehow didn't notice that the scripts had
failed and it won't try re-running them; in that case, you still re-run
setup.exe and click through it largely unaltered, but when you get to the
package chooser screen, select the category view and set the top category to
"reinstall".

> Also, it is not entirely clear to me if cygwin or BitDefender is to
> blame for the problem. Is there work going on to address this issue
> from the cygwin side? Should I contact BitDefender about the problem?
> I would regret it if cygwin can't be installed by Joe User on a system
> that has BitDefender 2010 installed as well.

  To a large extent, it's one of those 'can't-be-helped' things:

- To mimic posix fork semantics, Cygwin has to recreate the exact memory map
of the parent process in the child's memory space, including the addresses at
which shared libraries (dlls) are loaded.

- To intercept file access and check for viruses etc., BitDefender injects
dlls into every process to hook the potentially-dangerous system calls.

- Cygwin doesn't actually have full control over how things get loaded into
memory; that's determined by the OS loader which is invoked when Cygwin calls
CreateProcess.

- Sometimes the OS loader doesn't reload all the DLLs in the newly-created
child process at the same base addresses as they were at in the parent process
when there's a clash between two DLLs competing for the same base address.

  There are some tricks in the DLL to try and avoid and/or work around the
problem, but ultimately we're limited by the behaviour of the underlying OS
which isn't directly under our control and doesn't always do what is needed
for POSIX semantics because (after all) it was designed to implement win32
semantics.

  Of course, this means that it's all someone else's fault and Cygwin is
perfect :-) and I'm not saying that under any kind of duress or
gravitationally-inspired threat from any kind of even-toed aquatic ungulant
whatsoever ...

cheers,
  DaveK


--
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-desktop-database" seems to not work anymore.

[Claude Sylvain]

Cesar Strauss wrote:

>
> Claude Sylvain wrote:
>
>> - Just to report that "update-desktop-database" seems to not work
>>   correctly on Cygwin 1.7.1.
>
> update-desktop-database.exe seems to be affected by a bug in Cygwin's
> libtool.
>
> See:
> Libtool: Generated manifests need execute permission
> http://article.gmane.org/gmane.os.cygwin/110870
>
> When compiling update-desktop-database.exe, libtool first creates a
> wrapper executable with the same name, for internal purposes. To defeat
> UAC, it also creates a manifest file. Unfortunately, it fails to set the
> execute bit, so the wrapper is non-functional. As a result, the libtool
> wrapper ends up being installed and packaged, instead of the real program.
>
> For a detailed description and test case, see the post referenced above.
>
>> - This problem make installation to fail when doing "make install"
>>   on some projects; like "geda-gaf" project.
>
> Coincidentally, it was the very project that lead me to investigate the
> issue.
>
>> - The workaround I used to get rid of that problem is to replace the
>>   call to "update-desktop-database" by something like "ls" in the
>>   "Makefile" created by the autotools.
>
> Just use ./configure --disable-update-xdg-database
>


Thank you for your advice.  Your workaround is far much better than mine.

Claude.


--
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: Fwd: No go after update to 1.7.1

[Christopher Faylor]

On Tue, Dec 29, 2009 at 06:08:50PM +, Dave Korn wrote:
>Of course, this means that it's all someone else's fault and Cygwin is
>perfect :-) and I'm not saying that under any kind of duress or
>gravitationally-inspired threat from any kind of even-toed aquatic
>ungulant whatsoever ...

Gentlemen, please stand down.  There will be no hippo launching today.

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: A question about setup.exe

[Dave Korn]

Paul McFerrin wrote:
> OKAY... I finally realized that MTIME was not used by setup.  I now have
> my installation completely restored.  I used file
> /etc/setup/installed.db to "trick" setup to do a forced install.
> 
> 1. Have a running cygwin system available
> 2. Run "setup" thru the "Package Selection" pages but NOT beyond
> 3. On your running cygwin system, delete all but 1st line in file
> "/etc/setup/installed.db".
> 4. Shutdown your running cygwin sysrem
> 5.  Click the "NEXT" button in setup and your re-installation will begin.

  Oh, I didn't see this post earlier.  I prefer to do it the easy way:

> 2. Run "setup" thru the "Package Selection" pages but NOT beyond
3.  Select "Reinstall" at the top-level of the category view.
> 5.  Click the "NEXT" button in setup and your re-installation will begin.

cheers,
  DaveK


--
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: Fwd: No go after update to 1.7.1

[Bernd Bartmann]

On Tue, Dec 29, 2009 at 7:08 PM, Dave Korn wrote:
>  Take a look in /etc/postinstall.  If you see lots of files named "*.sh",
> then you can simply re-run setup.exe and click right through it without
> changing any of the settings from last time and it will finish off running any
> scripts that it didn't do last time.  OTOH, if you see only lots of files
> named "*.sh.done", that means it somehow didn't notice that the scripts had
> failed and it won't try re-running them; in that case, you still re-run
> setup.exe and click through it largely unaltered, but when you get to the
> package chooser screen, select the category view and set the top category to
> "reinstall".

After noticing that all files in the /etc/postinstall dir are named
*.sh.done I chose your second option. This worked fine and now my /etc
dir is filled correctly. But I should note that of course one has to
omit the cygwin-1.7.1-1 package from the reinstall process as this
will again install the DLL that has not been rebased and thus all
postinstall scripts will fail again.

>  To a large extent, it's one of those 'can't-be-helped' things:
>
> - To mimic posix fork semantics, Cygwin has to recreate the exact memory map
> of the parent process in the child's memory space, including the addresses at
> which shared libraries (dlls) are loaded.
>
> - To intercept file access and check for viruses etc., BitDefender injects
> dlls into every process to hook the potentially-dangerous system calls.
>
> - Cygwin doesn't actually have full control over how things get loaded into
> memory; that's determined by the OS loader which is invoked when Cygwin calls
> CreateProcess.
>
> - Sometimes the OS loader doesn't reload all the DLLs in the newly-created
> child process at the same base addresses as they were at in the parent process
> when there's a clash between two DLLs competing for the same base address.
>
>  There are some tricks in the DLL to try and avoid and/or work around the
> problem, but ultimately we're limited by the behaviour of the underlying OS
> which isn't directly under our control and doesn't always do what is needed
> for POSIX semantics because (after all) it was designed to implement win32
> semantics.
>
>  Of course, this means that it's all someone else's fault and Cygwin is
> perfect :-) and I'm not saying that under any kind of duress or
> gravitationally-inspired threat from any kind of even-toed aquatic ungulant
> whatsoever ...

Thanks for your explanations. One just has to keep in mind that for
every upcoming update of the cygwin1.dll one has to re-run the rebase
process.

Best regards,
Bernd.

--
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: make-3.81-4

[Edward Lam]

Hi Rob,

Rob Walker wrote:
It's been almost a year and a half since I made a request to have 
Cygwin's GNU make updated with the upstream patches for colons in 
dependencies and VPATH directives:


Is this patch submitted upstream to the gmake project? I imagine it 
would be helpful to the HAVE_DOS_PATHS define code path in gmake. 
Personally, I always recompile gmake in cygwin with HAVE_DOS_PATHS defined.


Thanks,
-Edward

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

Bash v4.0 does not respect $PATH

[Neil.Mowbray]

Folks,

I need associative arrays so I got the bash 4.0 source, compiled it under
cygwin
and installed it in /usr/local/bin.

I have ActiveState perl installed in /opt/perl which preceeds
/usr/local/bin:/bin:/usr/bin
on my path.  Using bash 4.0, 'which' says I should get ActiveState perl, but
actual
execution gives cygwin perl in /bin

$ for i in $(echo $PATH | sed -r -e "s/:/ /g"); do echo $i; done
/opt/site/bin
/opt/ms-vs-10.0/VC/bin
/opt/perl/bin
/usr/local/bin
/bin
/usr/bin
...

$ which perl
/opt/perl/bin/perl

But

$ perl --version
This is perl, v5.10.1 (*) built for i686-cygwin-thread-muli-64int
(with 12 registered patches, see perl -V for more detail)
...

If I switch to bash 3.x in /bin things work as expected.

$ /bin/bash

$ which perl
/opt/perl/bin/perl

$ perl --version
This is perl, v5.10.1 built for MSWin32-x86-multi-thread
...

How can I fix bash 4.0 path problems?

Regards, Neil


--
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: git stopped working with 1.7.1

[David Antliff]

On Thu, Dec 24, 2009 at 07:55, Kevin Layer  wrote:
>  la...@hobart128 /c/tmp
>  $ git clone git:/repo/git/acl acl.test
>  Initialized empty Git repository in /c/tmp/acl.test/.git/
>  remote: Counting objects: 9205, done.
>  remote: Compressing objects: 100% (3300/3300), done.
>  fatal: The remote end hung up unexpectedly
>  fatal: early EOFs:  62% (5708/9205)
>  fatal: index-pack failed

I'm no git expert, but that looks to me like the remote side (where
the repository is stored) is experiencing the error while it's
preparing data for transfer, and your local git is simply reporting
the remote error. It also looks like the remote side is actually the
same machine but you're using the git:// protocol to access it without
specifying a remote server. I've never tried this and would have
expected instead to see something like:

$ git clone git://localhost/repo/git/acl acl.test
or
$ git clone /repo/git/acl acl.test

I.e. there's something about your command that *I* don't understand.
It's probably perfectly fine though, and the problem is with me.

Are you intending to clone a repository on the same machine but via
the git:// protocol? What if you just do this instead:

$ git clone /repo/git/acl acl.test

Do you get the same error?

Since it looks like the remote is on the same machine as your shell,
do you have write access to the actual repository? If so, you could
run git-fsck on the repository to make sure it's intact.

What about other repositories, do they behave the same way, or is your
problem restricted to this one?

-- David.

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

Re: Cygwin 1.7.1-1 - problem with non-blocking socket IO

[Corinna Vinschen]

On Dec 29 09:30, Corinna Vinschen wrote:
> On Dec 29 01:11, Larry Hall (Cygwin) wrote:
> > On 12/29/2009 01:07 AM, Uri Simchoni wrote:
> > >Thanks for the quick response. Could you post the patch?
> > 
> > See the cygwin-cvs mailing list for applied patches to Cygwin.  In this 
> > case:
> > 
> 
> Tonight (yes, unfortunately) it occured to me that the patch isn't quite
> correct, yet.  I haven't much time, what with vacation and all that, but
> I know what has to be changed.  I'll come up with a better solution in
> the next couple of days.

False alarm.  The code is already doing the right thing, AFAICS.


Corinna

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

Alt key not recognized as Meta in xterm

[Gary Carvell]

With the upgrade to Cygwin 1.7, I found that the Alt key is no longer
recognized as a Meta key in xterm. This means the Alt based command
line editing keys such as Alt-F/B for forward- and backward-word must
be entered with the Esc key instead. I assume this is related to the
internationalization changes in 1.7.

I liked the old behavior better, but had some trouble changing it
back. So here's my little hack for this in case anyone else finds it
useful. In your home directory, create a file .Xdefaults containing
this line:

XTerm*vt100.metaSendsEscape: true

This effectively sets the Meta Sends Escape menu option for new
xterms, causing the Alt key to work again for command line editing.

I'd be glad to hear any background information on the key mapping
change, or better ways to restore the old behavior.

Gary

--
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: make-3.81-4

[Rob Walker]

Edward Lam wrote:

Rob Walker wrote:
  
It's been almost a year and a half since I made a request to have 
Cygwin's GNU make updated with the upstream patches for colons in 
dependencies and VPATH directives:



Is this patch submitted upstream to the gmake project? I imagine it 
would be helpful to the HAVE_DOS_PATHS define code path in gmake. 
Personally, I always recompile gmake in cygwin with HAVE_DOS_PATHS defined.


  

Here are links to the patches I've applied to construct this package:

 http://lists.gnu.org/archive/html/make-w32/2006-09/msg00037.html
 http://lists.gnu.org/archive/html/make-w32/2007-12/msg00015.html

-Rob



--
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: "mount -a" has no effect on the cygdrive prefix

[Karl M]

> Date: Thu, 24 Dec 2009 12:10:47 +0100
> From: corinna-cygwin
> Subject: Re: "mount -a" has no effect on the cygdrive prefix
>
> On Dec 23 08:32, Karl M wrote:
>> Hi All...
>>
>> With the last 1.7.0 version and with a clean 1.7.1 install on an XP Pro SP3 
>> machine,
>> if I edit my fstab to change my cygdrive prefix and then do a "mount -a", my 
>> mounts
>> as shown by the mount command or catting mtab are not updated. I only tried 
>> it with
>> the cygdrive prefix, not with other mounts.
>
> The cygdrive prefix is explicitely ignored when calling mount -a.
> The problem is, I'm not sure anymore *why* I did it that way.
> I added it to my TODO list, at least to figure out the reason...
>
>
> Thanks,
> Corinna
>
Hi Corinna...
 
Did you figure out the reason?
 
It seems to me that one could change mount points in a disruptive way as easily 
as one
could change the cygdrive prefix. Both would then have a "don't do that to a 
running system"
requirement...restarting Cygwin would be required for either a disruptive 
prefix change
or disruptive mount change.
 
When you look at it, could you remove the inconsistant posix=0 from mount and 
mount -m
output for the prefix where posix=0 is the default.
 
Thanks,
 
...Karl   
_
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/171222985/direct/01/

--
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: Bash v4.0 does not respect $PATH

[Csaba Raduly]

On Tue, Dec 29, 2009 at 11:21 PM,  Neil Mowbray wrote:
> Folks,
>
> I need associative arrays so I got the bash 4.0 source, compiled it under
> cygwin and installed it in /usr/local/bin.
>
> I have ActiveState perl installed in /opt/perl which preceeds
> /usr/local/bin:/bin:/usr/bin
> on my path.  Using bash 4.0, 'which' says I should get ActiveState perl, but
> actual execution gives cygwin perl in /bin

Are you sure PATH is the same in bash 3 and 4? You only showed the
PATH from bash 4.
Just out of curiosity, what does

perl -e 'print $^X'

print in those two situations? Also, try running

for i in $(echo $PATH | sed -r -e "s/:/ /g"); do ls -l $i/perl; done

in both shells.


-- 
Life is complex, with real and imaginary parts

--
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: make-3.81-4

[Edward Lam]

On Tue, December 29, 2009 19:09, Rob Walker wrote:
>
> Here are links to the patches I've applied to construct this package:
>
>   http://lists.gnu.org/archive/html/make-w32/2006-09/msg00037.html
>   http://lists.gnu.org/archive/html/make-w32/2007-12/msg00015.html
>

Ah, ok, the patches are already accepted upstream and exist in the GNU
Make trunk baseline. So all that remains is for GNU Make 3.82 to be
publicly released, and then updated downstream in cygwin. I think the best
we can hope for is to recompile cygwin's make with HAVE_DOS_PATHS defined
one day without manual patching. :)

Regards,
-Edward


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

High CPU consumption with git tab completion in zsh

[Steven E. Harris]

I've noticed that using tab completion with git in zsh often causes zsh
to consume 100% of my CPU for around ten minutes before the completion
request completes. The zsh completion commands look rather old:

,
| % ls -l /usr/share/zsh/4.3.9/functions | egrep git
| -rwxr-x---+ 1 seh Users618 2008-11-25 19:45 VCS_INFO_detect_git
| -rwxr-x---+ 1 seh Users   2959 2008-11-25 19:45 VCS_INFO_get_data_git
| -rwxr-x---+ 1 seh Users 163034 2008-11-25 19:45 _git
| -rwxr-x---+ 1 seh Users   2301 2008-11-25 19:45 _stgit
| -rwxr-x---+ 1 seh Users144 2008-11-25 19:45 run-help-git
`

Is this the right place to report such a problem in more detail, or do I
need to contact the git mailing list, or maybe the zsh mailing list?

-- 
Steven E. Harris


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

Defeated by "alternatives": unison

[Steven E. Harris]

Since updating my Cygwin installation to version 1.7, I can no longer
run "unison" from the command line. Unison uses the "alternatives"
facility to select among multiple installed versions. The symbolic links
all look to be set up properly, but the program can't be invoked in the
normal ways.

I've tried this same sequence of commands using the shells zsh, bash,
and ash, and all fail in the same way.

Witness:

,
| % which unison
| unison not found
| 
| % /usr/sbin/alternatives --display unison
| unison - status is manual.
|  link currently points to /usr/bin/unison-2.27
| /usr/bin/unison-2.32 - priority 2032
| /usr/bin/unison-2.27 - priority 2027
| Current `best' version is /usr/bin/unison-2.32.
| 
| % ls -l /usr/bin/unison*
| -rwxr-xr-x 1 seh root 1076224 2009-10-01 11:27 /usr/bin/unison-2.27.exe
| -rwxr-xr-x 1 seh root 1123840 2009-10-01 11:31 /usr/bin/unison-2.32.exe
| lrwxrwxrwx 1 seh None  28 2005-03-24 22:09 /usr/bin/unison.exe ->
|/etc/alternatives/unison.exe
| 
| torus:~% /usr/bin/unison
| zsh: no such file or directory: /usr/bin/unison
| 
| % /usr/bin/unison.exe
| zsh: no such file or directory: /usr/bin/unison.exe
| 
| % /etc/alternatives/unison
| Usage: unison [options]
| or unison root1 root2 [options]
| or unison profilename [options]
| 
| For a list of options, type "unison -help".
| For a tutorial on basic usage, type "unison -doc tutorial".
| For other documentation, type "unison -doc topics".
`

I used to just be able to type "unison" at the command prompt and invoke
it like any other program. Is this a permissions problem? I have found
that other programs using the "alternatives" facility work as
expected. Why is "unison" different?

[I've tried posting this message with the cygcheck output attached, but
 the messages get rejected.]

-- 
Steven E. Harris


--
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: Defeated by "alternatives": unison

[Larry Hall (Cygwin)]

On 12/29/2009 09:28 PM, Steven E. Harris wrote:

Since updating my Cygwin installation to version 1.7, I can no longer
run "unison" from the command line. Unison uses the "alternatives"
facility to select among multiple installed versions. The symbolic links
all look to be set up properly, but the program can't be invoked in the
normal ways.

I've tried this same sequence of commands using the shells zsh, bash,
and ash, and all fail in the same way.

Witness:

,
| % which unison
| unison not found
|
| % /usr/sbin/alternatives --display unison
| unison - status is manual.
|  link currently points to /usr/bin/unison-2.27
| /usr/bin/unison-2.32 - priority 2032
| /usr/bin/unison-2.27 - priority 2027
| Current `best' version is /usr/bin/unison-2.32.
|
| % ls -l /usr/bin/unison*
| -rwxr-xr-x 1 seh root 1076224 2009-10-01 11:27 /usr/bin/unison-2.27.exe
| -rwxr-xr-x 1 seh root 1123840 2009-10-01 11:31 /usr/bin/unison-2.32.exe
| lrwxrwxrwx 1 seh None  28 2005-03-24 22:09 /usr/bin/unison.exe ->
|/etc/alternatives/unison.exe
|
| torus:~% /usr/bin/unison
| zsh: no such file or directory: /usr/bin/unison
|
| % /usr/bin/unison.exe
| zsh: no such file or directory: /usr/bin/unison.exe
|
| % /etc/alternatives/unison
| Usage: unison [options]
| or unison root1 root2 [options]
| or unison profilename [options]
|
| For a list of options, type "unison -help".
| For a tutorial on basic usage, type "unison -doc tutorial".
| For other documentation, type "unison -doc topics".
`

I used to just be able to type "unison" at the command prompt and invoke
it like any other program. Is this a permissions problem? I have found
that other programs using the "alternatives" facility work as
expected. Why is "unison" different?


WJFFM.  Try looking at your file permissions to see if you can find anything
revealing.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

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

Can't use key authentication on x64 Server 2003 R2

[Gordon Messmer]

Since upgrading to Cygwin 1.7, I'm no longer able to use key 
authentication on one of several Windows systems.  All of the working 
systems are 32 bit installs, the one which isn't working is 64 bit.


The problem only affects key authentication.  Password authentication 
still works properly.


To minimize variables, I started by removing Cygwin entirely from this 
host.  I deleted C:\cygwin, removed the old sshd and sshd_server user 
accounts, and removed those accounts' rights in the Local Security 
Policy tool.  Cygwin was then installed again.


I don't think it matters, but I also noticed that all of these hosts are 
domain members.  All of the other (working) hosts opted to use the sshd 
and sshd_server domain accounts, while the failing host is using local 
accounts.  I'm not sure how Cygwin interacts with Windows when creating 
accounts, and what would cause it to use domain accounts on some hosts 
but local accounts on others.  I previously tried removing the local 
accounts and using mkpasswd.exe to load the domain accounts into 
/etc/passwd.  That attempt also failed, but in a completely different 
manner.  ssh-host-config complained that the local SAM didn't recognize 
the accounts or something like that.  I can do so again if that 
information is wanted.


When the client connects, I get this error:

   # ssh -i id_rsa gor...@exch64.xxx.local
   Last login: Tue Dec 29 13:17:34 2009 from backup.xxx.local
  1 [main] -bash 6832 C:\cygwin\bin\bash.exe: *** fatal error -
   couldn't dynamically determine load address for 'WSAGetLastError'
   (handle 0x), Win32 error 126
   Connection to exch64.xxx.local closed.

Event viewer records an apparent success:

   The description for Event ID ( 0 ) in Source ( sshd ) cannot be
   found. The local computer may not have the necessary registry
   information or message DLL files to display messages from a remote
   computer. You may be able to use the /AUXSOURCE= flag to retrieve
   this description; see Help and Support for details. The following
   information is part of the event: sshd: PID 5872: Accepted publickey
   for gordon from 192.168.99.4 port 49012 ssh2.

The output of "cygcheck -s -v -r" and "ssh-host-config" are attached. 
Please let me know if there is any additional information that I can 
provide to help diagnose and correct the problem.

Cygwin Configuration Diagnostics
Current System Time: Tue Dec 29 13:22:34 2009

Windows 2003 Server R2 Ver 5.2 Build 3790 Service Pack 2

Running under WOW64 on AMD64

Running in Terminal Service session

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\Program Files\Support Tools\
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\ATI Technologies\ATI Control Panel\
C:\WINDOWS\system32\WindowsPowerShell\v1.0
C:\Program Files\Microsoft\Exchange Server\bin
C:\Program Files\Microsoft\Exchange Server\Scripts
C:\WINDOWS\sysWOW64
C:\Program Files (x86)\ExchangeMapi\

Output from C:\cygwin\bin\id.exe
UID: 11287(gordon)  GID: 10513(Domain Users)
0(root)  544(Administrators)  545(Users)
10513(Domain Users)

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

USER = 'gordon'
PWD = '/home/gordon'
CYGWIN = 'tty'
HOME = '/home/gordon'

HOMEPATH = '\Documents and Settings\gordon.XX'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Documents and Settings\gordon.XX\Application Data'
ProgramW6432 = 'C:\Program Files'
HOSTNAME = 'EXCH64'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'EM64T Family 6 Model 15 Stepping 11, GenuineIntel'
WINDIR = 'C:\WINDOWS'
OLDPWD = '/etc/skel'
USERDOMAIN = 'XX'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files'
USERNAME = 'gordon'
ClusterLog = 'C:\WINDOWS\Cluster\cluster.log'
PROCESSOR_LEVEL = '6'
ProgramFiles(x86) = 'C:\Program Files (x86)'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
PROCESSOR_ARCHITEW6432 = 'AMD64'
LANG = 'C.UTF-8'
USERPROFILE = 'C:\Documents and Settings\gordon.XX'
CLIENTNAME = 'herald'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\EXCH'
CommonProgramW6432 = 'C:\Program Files\Common Files'
PROCESSOR_ARCHITECTURE = 'x86'
!C: = 'C:\cygwin\bin'
SHLVL = '1'
USERDNSDOMAIN = 'XX.LOCAL'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1'
HOMEDRIVE = 'C:'
PROMPT = '$P$G'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
SYSTEMROOT = 'C:\WINDOWS'
PRINTER = 'Microsoft XPS Document Writer'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '0f0b'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files (x86)'
NUMBER_OF_PROCESSORS = '4'
SESSIONNAME = 'RDP-Tcp#10'
COMPUTERNAME = 'EXCH64'
_ = '/usr/bin/cygcheck.exe'

HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKE

Goldstar please (Re: [ANNOUNCEMENT] Updated: xinit-1.2.0-2)

[Christopher Faylor]

On Tue, Dec 29, 2009 at 07:31:07PM -0500, Charles Wilson wrote:
>Yaakov (Cygwin/X) wrote:
>> On 29/12/2009 16:27, Charles Wilson wrote:
>>> Sounds like a good idea, but I wish I'd known this was coming before
>>> wasting time on:
>>>
>>>  * Improve checkX behavior when used as 'barrier' in startxwin.
>> 
>> Sorry about that, Chuck, but this was just the latest of a long string
>> of issues involving these scripts.  We've been talking about replacing
>> them for a while, and the recent traffic on the list was enough of an
>> impetus to make me finally stop bandaging the scripts and find a better
>> solution.  Plus, we gain argument handling and .startxwinrc, something
>> the scripts would likely never do.
>
>Like I said, it sounds to me like a good idea; there's just so many
>issues that can go (and have gone) wrong in these scripts -- PLUS, whose
>idea was it to have TWO, one .sh and one .bat?!!?  Yeeesh.  We're well
>rid of them.

Yes, in fact, I think this deserves a gold star.  These things have been
a pain in the neck for years.

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