Re: Fwd: 1.7.1 setup mirrors list is empty

[Marc Girod]

Marc Girod wrote:
> 
> Setup stays in download mode (setup.bz2), empty progress bar,
> now from sunet.se as well as all the others.
> 
And suddenly it started to work again from heanet.ie.
Thanks,
Marc
-- 
View this message in context: 
http://old.nabble.com/Fwd%3A-1.7.1-setup-mirrors-list-is-empty-tp27830001p27832666.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Problems installing Text-Iconv-1.7 (perl module)

[Marc Girod]

As part of Net::LDAP, I try to install Text-Iconv-1.7, and it fails.
I installed libiconv (I already had libiconv2), but 'perl Makefile.PL' has a
comiple test which fails.
I reproduced on the command line, removing the redirections to /dev/null:

Text-Iconv-1.7> gcc -I/usr/include -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include 
-Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608
-Wl,--enable-auto-image-base -fstack-protector -L/usr/local/lib -L/usr/lib
-o linktest linktest.c -L/usr/lib
cc1: error: unrecognized command line option "-fstack-protector"
cc1: error: unrecognized command line option "-fstack-protector"
Text-Iconv-1.7> gcc -I/usr/include -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
-fno-strict-aliasing -pipe -I/usr/local/include  -Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base
-L/usr/local/lib -L/usr/lib -o linktest linktest.c -L/usr/lib
/cygdrive/c/Users/emagiro/AppData/Local/Temp/ccqJIK6Z.o:linktest.c:(.text+0x3a):
undefined reference to `_libiconv_open'
collect2: ld returned 1 exit status
Text-Iconv-1.7> strings /usr/lib/libiconv.a | grep libiconv_open
_libiconv_open
_libiconv_open_into
_libiconv_open
_libiconv_open_into

???

Marc
-- 
View this message in context: 
http://old.nabble.com/Problems-installing-Text-Iconv-1.7-%28perl-module%29-tp27833019p27833019.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: User Guide Suggestion

[Corinna Vinschen]

On Mar  8 07:58, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Corinna Vinschen sent the following at Friday, March 05, 2010 10:44 AM
> >On Mar 5 09:00, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> >>> On , a link from the 
> >>> discussion of CYGWIN to 
> >>>  would be 
> >>> convenient.
> >
> >Done.
> 
> Corinna,
> 
> I don't see it on the page.  The only link I see is  "Internationalization">.

It's in CVS only for now.


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: Problems installing Text-Iconv-1.7 (perl module)

[Corinna Vinschen]

On Mar  9 01:03, Marc Girod wrote:
> 
> As part of Net::LDAP, I try to install Text-Iconv-1.7, and it fails.
> I installed libiconv (I already had libiconv2), but 'perl Makefile.PL' has a
> comiple test which fails.
> I reproduced on the command line, removing the redirections to /dev/null:
> 
> Text-Iconv-1.7> gcc -I/usr/include -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
> -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include 
> -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608
> -Wl,--enable-auto-image-base -fstack-protector -L/usr/local/lib -L/usr/lib
> -o linktest linktest.c -L/usr/lib
> cc1: error: unrecognized command line option "-fstack-protector"
> cc1: error: unrecognized command line option "-fstack-protector"
> Text-Iconv-1.7> gcc -I/usr/include -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
> -fno-strict-aliasing -pipe -I/usr/local/include  -Wl,--enable-auto-import
> -Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base
> -L/usr/local/lib -L/usr/lib -o linktest linktest.c -L/usr/lib
> /cygdrive/c/Users/emagiro/AppData/Local/Temp/ccqJIK6Z.o:linktest.c:(.text+0x3a):
> undefined reference to `_libiconv_open'
> collect2: ld returned 1 exit status
> Text-Iconv-1.7> strings /usr/lib/libiconv.a | grep libiconv_open
> _libiconv_open
> _libiconv_open_into
> _libiconv_open
> _libiconv_open_into
> 
> ???

There's no -liconv.


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: Cygwin 1.7: Concurrency Issue with Shared State Initialization

[Schmidt, Oliver]

Hi Christopher,

Fist of all thanks for your immediate feedback :-)

>>/* Initialize installation root dir. */
>> if (!installation_root[0])
>>   init_installation_root ();

> I'll check in something tonight which attempts to solve this problem.

Thanks in advance.

> It's a somewhat tricky problem because adding a mutex here would slow
> down every invocation of a cygwin program and we don't want to add to
> the "Why is Cygwin so slow???" scenarios if we can help it.

I understand your concern for sure ;-)

Maybe that's the very thing you're thinking about but ... AFAIK a spinlock is 
the usual paradigm in scenarios where one doesn't anticipate contention but 
needs to be aware of it 'just in case'. With InterlockedCompareExchange() and 
Sleep() it should be quite simple to create one that's very efficient in the 
usual scenario.

Regards, Oliver

--
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: gcc cannot find stdio.h

[Csaba Raduly]

On Mon, Mar 8, 2010 at 11:37 PM, Jacob Jacobson  wrote:
> I am unable to run gcc. I keep getting stdio.h: No such file.

Hi Jacob,
What is the output of

gcc-4 -v hello.c

and the output of

find /usr/include -name stdio.h -ls

-- 
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: Cygwin 1.7: Concurrency Issue with Shared State Initialization

[Christopher Faylor]

On Tue, Mar 09, 2010 at 12:36:08PM +0100, Corinna Vinschen wrote:
>On Mar  9 11:08, Schmidt, Oliver wrote:
>> Hi Christopher,
>> 
>> Fist of all thanks for your immediate feedback :-)
>> 
>> >>/* Initialize installation root dir. */
>> >> if (!installation_root[0])
>> >>   init_installation_root ();
>> 
>> > I'll check in something tonight which attempts to solve this problem.
>> 
>> Thanks in advance.
>> 
>> > It's a somewhat tricky problem because adding a mutex here would slow
>> > down every invocation of a cygwin program and we don't want to add to
>> > the "Why is Cygwin so slow???" scenarios if we can help it.
>> 
>> I understand your concern for sure ;-)
>> 
>> Maybe that's the very thing you're thinking about but ... AFAIK a
>> spinlock is the usual paradigm in scenarios where one doesn't
>> anticipate contention but needs to be aware of it 'just in case'. With
>> InterlockedCompareExchange() and Sleep() it should be quite simple to
>> create one that's very efficient in the usual scenario.
>
>Does the below patch fix this for you?

I really do have a patch sitting in my sandbox.  I just forgot to test it
last night.

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 1.7: Concurrency Issue with Shared State Initialization

[Corinna Vinschen]

On Mar  9 11:08, Schmidt, Oliver wrote:
> Hi Christopher,
> 
> Fist of all thanks for your immediate feedback :-)
> 
> >>/* Initialize installation root dir. */
> >> if (!installation_root[0])
> >>   init_installation_root ();
> 
> > I'll check in something tonight which attempts to solve this problem.
> 
> Thanks in advance.
> 
> > It's a somewhat tricky problem because adding a mutex here would slow
> > down every invocation of a cygwin program and we don't want to add to
> > the "Why is Cygwin so slow???" scenarios if we can help it.
> 
> I understand your concern for sure ;-)
> 
> Maybe that's the very thing you're thinking about but ... AFAIK a
> spinlock is the usual paradigm in scenarios where one doesn't
> anticipate contention but needs to be aware of it 'just in case'. With
> InterlockedCompareExchange() and Sleep() it should be quite simple to
> create one that's very efficient in the usual scenario.

Does the below patch fix this for you?

* shared.cc (installation_root_init): New DLL-shared variable.
(inst_root_inited): Remove.
(init_installation_root): Drop setting inst_root_inited.
(memory_init): Make inst_root_inited locale variable here.
Only try to initialize installation_root if parent is a non-Cygwin
process.  Guard initialization with spinlock.

Index: shared.cc
===
RCS file: /cvs/src/src/winsup/cygwin/shared.cc,v
retrieving revision 1.130
diff -u -p -r1.130 shared.cc
--- shared.cc   18 Dec 2009 20:32:04 -  1.130
+++ shared.cc   9 Mar 2010 11:31:12 -
@@ -34,10 +34,10 @@ user_info NO_COPY *user_shared;
 HANDLE NO_COPY cygwin_shared_h;
 HANDLE NO_COPY cygwin_user_h;
 
+LONG installation_root_init __attribute__((section (".cygwin_dll_common"), 
shared));
 WCHAR installation_root[PATH_MAX] __attribute__((section 
(".cygwin_dll_common"), shared));
 UNICODE_STRING installation_key __attribute__((section (".cygwin_dll_common"), 
shared));
 WCHAR installation_key_buf[18] __attribute__((section (".cygwin_dll_common"), 
shared));
-static bool inst_root_inited;
 
 /* Use absolute path of cygwin1.dll to derive the Win32 dir which
is our installation_root.  Note that we can't handle Cygwin installation
@@ -115,8 +115,6 @@ init_installation_root ()
   installation_key.Length = 0;
   installation_key.Buffer[0] = L'\0';
 }
-
-  inst_root_inited = true;
 }
 
 /* This function returns a handle to the top-level directory in the global
@@ -412,19 +410,29 @@ shared_info::initialize ()
 void
 memory_init (bool init_cygheap)
 {
+  bool inst_root_inited = false;
+
   getpagesize ();
 
-  /* Initialize the Cygwin heap, if necessary */
+  /* Initialize the Cygwin heap.  This is only necessary if the process is
+ started from a non-Cygwin process. */
   if (init_cygheap)
 {
   cygheap_init ();
   cygheap->user.init ();
+  /* Initialize installation root dir. */
+  LONG init = InterlockedCompareExchange (&installation_root_init, 1L, 0L);
+  if (!init)
+   {
+ init_installation_root ();
+ inst_root_inited = true;
+ InterlockedIncrement (&installation_root_init);
+   }
+  else
+   while (installation_root_init == 1L)
+ low_priority_sleep (0);
 }
 
-  /* Initialize installation root dir. */
-  if (!installation_root[0])
-init_installation_root ();
-
   /* Initialize general shared memory */
   shared_locations sh_cygwin_shared;
   cygwin_shared = (shared_info *) open_shared (L"shared",


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: terminals getting killed on parent's termination

[Thomas Wolff]

Andy Koppe wrote:

Thomas Wolff:
   

In general, a GUI application started in the background, like a terminal,
should detach itself from its parent process so that it survives if the
parent is terminated.
 

Says who?
   

Common practice in Unix/Linux/X environments.
 

I've finally got round to trying to confirm this on Linux, and the
results make me wonder what exactly you are basing this assertion on.
Out of the terminals I tried, xterm and urxvt ignored SIGHUP, whereas
rxvt, konsole, gnome-terminal, and lxterminal terminated. Among a
bunch of other GUI apps, only gvim ignored SIGHUP, whereas firefox,
gimp, abiword, konqueror and others all terminated.
   

Thanks for this more extensive survey, comments below.


And user expectation that an
interactive session (which may e.g. contain an editing session with unsaved
changes...) should not be aborted by an unrelated event.
 

You do have a point there (which is why mintty has the warning when
it's closed with background processes running). Closing the terminal
that a program was started from is not a completely unrelated event,
though, and there might well be users that do expect everything to
quit in that case. In other words, you don't help your case by stating
opinion as fact and ignoring the other side of an argument.
   
Well, I didn't mean "should" as stating a fact but more as a request for 
discussion (contributors welcome).
(Maybe one *should* be aware that the usage of "SHOULD" in RFCs may have 
somewhat tweaked the perception of "should" in computing language,

or I might have added an IMHO attribute :-) )

Concerning

Closing the terminal that a program was started from is not a completely 
unrelated event,
this is also a matter of taste and use case but just using a command 
line to *start* an application does not indicate the intent that the 
command line should continue to *host* the application in the sense of a 
session.


My case is that sturdiness of an application against external impact is 
the more desirable the more interactive and potentially unsaved data it 
maintains.
This is not so much the case with browsers but at least firefox has 
introduced the feature of "Restore session" as a remedy in case it gets 
killed.

It is more the case for a shell session and even more for an editor.
Your survey above may also be interpreted this way: the most established 
terminals (xterm, rxvt-unicode) do maintain this stability, while some 
"newcomers" don't care (yet).
Among editors, apparently gvim supports my point, while emacs, gimp, 
abiword don't - but that can also just mean the issue has not received 
common awareness by now.



2. Manual termination of a terminal with a window manager operation (like
clicking the Close X button, selecting Close from the menu, pressing
Alt-F4).
In the case of a Windows application, this is a WM_CLOSE message being
handled (not a HUP as I had assumed).
If the direct child process of the terminal explicitly catches HUP, the
terminal should not terminate. It should just send HUP to its child and then
terminate only if the child terminates (overriding a "hold after command
terminates" option in this case, so the option can be reset when handling
this).
 

Here we go again.

My little survey showed that xterm is the only terminal that does
things that way; all the others notify the child and quit immediately.
   
Maybe that's why xterm is still the mainstream terminal in the X world? 
(+ IMHO + ;-) )



It also works with mintty but only once, due to the 'killed' flag in the
function child_kill in child.c
 

Funnily enough, this was a deliberate design decision, i.e., a
compromise between the two approaches. Unlike rxvt et al., it does
allow an application to say bye and prompt about unsaved data. Yet
unlike with xterm, a misbehaving application won't stop the user from
closing the terminal, because guess who'd be blamed for that.
   
A well-considered approach; however, since mintty is the only terminal 
that applies this compromise, applications cannot assume this as a 
protocol, so I doubt there is much use case.
Actually I noticed xterm also implements a useful compromise: With a 
window manager close event (Click "X", Alt-F4) it behaves as I had 
described, with "Quit" from its own menu, on the other hand, it always 
quits, thus avoiding the problem of an "unkillable" terminal.


Finally, let me discuss again my use case of embedding an application 
into a terminal ("container" model): the "HUP-delegate" protocol that I 
favour would enable a text-based command-line application to raise 
itself to a desktop application, including the option of implementing 
any application-specific "Really exit?" or "Save first?" behaviour. This 
would be another great feature of the terminal.

So please consider again these two options:
* Follow xterm like this: Apply "HUP-delegate" (i.e. forward HUP, leave 
quit decision to application) to the top-right Close button ("X"), and 
quit on

Re: Strange symlink behaviour

[Alfred von Campe]

Here is an update from my experiments (sorry for the delay).  As  
Corinna explained, symlinks created in Cygwin are only recognized by  
Cygwin, so what I wanted to do wasn't really possible.  However, we  
still wanted to be able to update the share from Windows (a GUI  
application was written for the operator to update the share when a  
new release is available), so I really wanted to figure out a way to  
make this work on Windows.  The solution was to use hard links in the  
tar file (which doesn't use up any more space), and when it was  
untar'ed on Windows, everything worked as expected.


Thanks for all the help,
Alfred


--
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: User Guide Suggestion

[Buchbinder, Barry (NIH/NIAID) [E]]

Corinna Vinschen sent the following at Tuesday, March 09, 2010 5:00 AM
>On Mar 8 07:58, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>> Corinna Vinschen sent the following at Friday, March 05, 2010 10:44 AM
>> >On Mar 5 09:00, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>> I don't see it on the page.  The only link I see is > "Internationalization">.
>
>It's in CVS only for now.

Thanks for the explanation in answer to a stupid question.  I had thought
that it must have not propagated to the server and but I didn't realized
that that could be normal.

And thank you for all the work you do for cygwin.

- Barry

--
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: Shared home dir, samba, and workgroups

[Marco Atzeri]

--- Mar 9/3/10, Wes Barris  ha scritto:

> Marco Atzeri wrote:
> > --- Mar 9/3/10, Wes Barris ha scritto:
> > 
> >> Wes Barris wrote:
> >>> I use Cygwin 1.7 on my XP desktop system at
> >> work.  I like having the
> >>> same home directory on this Windows XP system
> as I do
> >> on our Unix
> >>> server.  The Windows XP system is a
> member of a
> >> domain.  The Unix
> >>> server is not.  The Unix server is
> running Samba
> >> and is configured
> >>> with a workgroup name.  My home directory
> on the
> >> Unix server is
> >>> mounted as a mapped network drive on the
> Windows XP
> >> system.
> >>> Everything in the above setup is working
> >>> properly from the Unix server side and from
> the
> >> Windows side when
> >>> working with Windows Explorer.  I can
> create and
> >> delete files via
> >>> Windows Explorer and they show up on the Unix
> side
> >> with proper
> >>> ownership and permissions (as controlled by
> >> Samba).  Conversely,
> >>> I can create and delete files under Unix and
> access
> >> these files
> >>> from Windows Explorer.
> >>> 
> >>> The problem is when I look at my mapped
> network home
> >> directory
> >>> with Cygwin, my home directory files are owned
> by
> >> nobody ('')
> >>> and have a group of nobody.  I am
> guessing that
> >> this is because my
> >>> Windows SID in /etc/passwd is the SID of my
> domain
> >> user and since
> >>> the Samba server is not part of this domain
> the files
> >> look like they
> >>> are from an unknown user.
> >>> 
> >>> In our Samba server there is a file (usermap)
> that
> >> maps unix usernames
> >>> to windows usernames.  This appears to be
> working
> >> when working with
> >>> Windows Explorer.  Why doesn't this work
> with
> >> Cygwin?  What is the
> >>> way to fix this?  Do I somehow need to
> map my
> >> unix username to a
> >>> windows SID?  Do I need to turn off
> ntsec? 
> > 
> > you need to map the WINDOWS SID to the UNIX username
> > 
> > so you need to add on /etc/passwd and etc/group
> > the right references.
> > 
> > see:
> > http://cygwin.com/cygwin-ug-net/using-utils.html#mkpasswd
> > http://cygwin.com/cygwin-ug-net/ntsec.html
> 
> I've read both of those pages many times.  They don't
> appear
> to apply to my situation.  What mkpasswd option(s)
> would you
> suggest?  --local doesn't help map the Windows SID to
> the UNIX
> username, --domain doesn't do it.

Web,
if mkpasswd can not help you to identify the SID, than
you can try Setacl
http://setacl.sourceforge.net/

using as:
$ SetACL.exe -on $(cygpath -aw YOUR_FILE) -ot file -actn list -lst 
"f:sddl;w:o,g,s,d"

will provide the full list of SID and ACL of the file 
or directory. The answer is a bit cryptic but it is very detailed. 

After that you can create,by hand, the right reference in
your 
/etc/passwd and /etc/group 

> 
> >> Do I need to change
> >>> the mount options for /cygdrive?
> >> Should I assume from the lack of any response that
> there is
> >> no fix
> >> for this?
> >> 
> >> -- Wes Barris
> > 
> > I should say no
> > Marco
> 
> -- Wes Barris

Marco





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

[ANNOUNCEMENT] Updated: OpenSSH-5.4p1-1

[Corinna Vinschen]

I've just updated the Cygwin version of OpenSSH to 5.4p1-1.

This is a new major upstream release.  The Cygwin release is created
from the vanilla sources.  It contains two Cygwin-specific changes
which haven't been mentioned in the official release message:

* When logging in via ssh into a Cygwin box, you must login with your
  username given in the exact same case as specified in /etc/passwd now.
  If your username in /etc/passwd is "foo", you can no longer login with
  the name "FOO" or "Foo".  This is the fix for a security problem where
  caseinsensitive usernames allowed to break out of user matches in the
  sshd configuration file.

* The environment variables propagated from sshd to the child login
  process have been reduced.  Especially TMP and TEMP are no longer
  propagated since that could result in permission problems when trying
  to create temporary files in the child process tree.

The official release message of 5.4p1:


OpenSSH 5.4 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed code
or patches, reported bugs, tested snapshots or donated to the project.
More information on donations may be found at:
http://www.openssh.com/donations.html

This is a major feature and bugfix release.

Changes since OpenSSH 5.3
=

Features:

 * After a transition period of about 10 years, this release disables
   SSH protocol 1 by default. Clients and servers that need to use the
   legacy protocol must explicitly enable it in ssh_config / sshd_config
   or on the command-line.

 * Remove the libsectok/OpenSC-based smartcard code and add support for
   PKCS#11 tokens. This support is automatically enabled on all
   platforms that support dlopen(3) and was inspired by patches written
   by Alon Bar-Lev. Details in the ssh(1) and ssh-add(1) manpages.

 * Add support for certificate authentication of users and hosts using a
   new, minimal OpenSSH certificate format (not X.509). Certificates
   contain a public key, identity information and some validity
   constraints and are signed with a standard SSH public key using
   ssh-keygen(1). CA keys may be marked as trusted in authorized_keys
   or via a TrustedUserCAKeys option in sshd_config(5) (for user
   authentication), or in known_hosts (for host authentication).

   Documentation for certificate support may be found in ssh-keygen(1),
   sshd(8) and ssh(1) and a description of the protocol extensions in
   PROTOCOL.certkeys.

 * Added a 'netcat mode' to ssh(1): "ssh -W host:port ..." This connects
   stdio on the client to a single port forward on the server. This
   allows, for example, using ssh as a ProxyCommand to route connections
   via intermediate servers. bz#1618

 * Add the ability to revoke keys in sshd(8) and ssh(1). User keys may
   be revoked using a new sshd_config(5) option "RevokedKeys". Host keys
   are revoked through known_hosts (details in the sshd(8) man page).
   Revoked keys cannot be used for user or host authentication and will
   trigger a warning if used.

 * Rewrite the ssh(1) multiplexing support to support non-blocking
   operation of the mux master, improve the resilience of the master to
   malformed messages sent to it by the slave and add support for
   requesting port- forwardings via the multiplex protocol. The new
   stdio-to-local forward mode ("ssh -W host:port ...") is also
   supported. The revised multiplexing protocol is documented in the
   file PROTOCOL.mux in the source distribution.

 * Add a 'read-only' mode to sftp-server(8) that disables open in write
   mode and all other fs-modifying protocol methods. bz#430

 * Allow setting an explicit umask on the sftp-server(8) commandline to
   override whatever default the user has. bz#1229

 * Many improvements to the sftp(1) client, many of which were
   implemented by Carlos Silva through the Google Summer of Code
   program:
   - Support the "-h" (human-readable units) flag for ls
   - Implement tab-completion of commands, local and remote filenames
   - Support most of scp(1)'s commandline arguments in sftp(1), as a
 first step towards making sftp(1) a drop-in replacement for scp(1).
 Note that the rarely-used "-P sftp_server_path" option has been
 moved to "-D sftp_server_path" to make way for "-P port" to match
 scp(1).
   - Add recursive transfer support for get/put and on the commandline

 * New RSA keys will be generated with a public exponent of RSA_F4 ==
   (2**16)+1 == 65537 instead of the previous value 35.

 * Passphrase-protected SSH protocol 2 private keys are now protected
   with AES-128 instead of 3DES. This applied to newly-gen

Re: 1.7.1-1: ImageMagick seems to lack jpeg support

[Nick White]

> I too have never seen that notation (although it may work).

Imagemagick does have a lot of options; -geometry has always worked 
for me, and I hadn't found -resize.

I tried convert test.jpg -resize 600x test-out.jpg 

with several different jpegs, including ones I'm sure are good, and 
got exactly the same results.

I wonder if this may be a problem with my install of cygwin, then (I 
did have a problem where the computer died mid-cygwin upgrade 
[thanks Windows!], and I'm not positive everything recovered).  I'm 
pleased to hear it's working for others, I'll persevere.

Thanks,

Nick

--
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: Concurrency Issue with Shared State Initialization

[Christopher Faylor]

On Tue, Mar 09, 2010 at 10:18:27AM -0500, Christopher Faylor wrote:
>On Tue, Mar 09, 2010 at 12:36:08PM +0100, Corinna Vinschen wrote:
>>On Mar  9 11:08, Schmidt, Oliver wrote:
>>> Hi Christopher,
>>> 
>>> Fist of all thanks for your immediate feedback :-)
>>> 
>>> >>/* Initialize installation root dir. */
>>> >> if (!installation_root[0])
>>> >>   init_installation_root ();
>>> 
>>> > I'll check in something tonight which attempts to solve this problem.
>>> 
>>> Thanks in advance.
>>> 
>>> > It's a somewhat tricky problem because adding a mutex here would slow
>>> > down every invocation of a cygwin program and we don't want to add to
>>> > the "Why is Cygwin so slow???" scenarios if we can help it.
>>> 
>>> I understand your concern for sure ;-)
>>> 
>>> Maybe that's the very thing you're thinking about but ... AFAIK a
>>> spinlock is the usual paradigm in scenarios where one doesn't
>>> anticipate contention but needs to be aware of it 'just in case'. With
>>> InterlockedCompareExchange() and Sleep() it should be quite simple to
>>> create one that's very efficient in the usual scenario.
>>
>>Does the below patch fix this for you?
>
>I really do have a patch sitting in my sandbox.  I just forgot to test it
>last night.

And, as it turned out, it was a good thing that I had a night to sleep
on it.  I scrapped what I did yesterday and just piggybacked on the
already existing spinlock.  My previous attempt added additional testing
which wasn't really necessary.

http://cygwin.com/snapshots/ has what I hope is the fix for this.

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: Problems installing Text-Iconv-1.7 (perl module)

[Reini Urban]

On Mar  9 01:03, Marc Girod wrote:

Text-Iconv-1.7>  gcc -I/usr/include -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
-Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608
-Wl,--enable-auto-image-base -fstack-protector -L/usr/local/lib -L/usr/lib
-o linktest linktest.c -L/usr/lib
cc1: error: unrecognized command line option "-fstack-protector"


you need gcc-4

--
Reini Urban
http://phpwiki.org/  http://murbreak.at/

--
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: gcc cannot find stdio.h

[Jacob Jacobson]

Csaba Raduly wrote:

On Mon, Mar 8, 2010 at 11:37 PM, Jacob Jacobson  wrote:

I am unable to run gcc. I keep getting stdio.h: No such file.


Hi Jacob,
What is the output of

gcc-4 -v hello.c

and the output of

find /usr/include -name stdio.h -ls


[hello$:502] gcc-4 -v hello.c
Using built-in specs.
Target: i686-pc-cygwin
Configured with: 
/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4/configure 
--srcdir=/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4 
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin 
--libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var 
--sysconfdir=/etc --infodir=/usr/share/info --mandir=/usr/share/man 
--datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man 
-v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap 
--enable-version-specific-runtime-libs --with-slibdir=/usr/bin 
--libexecdir=/usr/lib --enable-static --enable-shared 
--enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld 
--with-gnu-as --with-dwarf2 --disable-sjlj-exceptions 
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --disable-symvers 
--enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp 
--enable-libada --enable-threads=posix --with-arch=i686 
--with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 
CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake 
GNATBIND_FOR_TARGET=gnatbind AS=/opt/gcc-tools/bin/as.exe 
AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe LD=/opt/gcc-tools/bin/ld.exe 
LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe 
--with-ecj-jar=/usr/share/java/ecj.jar

Thread model: posix
gcc version 4.3.4 20090804 (release) 1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i686'
 /bin/../lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe -quiet -v -iprefix 
/bin/../lib/gcc/i686-pc-cygwin/4.3.4/ -D__CYGWIN32__ -D__CYGWIN__ -Dunix 
-D__unix__ -D__unix -idirafter /usr/lib/../include/w32api -idirafter 
../../include/w32api hello.c -quiet -dumpbase hello.c -mtune=generic 
-march=i686 -auxbase hello -version -o /c/home/abiyani/tmp/ccwzZUAU.s
ignoring nonexistent directory 
"/bin/../lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/include"

ignoring nonexistent directory "/usr/local/include"
ignoring duplicate directory 
"/bin/../lib/gcc/../../lib/gcc/i686-pc-cygwin/4.3.4/include"
ignoring duplicate directory 
"/bin/../lib/gcc/../../lib/gcc/i686-pc-cygwin/4.3.4/include-fixed"
ignoring nonexistent directory 
"/bin/../lib/gcc/../../lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/include"

ignoring nonexistent directory "../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
 /bin/../lib/gcc/i686-pc-cygwin/4.3.4/include
 /bin/../lib/gcc/i686-pc-cygwin/4.3.4/include-fixed
 /usr/include
 /usr/lib/../include/w32api
End of search list.
GNU C (GCC) version 4.3.4 20090804 (release) 1 (i686-pc-cygwin)
compiled by GNU C version 4.3.4 20090804 (release) 1, GMP 
version 4.3.1, MPFR version 2.4.1-p5.

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d5cdab7e958df0270fe64611765e0bb6
hello.c:2:19: error: stdio.h: No such file or directory
hello.c:3:20: error: stdlib.h: No such file or directory
hello.c: In function 'main':
hello.c:7: warning: incompatible implicit declaration of built-in 
function 'printf'

[hello$:503]


--
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: gcc cannot find stdio.h

[Jacob Jacobson]

Larry Hall (Cygwin) wrote:

On 3/8/2010 5:37 PM, Jacob Jacobson wrote:

I am unable to run gcc. I keep getting stdio.h: No such file.


Try getting rid of the ~\... paths from your Windows path.

I notice a reference to MKS in your cygcheck output.  Make
sure MKS is completely hidden from Cygwin.



[hello$:513] echo $PATH
/c/gac2500/bin-xp:/usr/local/bin:/bin:/usr/bin:/usr/ucb:/sbin:/usr/sbin:
/usr/X11R6/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:
/c/win/cw:/c/winxp/sdks/v6.0A/bin:/c/windows/microsoft.net/framework/v2.0.50727
[hello$:514] gcc-4 hello.c
hello.c:2:19: error: stdio.h: No such file or directory
hello.c:3:20: error: stdlib.h: No such file or directory
hello.c: In function 'main':
hello.c:7: warning: incompatible implicit declaration of built-in 
function 'printf'

[hello$:515]


--
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: gcc cannot find stdio.h

[Jacob Jacobson]

Csaba Raduly wrote:

On Mon, Mar 8, 2010 at 11:37 PM, Jacob Jacobson  wrote:

I am unable to run gcc. I keep getting stdio.h: No such file.


Hi Jacob,
What is the output of

gcc-4 -v hello.c

and the output of

find /usr/include -name stdio.h -ls



[~$:501] cd /usr/include
/usr/include
[include$:502] find . -name stdio.h -ls
1688849860890593   12 -rw-r--r--   1 abiyani  Administrators22047 
Mar  6 21:18 ./mingw/stdio.h

[include$:503]


--
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: glib and gtk+

[Yaakov (Cygwin/X)]

http://cygwin.com/acronyms/#PCYMTWLL

On 2010-03-08 20:53, wynfi...@gmail.com wrote:

Whenever I run "setup" the "view" always shows me the following two

> packages as being needed to install.  I select to install them.
> Installing them seems to happen.


glib 1.2.10-10 bin? [x] src[ ]  glib ..funct lib (1.2 sources
gtk+ 1.2.10-10 bin? [x] src[ ]  gtk+ gui lib (1.2 sources)

But, whenever I run "setup" again the same pair of files come up.

> Note also that the x'd box [x] is in the "binary" column",
> but the description specifies "sources".

These are currently only source packages but each previously had a 
corresponding binary package which is still listed as a dependency of 
some other package in the distro, because the latter has yet to be 
updated by its maintainer since the renaming.  The binary packages are 
now named libglib1.2{_0,-devel} and libgtk1.2{_),-devel.


Whether or not setup.exe should handle this differently, I'll leave to 
the maintainers thereof, but just ignore these for now.



Yaakov

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

"can't create master tty" errors

[Cesar Crusius]

Hi all,

I am using Cygwin and SSH to do automated remote builds using Visual
C++. It works for a few days, but invariably things start failing with
messages like these (this one from a build log):

Makefile:9: MakePID: 5964
  1 [main] env 2748 C:\cygwin\bin\env.exe: *** fatal error - can't create 
master tty

At this point, even if I 'rdesktop' to the build machine and try to get
a console (by clicking "Cygwin" on the desktop) I get nothing: the
console window comes up, issues the above error, and exits (this all
very fast). Rebooting solves the problem for a while (restarting
cygserver/sshd doesn't do anything).

To the setup then:

The computer is joined to an AD domain, and the account under which the
builds are done is remote (uses shared folders). Since the build system
has to issue one 'NET USE' statement to map a drive (visual C++ doesn't
like UNC paths), we have cygserver running (under the SYSTEM account)
and the logon implemented using method 3 of
http://www.cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview

SSHD is running under the AD's administrator account, and the build
account logs in using PKA.

% uname -a
CYGWIN_NT-5.2 mv011 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin

% echo $CYGWIN
binmode tty ntsec

Any help would be greatly appreciated. (The build, when it works, is
very slow, but at this point I need to get it working first before
getting it to work fast...)

Best,

- 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

Re: gcc cannot find stdio.h

[Larry Hall (Cygwin)]

On 3/9/2010 9:53 AM, Jacob Jacobson wrote:

Csaba Raduly wrote:

On Mon, Mar 8, 2010 at 11:37 PM, Jacob Jacobson wrote:

I am unable to run gcc. I keep getting stdio.h: No such file.


Hi Jacob,
What is the output of

gcc-4 -v hello.c

and the output of

find /usr/include -name stdio.h -ls



[~$:501] cd /usr/include
/usr/include
[include$:502] find . -name stdio.h -ls
1688849860890593 12 -rw-r--r-- 1 abiyani Administrators 22047 Mar 6
21:18 ./mingw/stdio.h
[include$:503]


You are missing a few entries, though it's not clear why you don't have
them.  Reinstall the 'cygwin' package.


--
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: Strange symlink behaviour

[Larry Hall (Cygwin)]

On 3/9/2010 10:11 AM, Alfred von Campe wrote:

The solution was to use hard links in the tar file (which doesn't use up
any more space), and when it was untar'ed on Windows, everything worked

^
On NTFS partitions.  It will on any kind of FAT partition though.

as expected.



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

1.7 - Problem installing perl modules

[Robert Slater]

Hi there,

In the process of installing perl modules to get an IRC bot working
via cygwin, I'm encountering a
problem with make & installing ExtUtils::CBuilder and thus the modules
that depend upon it. The
make / install goes through fine, but cygwin doesn't seem to detect it
afterwards.

Attached is the cygcheck of my system, and a log of my attempt to
install the two modules.

Thanks for any help with this problem

-Robert
rob...@robert-pc ~
$ cd c:/modules/Params-Validate

rob...@robert-pc /cygdrive/c/modules/Params-Validate
$ perl Build.pl
cygwin warning:
  MS-DOS style path detected: \Users\Robert
  Preferred POSIX equivalent is: /cygdrive/c/Users/Robert
  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
  Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
cc1: error: unrecognized command line option "-fstack-protector"
cc1: error: unrecognized command line option "-fstack-protector"
Warning: ExtUtils::CBuilder not installed or no compiler detected
Proceeding with configuration, but compilation may fail during Build

Creating new 'MYMETA.yml' with configuration results
Creating new 'Build' script for 'Params-Validate' version '0.95'

rob...@robert-pc /cygdrive/c/modules/Params-Validate
$ ./Build
Building Params-Validate
Error: no compiler detected to compile 'lib/Params/Validate.c'.  Aborting

rob...@robert-pc /cygdrive/c/modules/Params-Validate
$ cd c:/modules/ExtUtils-CBuilder

rob...@robert-pc /cygdrive/c/modules/ExtUtils-CBuilder
$ perl makefile.pl
Checking if your kit is complete...
Looks good
Writing Makefile for ExtUtils::CBuilder

rob...@robert-pc /cygdrive/c/modules/ExtUtils-CBuilder
$ make
cp lib/ExtUtils/CBuilder.pm blib/lib/ExtUtils/CBuilder.pm
cp lib/ExtUtils/CBuilder/Platform/Windows.pm blib/lib/ExtUtils/CBuilder/Platform
/Windows.pm
cp lib/ExtUtils/CBuilder/Platform/aix.pm blib/lib/ExtUtils/CBuilder/Platform/aix
.pm
cp lib/ExtUtils/CBuilder/Platform/cygwin.pm blib/lib/ExtUtils/CBuilder/Platform/
cygwin.pm
cp lib/ExtUtils/CBuilder/Platform/Windows/GCC.pm blib/lib/ExtUtils/CBuilder/Plat
form/Windows/GCC.pm
cp lib/ExtUtils/CBuilder/Platform/VMS.pm blib/lib/ExtUtils/CBuilder/Platform/VMS
.pm
cp lib/ExtUtils/CBuilder/Platform/Unix.pm blib/lib/ExtUtils/CBuilder/Platform/Un
ix.pm
cp lib/ExtUtils/CBuilder/Platform/Windows/BCC.pm blib/lib/ExtUtils/CBuilder/Plat
form/Windows/BCC.pm
cp lib/ExtUtils/CBuilder/Platform/Windows/MSVC.pm blib/lib/ExtUtils/CBuilder/Pla
tform/Windows/MSVC.pm
cp lib/ExtUtils/CBuilder/Platform/darwin.pm blib/lib/ExtUtils/CBuilder/Platform/
darwin.pm
cp lib/ExtUtils/CBuilder/Platform/os2.pm blib/lib/ExtUtils/CBuilder/Platform/os2
.pm
cp lib/ExtUtils/CBuilder/Platform/dec_osf.pm blib/lib/ExtUtils/CBuilder/Platform
/dec_osf.pm
cp lib/ExtUtils/CBuilder/Base.pm blib/lib/ExtUtils/CBuilder/Base.pm
Manifying blib/man3/ExtUtils.CBuilder.Platform.Windows.3pm
Manifying blib/man3/ExtUtils.CBuilder.3pm

rob...@robert-pc /cygdrive/c/modules/ExtUtils-CBuilder
$ make test
PERL_DL_NONLAZY=1 /usr/bin/perl.exe "-MExtUtils::Command::MM" "-e" "test_harness
(0, 'blib/lib', 'blib/arch')" t/*.t
t/00-have-compiler.t .. ok
t/01-basic.t .. cc1: error: unrecognized command line option "-fstack-pr
otector"
cc1: error: unrecognized command line option "-fstack-protector"
t/01-basic.t .. skipped: no compiler available for testing
t/02-link.t ... cc1: error: unrecognized command line option "-fstack-pr
otector"
cc1: error: unrecognized command line option "-fstack-protector"
t/02-link.t ... skipped: no compiler available for testing
t/03-cplusplus.t .. cc1plus: error: unrecognized command line option "-fstac
k-protector"
cc1plus: error: unrecognized command line option "-fstack-protector"
t/03-cplusplus.t .. skipped: no compiler available for testing
All tests successful.
Files=4, Tests=6,  4 wallclock secs ( 0.05 usr  0.02 sys +  0.80 cusr  0.80 csys
 =  1.66 CPU)
Result: PASS

rob...@robert-pc /cygdrive/c/modules/ExtUtils-CBuilder
$ make install
Installing /usr/share/man/man3/ExtUtils.CBuilder.3pm
Installing /usr/share/man/man3/ExtUtils.CBuilder.Platform.Windows.3pm
Appending installation info to /usr/lib/perl5/5.10/i686-cygwin/perllocal.pod

rob...@robert-pc /cygdrive/c/modules/ExtUtils-CBuilder
$ cd c:/modules/params-validate

rob...@robert-pc /cygdrive/c/modules/params-validate
$ perl Build.pl
cc1: error: unrecognized command line option "-fstack-protector"
cc1: error: unrecognized command line option "-fstack-protector"
Warning: ExtUtils::CBuilder not installed or no compiler detected
Proceeding with configuration, but compilation may fail during Build

Creating new 'MYMETA.yml' with configuration results
Creating new 'Build' script for 'Params-Validate' version '0.95'

rob...@robert-pc /cygdrive/c/modules/params-validate
$ ./Build
Building Params-Validate
Error: no compiler detected to compile 'lib/Params/Validate.c'.  Aborting

cygcheck.out
Description: Bina

RE: redirect-append (>>) creates garbage-y file

[William Lebow]

I've diagnosed this problem further. It is an interaction between cygwin and a 
security package called "Credant Guardian Shield" that my company installs on 
all of its laptops. I can't say specifically that it is a cygwin bug, but this 
bad behavior is not present in earlier versions.

As described below, the problem is a command like "echo foo >> foo.txt" creates 
a file that starts with a bunch of garbage, and ends with the expected text.

 -- Bill



-Original Message-
From: William Lebow [mailto:william.le...@phaseforward.com] 
Sent: Sunday, March 07, 2010 2:58 PM
To: cygwin@cygwin.com
Cc: ble...@alum.mit.edu
Subject: redirect-append (>>) creates garbage-y file

I'm a long time cygwin user, but I am having the weirdest problem after 
installing on my new Dell laptop running Windows XP professional. I'd be 
grateful for any advice or hints from this group.

I am doing a simple redirect-append (>>, that is) to create a new file. When I 
do this the new file has twice as many characters as I expect and the first 
bunch of characters are seemingly garbage.

This only happens with ">>" and only if I am creating a new file.
Using ">>" to append to a file is no problem.
Using ">" to create a new file is not problem

So far this has not been reproducable on any other PC.

I am using the bash version 3.2.49(23)-release (i686-pc-wygwin) , with the 
1007.1.0.0 cygwin1 dll-- see attached output from cygcheck.

Some examples follow::

#
 Example 1
 I expect 4 characters (including the terminator); I get 7  The first 3 
characters are unwanted
  $ echo abc >> test1.txt
  $ wc test1.txt
  1 1 7 test1.txt
  $ cat test1.txt
  0▒▒abc

$ hexedit test1.txt
   30 B5 A2 61  62 63 0A
0..abc.

#
 Example 2
 I expect 8 characters (including the terminator); I get 15  The first 
7 characters are unwanted
  $ echo abcdefg >> test2.txt
  $ wc test2.txt
   1  1 15 test2.txt
  $ cat test2.txt
  ▒▒\zB▒▒abcdefg

hexedit test2.txt
   AD EB 5C 7A  42 B6 C5 61  62 63 64 65  66 67 0A  
..\zB..abcdefg.


#
 Example 3
 Use > instead of >> and I get exactly what I should get
  $ echo abc > test3.txt
  $ wc test3.txt
  1 1 4 test3.txt
  $ cat test3.txt
  abc



Many thanks for any help

 -- Bill

--
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: Problems installing Text-Iconv-1.7 (perl module)

[Marc Girod]

Reini Urban wrote:
> 
> you need gcc-4
> 

Thanks, to both of you (Corina and Reini).
Do I understand right that perl was built with gcc 4 and -fstack-protect?
So, shouldn't gcc 4 be the default?
OK... It has been beaten to death and I just didn't notice or look for it...

Text-Iconv-1.7> gcc  -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include 
-Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608
-Wl,--enable-auto-image-base -fstack-protector -L/usr/local/lib -liconv  -o
linktest linktest.c
/cygdrive/c/Users/emagiro/AppData/Local/Temp/ccwhhRl0.o:linktest.c:(.text+0x26):
undefined reference to `_libiconv_open'
collect2: ld returned 1 exit status
Text-Iconv-1.7> gcc --version
gcc (GCC) 4.3.4 20090804 (release) 1
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

For -liconv, I added it now, but it doesn't affect.
Please note that this package installs fine on Solaris (without -liconv,
which I agree, looks like a miracle).
I would guess that somewhere it looks for a shared library, and doesn't find
the dll as one...

Marc
-- 
View this message in context: 
http://old.nabble.com/Problems-installing-Text-Iconv-1.7-%28perl-module%29-tp27833019p27841003.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: Problems installing Text-Iconv-1.7 (perl module)

[Larry Hall (Cygwin)]

On 3/9/2010 3:05 PM, Marc Girod wrote:

For -liconv, I added it now, but it doesn't affect.
Please note that this package installs fine on Solaris (without -liconv,
which I agree, looks like a miracle).
I would guess that somewhere it looks for a shared library, and doesn't find
the dll as one...


Did you install it?



--
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: "can't create master tty" errors

[Andy Koppe]

Cesar Crusius:
> I am using Cygwin and SSH to do automated remote builds using Visual
> C++. It works for a few days, but invariably things start failing with
> messages like these (this one from a build log):
>
> Makefile:9: MakePID: 5964
>      1 [main] env 2748 C:\cygwin\bin\env.exe: *** fatal error - can't create 
> master tty

The number of tty devices is limited, so the first thing to check is
whether your build system simply leaves too many sessions open, by
checking the output of 'ps'.

If not, it might be to do with the following. If you open a couple of
terminals, they're assigned  tty0 and tty1. If you then close tty1 and
open another terminal, that again becomes tty1. But if you close tty0,
and open yet another one, that becomes tty2 rather than tty0.

That appears to be the general rule: a new terminal gets the next ID
above the current highest one. This means, however, that if opening
and closing of terminal sessions is interleaved in certain ways,
Cygwin might eventually run out of terminal IDs, even if only few of
them are actually used. High numbers in the TTY column of the 'ps'
output would point to that.

Cgf, am I talking rubbish here?

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: "can't create master tty" errors

[Cesar Crusius]

On Tue, Mar 09, 2010 at 08:50:38PM +, Andy Koppe wrote:
> Cesar Crusius:
> > I am using Cygwin and SSH to do automated remote builds using Visual
> > C++. It works for a few days, but invariably things start failing with
> > messages like these (this one from a build log):
> >
> > Makefile:9: MakePID: 5964
> >      1 [main] env 2748 C:\cygwin\bin\env.exe: *** fatal error - can't 
> > create master tty
> 
> The number of tty devices is limited, so the first thing to check is
> whether your build system simply leaves too many sessions open, by
> checking the output of 'ps'.
> 
> If not, it might be to do with the following. If you open a couple of
> terminals, they're assigned  tty0 and tty1. If you then close tty1 and
> open another terminal, that again becomes tty1. But if you close tty0,
> and open yet another one, that becomes tty2 rather than tty0.
> 
> That appears to be the general rule: a new terminal gets the next ID
> above the current highest one. This means, however, that if opening
> and closing of terminal sessions is interleaved in certain ways,
> Cygwin might eventually run out of terminal IDs, even if only few of
> them are actually used. High numbers in the TTY column of the 'ps'
> output would point to that.
> 
> Cgf, am I talking rubbish here?
> 
> Andy
> 

There are never many processes running at a time by the build system
account (or any other account). If the second option really describes
the algorithm, then it is probably what is happening, and why it takes a
few days for the problem to manifest itself.

I'm trying to reproduce it, though, and here's what I am getting

ssh m...@build -> exit -> ssh bu...@build -> exit -> ...

This loop always gives me SSH_TTY=/dev/tty0, so it seems tty0 is getting
reused. (ps -eaW currently reports max(TTY)=2).

If I ssh as two users at the same time, one got tty0, the other tty3.
Still, exiting and ssh'ing back again still gives me tty0...

- 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

Re: Program cgystart does not recognize .pl file type; gets mime type incorrect

[Dave Korn]

On 09/03/2010 01:55, Paul McFerrin wrote:
> I ran into my first real problem with "cygstart".  When I execute
> cygstart with the argument:
>sendemail.pl
> 
> The browser window has the source-code being displayed. 

  Cygstart uses your windows file associations to launch the standard OS
action; it does the same thing as if you double-clicked on the file in
explorer.  So I guess that's how you've told explorer to handle .pl files.

  Why would you want to use 'cygstart' to launch perl anyway?  What were you
expecting it to do that's any different from just running "./sendmail.pl" at
the command-line?  You use a shell to launch stuff under cygwin, not cygstart;
that's just for interacting with windows.

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: allow executing a path in backslash notation

[Ilguiz Latypov]

> The bottom line is that if you want to use MS-DOS
> paths, then use a MinGW or DJGPP version of make.exe.  make.exe is not
> going to be patched.

The patch was to cygwin1.dll, but I am not insisting.

-- 

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

Network install of Cygwin?

[John Sambrook]

Hello,

Is it possible to do a network install of the Cygwin distribution, so
that a copy doesn't have to reside on every machine where it might be
used?

Thanks,

John Sambrook

--
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: terminals getting killed on parent's termination

[Andy Koppe]

Thomas Wolff:
>> Closing the terminal that a program was started from is not a completely
>> unrelated event,
>
> this is also a matter of taste and use case but just using a command line to
> *start* an application does not indicate the intent that the command line
> should continue to *host* the application in the sense of a session.

That's your opinion, but apparently it's not what the designers of
either Unix or X(lib) thought, because otherwise they could have
disabled SIGHUP by default. An example of Unix's sharp-edged "the user
knows best" philosophy, I guess. (Not that I'm a great fan of that
philosophy, as I've run 'rm -r' on the wrong directory often enough.)


> My case is that sturdiness of an application against external impact is the 
> more
> desirable the more interactive and potentially unsaved data it maintains.

Now that's something I can agree with.


> Your survey above may also be interpreted this way: the most established
> terminals (xterm, rxvt-unicode) do maintain this stability, while some
> "newcomers" don't care (yet).

Or put another way: they've been around long enough to have had enough
complaints about it, and I do wonder whether one T.Wolff had something
to do with it. ;)

Anyway, mintty 0.6-beta3 does ignore SIGHUP, for the sake of
consistency with its behaviour when invoked from a console.


> Among editors, apparently gvim supports my point, while emacs, gimp, abiword
> don't - but that can also just mean the issue has not received common
> awareness by now.

Right. I shan't dwell on the previously mentioned "common Unix
practice in Unix/Linux/X environments".


>> [It's] a
>> compromise between the two approaches. Unlike rxvt et al., it does
>> allow an application to say bye and prompt about unsaved data. Yet
>> unlike with xterm, a misbehaving application won't stop the user from
>> closing the terminal, because guess who'd be blamed for that.
>
> A well-considered approach; however, since mintty is the only terminal that
> applies this compromise, applications cannot assume this as a protocol, so I
> doubt there is much use case.

True enough, but then the same is true of xterm's approach, because
many of the other terminals also identify themselves as xterm. So, as
of course you're aware, you need to check the terminal type more
closely anyway (using the 'secondary device attribute' sequence), at
which point you can pick out mintty too.


> Actually I noticed xterm also implements a useful compromise: With a window
> manager close event (Click "X", Alt-F4) it behaves as I had described, with
> "Quit" from its own menu, on the other hand, it always quits, thus avoiding
> the problem of an "unkillable" terminal.

I'd seen that too, and I think it's bad UI design to have two subtly
different ways to quit a program, whereby you have to dig deep into
the manual to even find out that there is a difference. So having the
X button and the Close menu item behave differently is out of the
question. Nor am I keen on adding an option for this.

Another way to give you what you want would be to add a control
sequence for resetting the 'killed' flag, which would stop the next
click on the close button (or menu item) from closing mintty,

Thinking about xterm again, though, Cygwin's xterm is fairly unusual
to have its menu enabled by default, i.e. the "X"/SIGHUP button often
is the only way to close it. Xterm's child process normally is a shell
that does handle SIGHUP correctly, so I guess my concern about an
unclosable terminal isn't really relevant in practice. So sod it, I'll
change mintty to xterm's approach, with the proviso that I might
revert and add the aforementioned control sequence in case it does
create issues.

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

Close==SIGHUP

[Andy Koppe]

Hallo Thomas,

Ich habe den Close==SIGHUP Wunsch auf trunk implementiert. Wär toll,
wenn Du das einem Härtetest unterziehen könntest, auch in Verbindung
mit --hold=always und --hold=error.

Gruss,
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: Strange symlink behaviour

[Alfred von Campe]

On Mar 9, 2010, at 13:44, Larry Hall (Cygwin) wrote:


On 3/9/2010 10:11 AM, Alfred von Campe wrote:
The solution was to use hard links in the tar file (which doesn't  
use up
any more space), and when it was untar'ed on Windows, everything  
worked

^
On NTFS partitions.  It will on any kind of FAT partition though.


I meant that it didn't take more space inside the tar file.  I don't  
mind if it takes twice the disk space once extracted.


Alfred


--
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: Shared home dir, samba, and workgroups

[Wes Barris]

Marco Atzeri wrote:

--- Mar 9/3/10, Wes Barris  ha scritto:


Marco Atzeri wrote:

--- Mar 9/3/10, Wes Barris ha scritto:


Wes Barris wrote:

I use Cygwin 1.7 on my XP desktop system at

work.  I like having the

same home directory on this Windows XP system

as I do

on our Unix

server.  The Windows XP system is a

member of a

domain.  The Unix

server is not.  The Unix server is

running Samba

and is configured

with a workgroup name.  My home directory

on the

Unix server is

mounted as a mapped network drive on the

Windows XP

system.

Everything in the above setup is working
properly from the Unix server side and from

the

Windows side when

working with Windows Explorer.  I can

create and

delete files via

Windows Explorer and they show up on the Unix

side

with proper

ownership and permissions (as controlled by

Samba).  Conversely,

I can create and delete files under Unix and

access

these files

from Windows Explorer.

The problem is when I look at my mapped

network home

directory

with Cygwin, my home directory files are owned

by

nobody ('')

and have a group of nobody.  I am

guessing that

this is because my

Windows SID in /etc/passwd is the SID of my

domain

user and since

the Samba server is not part of this domain

the files

look like they

are from an unknown user.

In our Samba server there is a file (usermap)

that

maps unix usernames

to windows usernames.  This appears to be

working

when working with

Windows Explorer.  Why doesn't this work

with

Cygwin?  What is the

way to fix this?  Do I somehow need to

map my

unix username to a

windows SID?  Do I need to turn off
ntsec? 

you need to map the WINDOWS SID to the UNIX username

so you need to add on /etc/passwd and etc/group
the right references.

see:
http://cygwin.com/cygwin-ug-net/using-utils.html#mkpasswd
http://cygwin.com/cygwin-ug-net/ntsec.html

I've read both of those pages many times.  They don't
appear
to apply to my situation.  What mkpasswd option(s)
would you
suggest?  --local doesn't help map the Windows SID to
the UNIX
username, --domain doesn't do it.


Web,
if mkpasswd can not help you to identify the SID, than
you can try Setacl
http://setacl.sourceforge.net/

using as:
$ SetACL.exe -on $(cygpath -aw YOUR_FILE) -ot file -actn list -lst 
"f:sddl;w:o,g,s,d"

will provide the full list of SID and ACL of the file 
or directory. The answer is a bit cryptic but it is very detailed. 


After that you can create,by hand, the right reference in
your 
/etc/passwd and /etc/group 


Thanks Marco.  I was a bit skeptical having already worked so hard
on resolving this.  Using setacl.exe I was able to determine both
the owner and group SIDs:

W:\>SetACL.exe -on wesbarris.pdf -ot file -actn list -lst "f:tab;w:o"
wesbarris.pdf

   Owner: S-1-5-21-290311034-2557831423-1240041065-5424

   DACL(protected):
   S-1-5-21-290311034-2557831423-1240041065-5424   full   allow   no_inheritance

   S-1-22-2-200   read   allow   no_inheritance
   Everyone   read   allow   no_inheritance

Using this information I modified my /etc/passwd and /etc/group files.
The passwd file now contains a line for my domain user and a line
for the owner of the files from my home directory server.  It's a
bit confusing (having a different user owning my home directory
files) but everything appears to be working properly now.

Thank you very much!


Do I need to change

the mount options for /cygdrive?

Should I assume from the lack of any response that

there is

no fix
for this?

-- Wes Barris

I should say no
Marco

-- Wes Barris


Marco


  




--
Wes Barris

--
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: about base-files

[Cyrille Lefevre]

Hi,

FYI, still not fixed...

package version : base-files-3.9-3.tar.bz2

postinstall message :

running: D:\Cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/base-files-mketc.sh
cygwin warning:
  MS-DOS style path detected: C:\WINDOWS\system32\drivers\etc
  Preferred POSIX equivalent is: /cygdrive/c/WINDOWS/system32/drivers/etc
  CYGWIN environment variable option "nodosfilewarning" turns off this
warning.
  Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

=> WINETC and WFILE should use forward slashes (\\ => /)

proposed change (thanks to Eric Blake) :

WINETC="$WINHOME/system32/drivers/etc"
...
WFILE="$WINETC/`expr substr "$mketc" 1 8`"

Regards,

Cyrille Lefevre
--
mailto:cyrille.lefevre-li...@laposte.net


--
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: about pdksh

[Cyrille Lefevre]

Cyrille Lefevre a écrit :


Hi,

FYI

package version : pdksh-5.2.14-3.tar.bz2

postinstall message :

running: D:\Cygwin\bin\bash.exe --norc --noprofile 
/etc/postinstall/pdksh.sh

/etc/postinstall/pdksh.sh: line 6: @(#)PD KSH v5.2.14 99/07/13.2: No
such file or directory
Installing default /etc/ksh.kshrc
install: cannot stat `/usr/share/pdksh-/ksh.kshrc': No such file or
directory
Installing default /etc/profile.ksh
install: cannot stat `/usr/share/pdksh-/profile.ksh': No such file or
directory
/bin/pdksh already in /etc/shells
/bin/ksh already in /etc/shells
/usr/bin/pdksh already in /etc/shells
/usr/bin/ksh already in /etc/shells

=> VERSION=\
"..."
is not bourne like shell compatible.
should be VERSION="..." or VERSION=\
"..." w/ no .


still not fixed, CC Igor Pechtchanski

Regards,

Cyrille Lefevre
--
mailto:cyrille.lefevre-li...@laposte.net



--
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: Problems installing Text-Iconv-1.7 (perl module)

[Marc Girod]

Larry Hall (Cygwin) wrote:
> 
> Did you install it?
> 
I installed libiconv, but there is no dll in it: an archive, and this dll.a
file, of which I don't what to think:

~> cygcheck -l libiconv | grep lib/libiconv
/usr/lib/libiconv.a
/usr/lib/libiconv.dll.a
/usr/lib/libiconv.la
~> file /usr/lib/libiconv.dll.a
/usr/lib/libiconv.dll.a: current ar archive

Marc
-- 
View this message in context: 
http://old.nabble.com/Problems-installing-Text-Iconv-1.7-%28perl-module%29-tp27833019p27845834.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: Problems installing Text-Iconv-1.7 (perl module)

[Larry Hall (Cygwin)]

On 3/10/2010 12:44 AM, Marc Girod wrote:



Larry Hall (Cygwin) wrote:


Did you install it?


I installed libiconv, but there is no dll in it: an archive, and this dll.a
file, of which I don't what to think:

~>  cygcheck -l libiconv | grep lib/libiconv
/usr/lib/libiconv.a
/usr/lib/libiconv.dll.a
/usr/lib/libiconv.la
~>  file /usr/lib/libiconv.dll.a
/usr/lib/libiconv.dll.a: current ar archive


Sorry.  Reread the thread.  You forgot to put the -liconv at the end.
Remember, Windows != UNIX/Linux. ;-)

--
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: Problems installing Text-Iconv-1.7 (perl module)

[Marc Girod]

Larry Hall (Cygwin) wrote:
> 
> Sorry.  Reread the thread.  You forgot to put the -liconv at the end.
> Remember, Windows != UNIX/Linux. ;-)
> 
Thanks! It worked, and then I read the makefile better,
and it did it correctly, only the second time: it made a first
attempt without it (in case the symbols would be found in
libc), and added it to the second phase.
Which it didn't try as long as the first phase failed because
of my first using gcc 3.
So, with gcc 4, Text::Iconv installs correctly on cygwin
without needing to tweak the Makefile.PL.

Marc
-- 
View this message in context: 
http://old.nabble.com/Problems-installing-Text-Iconv-1.7-%28perl-module%29-tp27833019p27846072.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

MIT krb5 on cygwin?

[Marc Girod]

Still trying to install Net::LDAP, I am now in GSSAPI-0.26.
This one requires...

  An installed Version of GSS-API bindings, e.g

  MIT Kerberos 
  Heimdal  
  VAS  

It goes on indicating that...

- Windows - MIT KfW SDK:

  This SDK does not provide the krb5-config command,
  .
  Instead of using krb5-config you need to specifiy the compiler and linker
flags
  on the perl Makefile.PL commandline. run
  perl Makefile.PL --help
  to see all available configuration options.

I downloaded and extracted MIT Kfw SDK sources, but all the build
instructions are for Visual C++, and this won't give me anything linkable.

Am I completely going the wrong way?

Thanks,
Marc
-- 
View this message in context: 
http://old.nabble.com/MIT-krb5-on-cygwin--tp27846278p27846278.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: about pdksh

[Christopher Faylor]

On Wed, Mar 10, 2010 at 05:25:50AM +0100, Cyrille Lefevre wrote:
>
>Cyrille Lefevre a ?crit :
>> 
>> package version : pdksh-5.2.14-3.tar.bz2
>> 
>> postinstall message :
>> 
>> running: D:\Cygwin\bin\bash.exe --norc --noprofile 
>> /etc/postinstall/pdksh.sh
>> /etc/postinstall/pdksh.sh: line 6: @(#)PD KSH v5.2.14 99/07/13.2: No
>> such file or directory
>> Installing default /etc/ksh.kshrc
>> install: cannot stat `/usr/share/pdksh-/ksh.kshrc': No such file or
>> directory
>> Installing default /etc/profile.ksh
>> install: cannot stat `/usr/share/pdksh-/profile.ksh': No such file or
>> directory
>> /bin/pdksh already in /etc/shells
>> /bin/ksh already in /etc/shells
>> /usr/bin/pdksh already in /etc/shells
>> /usr/bin/ksh already in /etc/shells
>> 
>> => VERSION=\
>> "..."
>> is not bourne like shell compatible.
>> should be VERSION="..." or VERSION=\
>> "..." w/ no .
>
>still not fixed, CC Igor Pechtchanski

Why?  1) He is not the maintainer,  2) http://cygwin.com/acronyms/#PPIOSPE , and
3) http://cygwin.com/problems.html 

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: Installing a "copy" of an installation on a new computer

[Olle Olsson]

Hi,

I found the following
  http://www.cygwin.com/ml/cygwin/2006-05/msg00753.html
which might provide one practical solution. Will try this.
/olle

PS To avoid getting bounced by the MAILER-DAEMON I have removed the
original message.

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