Re: Thread support in cygwin!

[Joost Kraaijeveld]

On Wed, 2006-04-12 at 21:53 -0700, Do Nguyen Luong wrote:

> #include 
> #include  
> #include  
> int main() 
> { 
> #ifdef _POSIX_THREADS 
> printf("sysconf(_SC_THREADS): %d\n", sysconf(_SC_THREADS)); 
> #else 
> printf("_POSIX_THREADS not defined\n"); 
> #endif 
> return 0; 
> } 
> 
> And I get :
> sysconf(_SC_THREADS): -1
> 
> Is that mean cygwin doesn't support threads? Or I missed some package? 
No, it means that _POSIX_THREADS  is not defined. 

For the pthread support of Cygwin you can look at Cygwin's pthread.h
(which basically says that this is implemented:
http://www.opengroup.org/onlinepubs/7908799/xsh/pthread.h.html ) or at
the Cygwin API docs at http://cygwin.com/cygwin-api/std-posix.html#AEN85
(which seems a little sparse). 


-- 
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

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

Thread support in cygwin!

[Do Nguyen Luong]

Hi, I'm trying to port a program used pthread in Linux to Windows.In cygwin,
I compiled it but when executing I got this message : Threads are not
supported
In Linux, it works fine.
Then in Cygwin I write this simple program : 

#include 
#include  
#include  
int main() 
{ 
#ifdef _POSIX_THREADS 
printf("sysconf(_SC_THREADS): %d\n", sysconf(_SC_THREADS)); 
#else 
printf("_POSIX_THREADS not defined\n"); 
#endif 
return 0; 
} 

And I get :
sysconf(_SC_THREADS): -1

Is that mean cygwin doesn't support threads? Or I missed some package? 

--
View this message in context: 
http://www.nabble.com/Thread-support-in-cygwin%21-t1442219.html#a3894619
Sent from the Cygwin Users forum at Nabble.com.


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

Re: CVS command returns error

[Igor Peshansky]

Ugh, top-posting...  Reformatted.

On Wed, 12 Apr 2006, Michael Giroux wrote:

> Igor Peshansky wrote:
> > On Wed, 12 Apr 2006, Michael Giroux wrote:
> >
> > > The CVS related ANT tasks require that the cvs executable is on the
> > > PATH.
> > >
> > > I have two versions of cvs installed,
> > > one is at c:\bin\cvs\cvs.exe
> > > The other at c:\cygwin\bin\cvs.exe
> >
> > I'm assuming the former is a Windows build of cvs.
> >
> > > Both versions show the same version information:
> > > Concurrent Versions System (CVS) 1.11.20 (client)
> > >
> > > When I attempt to execute the target that contains  using
> > > the
> > > cygwin copy of cvs, I get the following error:
> > > cvs server: cannot open directory /cvsroot/howl/howl/logger
> > ^
> > There's your problem.  Cygwin's cvs will interpret this as an absolute
> > POSIX path, and will try to find it relative to the root ("/") mount
> > (unless you have a specific mount for that directory).  So, by
> > default, it'll look in c:\cygwin\cvsroot\howl\howl\logger (which, I'm
> > guessing, doesn't exist).
>
> Correct, it does not exist.
>
> > Whereas the Windows build of cvs (even though it reports the same
> > version) will treat the above path as a Win32 path (which will be
> > relative to the current drive, BTW), so it'll look (again, by default)
> > in c:\cvsroot\howl\howl\logger (which, I presume, exists).
>
> No, this does not exist either.
>
> > > When I execute using the version in my c:\bin\cvs directory, the
> > > task runs successfully.  So while these two versions of CVS appear
> > > to be the same version, they certainly do not work identically.
> >
> > They are the same version of CVS built for different platforms.  Of
> > course they won't work identically.
> >
> > FWIW, the only way you can be sure two executables will work
> > identically in every circumstance (apart from actually trying them) is
> > if they are exactly the same bit-by-bit.
> >
> > > Is anyone aware of any issues with the cygwin version of cvs command?
> >
> > No issues -- the behavior you're getting is expected.
> >
> > > Any tricks to using it with  ant tasks?
> >
> > You can make sure Cygwin's cvs looks for that directory in the same
> > place as the Windows cvs by mounting the directory appropriately.  I
> > suggest issuing the following command at the Cygwin prompt:
> >
> > mount -s 'c:\cvsroot' /cvsroot
> >
> > Once that's done, your Cygwin cvs should work properly *for that
> > repository*.
> >
> > > I did not see that I could specify a nested search path in the 
> > > commands. Is there a way to force ANT to use a specific executable
> > > for the  tasks?
> >
> > Not via the  tasks themselves, but you should be able to modify
> > the PATH environment variable within ant before running the 
> > tasks. Which is (a) not Cygwin-specific in any way, and (b)
> > unnecessary, given the above explanation.
> >
> > > FWIW, I get similar results using "cvs status" from the command
> > > prompt (taking ANT out of the picture).  When using
> > > c:\bin\cvs\cvs.exe version the status is returned successfully.
> > > When using c:\cygwin\bin\cvs.exe I get an error.  The error occurs
> > > whether I invoke cvs from a dos shell, or a cygwin shell.
> >
> > They are built for *different* platforms (Cygwin and Windows), which
> > treat paths differently.  Try the mount command above to fix the
> > Cygwin case.
> > Igor
>
> Igor,
> Thanks for the very complete answer.  I had not considered the fact that
> there were two separate builds for windows and cygwin.  Based on this,
> it seems that the correct solution is to set my PATH so that the windows
> version of CVS is in the PATH prior to cygwin version

Yes, that's one way of addressing this.

> I suspect that your explanation about the file path is related some how,
> but there are a detail that might apply.
>
> WRT the error message
> >> cvs server: cannot open directory /cvsroot/howl/howl/logger
> The path is the path on the remote server.  This comes from the cvs login:
> cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/howl login

Ah, that explains it.  In your previous message you neglected to mention
that this was a remote path, so I assumed the path was local.

> The remote cvs root is /cvsroot/howl and the module is howl/logger
> resulting in a request to access something on the remote system in
> /cvsroot/howl/howl/logger
>
> The local system (cvs client) location for this project is
> e:\workspace\logger\ (the location I did the co into.)
>
> WRT the mount
> > mount -s 'c:\cvsroot' /cvsroot

Well, since we're talking about the remote server, never mind this mount.

> Based on everything you have suggested, I'm starting to think that the
> problem has to do with the fact that the project was checked out using
> the windows version of cvs client, and something in the project
> structure is throwing the cygwin version of the client off.

Exactly.  I would guess the reason is pret

Re: CVS command returns error

[Michael Giroux]

Igor,
Thanks for the very complete answer.  I had not considered the fact that 
there were two separate builds for windows and cygwin.  Based on this, 
it seems that the correct solution is to set my PATH so that the windows 
version of CVS is in the PATH prior to cygwin version


I suspect that your explanation about the file path is related some how, 
but there are a detail that might apply.


WRT the error message
>> cvs server: cannot open directory /cvsroot/howl/howl/logger
The path is the path on the remote server.  This comes from the cvs login:
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/howl login

The remote cvs root is /cvsroot/howl and the module is howl/logger 
resulting in a request to access something on the remote system in 
/cvsroot/howl/howl/logger


The local system (cvs client) location for this project is 
e:\workspace\logger\ (the location I did the co into.)


WRT the mount
> mount -s 'c:\cvsroot' /cvsroot

Based on everything you have suggested, I'm starting to think that the 
problem has to do with the fact that the project was checked out using 
the windows version of cvs client, and something in the project 
structure is throwing the cygwin version of the client off.


I guess this really isn't that important since I do have a workaround. 
Unless you (or anyone else) has a compelling desire to rationalize what 
else might be going on, I'll leave it here.


Thanks for the help.

Michael





Igor Peshansky wrote:

On Wed, 12 Apr 2006, Michael Giroux wrote:


The CVS related ANT tasks require that the cvs executable is on the PATH.

I have two versions of cvs installed,
one is at c:\bin\cvs\cvs.exe
The other at c:\cygwin\bin\cvs.exe


I'm assuming the former is a Windows build of cvs.


Both versions show the same version information:
Concurrent Versions System (CVS) 1.11.20 (client)

When I attempt to execute the target that contains  using the
cygwin copy of cvs, I get the following error:
cvs server: cannot open directory /cvsroot/howl/howl/logger

^
There's your problem.  Cygwin's cvs will interpret this as an absolute
POSIX path, and will try to find it relative to the root ("/") mount
(unless you have a specific mount for that directory).  So, by default,
it'll look in c:\cygwin\cvsroot\howl\howl\logger (which, I'm guessing,
doesn't exist).  


Correct, it does not exist.


Whereas the Windows build of cvs (even though it reports
the same version) will treat the above path as a Win32 path (which will be
relative to the current drive, BTW), so it'll look (again, by default) in
c:\cvsroot\howl\howl\logger (which, I presume, exists).


No, this does not exist either.




When I execute using the version in my c:\bin\cvs directory, the task
runs successfully.  So while these two versions of CVS appear to be the
same version, they certainly do not work identically.


They are the same version of CVS built for different platforms.  Of course
they won't work identically.

FWIW, the only way you can be sure two executables will work identically
in every circumstance (apart from actually trying them) is if they are
exactly the same bit-by-bit.


Is anyone aware of any issues with the cygwin version of cvs command?


No issues -- the behavior you're getting is expected.


Any tricks to using it with  ant tasks?


You can make sure Cygwin's cvs looks for that directory in the same place
as the Windows cvs by mounting the directory appropriately.  I suggest
issuing the following command at the Cygwin prompt:

mount -s 'c:\cvsroot' /cvsroot

Once that's done, your Cygwin cvs should work properly *for that
repository*.


I did not see that I could specify a nested search path in the 
commands. Is there a way to force ANT to use a specific executable for
the  tasks?


Not via the  tasks themselves, but you should be able to modify the
PATH environment variable within ant before running the  tasks.
Which is (a) not Cygwin-specific in any way, and (b) unnecessary, given
the above explanation.


FWIW, I get similar results using "cvs status" from the command prompt
(taking ANT out of the picture).  When using c:\bin\cvs\cvs.exe version
the status is returned successfully.  When using c:\cygwin\bin\cvs.exe I
get an error.  The error occurs whether I invoke cvs from a dos shell,
or a cygwin shell.


They are built for *different* platforms (Cygwin and Windows), which treat
paths differently.  Try the mount command above to fix the Cygwin case.
Igor



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

Re: CVS command returns error

[René Berber]

Michael Giroux wrote:

> The CVS related ANT tasks require that the cvs executable is on the PATH.

Which is Windows' environment variable PATH, not necessarily the same as the
shell variable PATH you see under Cygwin.

Most important is that ant, like any other java application, uses Windows paths
while applications compiled with Cygwin see and use a Unix-like path (which
doesn't necessarily work with java).

> I have two versions of cvs installed,
> one is at c:\bin\cvs\cvs.exe
> The other at c:\cygwin\bin\cvs.exe
> 
> Both versions show the same version information:
> Concurrent Versions System (CVS) 1.11.20 (client)

Neither of those is the Cygwin distributed "stable" version (which is at the
1.11.17 version) unless you installed the "experimental" tagged package.  But
that is not important, are those compiled under Cygwin?

> When I attempt to execute the target that contains  using
> the cygwin copy of cvs, I get the following error:
> cvs server: cannot open directory /cvsroot/howl/howl/logger

Probably a path problem.

> When I execute using the version in my c:\bin\cvs directory, the task
> runs successfully.  So while these two versions of CVS appear to be the
> same version, they certainly do not work identically.
> 
> Is anyone aware of any issues with the cygwin version of cvs command?
> Any tricks to using it with  ant tasks?

No tricks really, is only knowing cvs, Cygwin and ant.

- cvs client has the option of specifying which executable to run as server.
- Cygwin has the cygpath command, used to translate paths to/from Windows 
syntax.

If you are using an IDE for java, some of those include their own cvs (which
comes from cvsNT) and use non-standard parameters and do understand Windows
paths (but not Cygwin/Unix paths).

> I did not see that I could specify a nested search path in the 
> commands.  Is there a way to force ANT to use a specific executable for
> the  tasks?

Yes.  As I said, that is a cvs client parameter.

> FWIW, I get similar results using "cvs status" from the command prompt
> (taking ANT out of the picture).  When using c:\bin\cvs\cvs.exe version
> the status is returned successfully.  When using c:\cygwin\bin\cvs.exe I
> get an error.  The error occurs whether I invoke cvs from a dos shell,
> or a cygwin shell.

Now you are confusing things.  The cvs status that worked was done in a working
repository build by the same cvs (it already has, inside all those CVS
directories, where the repository is located, what user did the checkout, and
whatever it needs to work).

Anyway, the owners of this list may object to discussions over non-Cygwin
related issues.  So, if you can limit your questions to the cvs distributed
package it would be better, ant has its own list, cvs in general has its own 
list.
-- 
René Berber


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

Re: CVS command returns error

[Igor Peshansky]

On Wed, 12 Apr 2006, Michael Giroux wrote:

> The CVS related ANT tasks require that the cvs executable is on the PATH.
>
> I have two versions of cvs installed,
> one is at c:\bin\cvs\cvs.exe
> The other at c:\cygwin\bin\cvs.exe

I'm assuming the former is a Windows build of cvs.

> Both versions show the same version information:
> Concurrent Versions System (CVS) 1.11.20 (client)
>
> When I attempt to execute the target that contains  using the
> cygwin copy of cvs, I get the following error:
> cvs server: cannot open directory /cvsroot/howl/howl/logger
^
There's your problem.  Cygwin's cvs will interpret this as an absolute
POSIX path, and will try to find it relative to the root ("/") mount
(unless you have a specific mount for that directory).  So, by default,
it'll look in c:\cygwin\cvsroot\howl\howl\logger (which, I'm guessing,
doesn't exist).  Whereas the Windows build of cvs (even though it reports
the same version) will treat the above path as a Win32 path (which will be
relative to the current drive, BTW), so it'll look (again, by default) in
c:\cvsroot\howl\howl\logger (which, I presume, exists).

> When I execute using the version in my c:\bin\cvs directory, the task
> runs successfully.  So while these two versions of CVS appear to be the
> same version, they certainly do not work identically.

They are the same version of CVS built for different platforms.  Of course
they won't work identically.

FWIW, the only way you can be sure two executables will work identically
in every circumstance (apart from actually trying them) is if they are
exactly the same bit-by-bit.

> Is anyone aware of any issues with the cygwin version of cvs command?

No issues -- the behavior you're getting is expected.

> Any tricks to using it with  ant tasks?

You can make sure Cygwin's cvs looks for that directory in the same place
as the Windows cvs by mounting the directory appropriately.  I suggest
issuing the following command at the Cygwin prompt:

mount -s 'c:\cvsroot' /cvsroot

Once that's done, your Cygwin cvs should work properly *for that
repository*.

> I did not see that I could specify a nested search path in the 
> commands. Is there a way to force ANT to use a specific executable for
> the  tasks?

Not via the  tasks themselves, but you should be able to modify the
PATH environment variable within ant before running the  tasks.
Which is (a) not Cygwin-specific in any way, and (b) unnecessary, given
the above explanation.

> FWIW, I get similar results using "cvs status" from the command prompt
> (taking ANT out of the picture).  When using c:\bin\cvs\cvs.exe version
> the status is returned successfully.  When using c:\cygwin\bin\cvs.exe I
> get an error.  The error occurs whether I invoke cvs from a dos shell,
> or a cygwin shell.

They are built for *different* platforms (Cygwin and Windows), which treat
paths differently.  Try the mount command above to fix the Cygwin case.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

Re: Cron on Cygwin

[Brian Dessent]

grahul wrote:

> I installed cron, everything seems fine. This is what I've done so far:
> cygrunsrv -I cron -p /usr/sbin/cron -a -D
> net start cron

You should run the cron-config script instead of trying to do it
yourself.  There's more to it than this.  See also cron_diagnose.sh.

Also, please read the problem reporting guidelines on
, specifically the part about attaching
cygcheck output.

Brian

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

Cron on Cygwin

[grahul]

I installed cron, everything seems fine. This is what I've done so far:
cygrunsrv -I cron -p /usr/sbin/cron -a -D
net start cron

and seems to start fine, it even comes up when i do ps -ef
i modify the crontab file by doing
crontab -e
then I do crontab -l to see if it picks it up and it does and the output is:
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.1080 installed on Wed Apr 12 17:08:42 2006)
# (Cron version -- $Id: crontab.c,v 1.7 2003/04/15 15:13:41 corinna Exp $)
* * * * * alavrah ls -al > /cygdrive/h/testingCron

but it doesn't do anything, (alavrah is my username) I tried with and
without username. I DON'T have any error messages at all. I've tried other
commands and nothing happens in the crontab and still nothing, no errors,
nothing. Any help is really really appreciated.
--
View this message in context: 
http://www.nabble.com/Cron-on-Cygwin-t1440839.html#a3890766
Sent from the Cygwin Users forum at Nabble.com.


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

Re: CVS command returns error

[Michael Giroux]

BTW, any suggestions for helping to debug the problem will be 
appreciated.  I normally use CVS via Eclipse and ANT tasks, so I'm not 
very familiar with the command-line, but I'll gladly try anything to 
sort out the problem.



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

CVS command returns error

[Michael Giroux]

The CVS related ANT tasks require that the cvs executable is on the PATH.

I have two versions of cvs installed,
one is at c:\bin\cvs\cvs.exe
The other at c:\cygwin\bin\cvs.exe

Both versions show the same version information:
Concurrent Versions System (CVS) 1.11.20 (client)

When I attempt to execute the target that contains  using 
the cygwin copy of cvs, I get the following error:

cvs server: cannot open directory /cvsroot/howl/howl/logger

When I execute using the version in my c:\bin\cvs directory, the task 
runs successfully.  So while these two versions of CVS appear to be the 
same version, they certainly do not work identically.


Is anyone aware of any issues with the cygwin version of cvs command? 
Any tricks to using it with  ant tasks?


I did not see that I could specify a nested search path in the  
commands.  Is there a way to force ANT to use a specific executable for 
the  tasks?


FWIW, I get similar results using "cvs status" from the command prompt 
(taking ANT out of the picture).  When using c:\bin\cvs\cvs.exe version 
the status is returned successfully.  When using c:\cygwin\bin\cvs.exe I 
get an error.  The error occurs whether I invoke cvs from a dos shell, 
or a cygwin shell.


Thanks
Michael Giroux


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

Re: XP embedded

[Tony Richardson]

Jeff Lange  gmail.com> writes:
>   While searching though the mail list archives, I found a posting
> back on March 9th asking about XP Embedded SP2 and the error
> "/dev/null: No such file or directory".
> 
> Everyone blasted the poster for running a really old version of Cygwin.
> 
> Well I'm running into the exact same problem, except that I'm running
> the latest version of Cygwin. When I start a console I get the message
> "bash: /dev/null: No such file or directory"

You might try adding the NULL device driver to XPE.  Search
for info in the microsoft.public.windowsxp.embedded newsgroup.

Tony Richardson



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

Re: Cygrunsrv starts service but reports that it didn't start

[Sven Köhler]

> Command : /usr/sbin/sshd -D

for sshd, "-D" means, that the sshd process will _not_ detach from his
parent process (which is cygrunsrv)

> Command : /usr/local/sbin/samhain -D

and according to the docs, saimhain will _not_ detach from the parent
process to become a daemon.
(which would be the same behaviour than "sshd -D")

But you specified "-D" as an option to samhain and the docs say, that
"-D" will cause that samhain does detach from its parent - which is the
opposite of what you want, because you want samhain to be under the
control of cygrunsrv, and therefor you want that it does detach.



signature.asc
Description: OpenPGP digital signature

Re: XP embedded

[Igor Peshansky]

On Wed, 12 Apr 2006, Christopher Faylor wrote:

> On Wed, Apr 12, 2006 at 12:05:04PM -0400, Igor Peshansky wrote:
> >On Wed, 12 Apr 2006, Christopher Faylor wrote:
> >>On Wed, Apr 12, 2006 at 07:43:33AM -0400, Jeff Lange wrote:
> >>>/dev/zero does work properly.  I changed line 68 in /etc/profile to use
> >>>/dev/zero instead of /dev/null and I no longer get the bash error on
> >>>start up.
> >
> >FWIW, /dev/zero is not always the proper substitution for /dev/null
> >(i.e., on input redirection, it will work differently).
> >
> >>>Perhaps the cygwin libraries should be modified so that if the windows
> >>>NUL device doesn't exist, it should use a different method.
> >>
> >>Sorry, no.  We already have enough special cases in the code.  We're
> >>not going to start adding more for XP Embedded.
> >
> >What I'm wondering is whether we need the Windows NUL device at all for
> >implementing /dev/null...  It's rather trivial[*] to implement one
> >without resorting to a Windows device.  Would there be any way of
> >distinguishing an emulation from the real NUL device?
>
> Wasn't that the point that the OP was making and to which I responded?

Umm, not quite.  The OP was proposing doing this conditionally, if NUL is
not present.  I was asking what the drawbacks of always using an emulated
null device were.

> I really do understand this stuff, Igor.
>
> When possible we always try to use the underlying device.  There are
> obvious benefits to doing things this way and there is no reason to
> abandon this policy for XP Embedded.

Ok, I understand the issue now.  Thanks for explaining it.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

perl reading ^M on text mounts

[Lemke, Michael SZ/HZA-IOM1]

If I execute this perl script
 
   de010597> cat x.pl
   #!/usr/bin/perl
   use strict;

   open( HO, ") { print "$_"; }

on a text mount with an input file that has CRLF line endings perl
should treat this as a text file and strip the CR.  Only if I use
binmode HO should I see the CR.  But it doesn't:


 de010597> ./x.pl | cat -A
bla^M$
 de010597> cat -A x.txt
bla^M$

What am I missing here?

 de010597> pwd
/d/jakarta-tomcat/awstats
 de010597> mount
D:\PROGRA~1\cygwin\bin on /usr/bin type system (binmode)
D:\PROGRA~1\cygwin\lib on /usr/lib type system (binmode)
D:\PROGRA~1\cygwin on / type system (binmode)
c: on /c type system (textmode,noumount)
d: on /d type system (textmode,noumount)
f: on /f type system (textmode,noumount)
 de010597> mount -m
mount -f -s -b "D:/PROGRA~1/cygwin/bin" "/usr/bin"
mount -f -s -b "D:/PROGRA~1/cygwin/lib" "/usr/lib"
mount -f -s -b "D:/PROGRA~1/cygwin" "/"
mount -s -t --change-cygdrive-prefix "/"
 de010597> uname -a
CYGWIN_NT-5.2 de010597 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown
unknown Cygwin
 de010597> perl -v

This is perl, v5.8.7 built for cygwin-thread-multi-64int



Michael

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

Re: XP embedded

[Christopher Faylor]

On Wed, Apr 12, 2006 at 06:19:37PM +0200, Corinna Vinschen wrote:
>Since /dev/null is a really existing native device, it also works for
>stdio redirection when executing a native Windows process.  Off the top
>of my head I don't know a case for which that really matters, but it's
>guaranteed that somebody on the list will find a case really soon after
>this change.

In this case, "somebody on the list" is me.  I changed this back in 1997
because I wanted my windows apps to really see a null device when
redirected to /dev/null.

cgf

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

Re: XP embedded

[Igor Peshansky]

On Wed, 12 Apr 2006, Corinna Vinschen wrote:

> On Apr 12 12:05, Igor Peshansky wrote:
> > On Wed, 12 Apr 2006, Christopher Faylor wrote:
> >
> > > On Wed, Apr 12, 2006 at 07:43:33AM -0400, Jeff Lange wrote:
> > > >/dev/zero does work properly.  I changed line 68 in /etc/profile to
> > > >use /dev/zero instead of /dev/null and I no longer get the bash error
> > > >on start up.
> >
> > FWIW, /dev/zero is not always the proper substitution for /dev/null (i.e.,
> > on input redirection, it will work differently).
>
> Mon dieu!

Yes, surprising, isn't it? :-)

> > What I'm wondering is whether we need the Windows NUL device at all for
> > implementing /dev/null...  It's rather trivial[*] to implement one without
> > resorting to a Windows device.  Would there be any way of distinguishing
> > an emulation from the real NUL device?
> > Igor
>
> Since /dev/null is a really existing native device, it also works for
> stdio redirection when executing a native Windows process.  Off the top
> of my head I don't know a case for which that really matters, but it's
> guaranteed that somebody on the list will find a case really soon after
> this change.

Hmm, true, but wouldn't we have this problem already if someone redirected
some native program's output to /dev/zero?  Or are you talking about
inheriting an open handle to /dev/null?
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

Re: XP embedded

[Christopher Faylor]

On Wed, Apr 12, 2006 at 12:05:04PM -0400, Igor Peshansky wrote:
>On Wed, 12 Apr 2006, Christopher Faylor wrote:
>>On Wed, Apr 12, 2006 at 07:43:33AM -0400, Jeff Lange wrote:
>>>/dev/zero does work properly.  I changed line 68 in /etc/profile to use
>>>/dev/zero instead of /dev/null and I no longer get the bash error on
>>>start up.
>
>FWIW, /dev/zero is not always the proper substitution for /dev/null
>(i.e., on input redirection, it will work differently).
>
>>>Perhaps the cygwin libraries should be modified so that if the windows
>>>NUL device doesn't exist, it should use a different method.
>>
>>Sorry, no.  We already have enough special cases in the code.  We're
>>not going to start adding more for XP Embedded.
>
>What I'm wondering is whether we need the Windows NUL device at all for
>implementing /dev/null...  It's rather trivial[*] to implement one
>without resorting to a Windows device.  Would there be any way of
>distinguishing an emulation from the real NUL device?

Wasn't that the point that the OP was making and to which I responded?
I really do understand this stuff, Igor.

When possible we always try to use the underlying device.  There are
obvious benefits to doing things this way and there is no reason to
abandon this policy for XP Embedded.

cgf

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

Re: XP embedded

[Corinna Vinschen]

On Apr 12 12:05, Igor Peshansky wrote:
> On Wed, 12 Apr 2006, Christopher Faylor wrote:
> 
> > On Wed, Apr 12, 2006 at 07:43:33AM -0400, Jeff Lange wrote:
> > >/dev/zero does work properly.  I changed line 68 in /etc/profile to
> > >use /dev/zero instead of /dev/null and I no longer get the bash error
> > >on start up.
> 
> FWIW, /dev/zero is not always the proper substitution for /dev/null (i.e.,
> on input redirection, it will work differently).

Mon dieu!

> What I'm wondering is whether we need the Windows NUL device at all for
> implementing /dev/null...  It's rather trivial[*] to implement one without
> resorting to a Windows device.  Would there be any way of distinguishing
> an emulation from the real NUL device?
>   Igor

Since /dev/null is a really existing native device, it also works for
stdio redirection when executing a native Windows process.  Off the top
of my head I don't know a case for which that really matters, but it's
guaranteed that somebody on the list will find a case really soon after
this change.


Corinna

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

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

Re: XP embedded

[Igor Peshansky]

On Wed, 12 Apr 2006, Christopher Faylor wrote:

> On Wed, Apr 12, 2006 at 07:43:33AM -0400, Jeff Lange wrote:
> >/dev/zero does work properly.  I changed line 68 in /etc/profile to
> >use /dev/zero instead of /dev/null and I no longer get the bash error
> >on start up.

FWIW, /dev/zero is not always the proper substitution for /dev/null (i.e.,
on input redirection, it will work differently).

> >Perhaps the cygwin libraries should be modified so that if the windows
> >NUL device doesn't exist, it should use a different method.
>
> Sorry, no.  We already have enough special cases in the code.  We're not
> going to start adding more for XP Embedded.

What I'm wondering is whether we need the Windows NUL device at all for
implementing /dev/null...  It's rather trivial[*] to implement one without
resorting to a Windows device.  Would there be any way of distinguishing
an emulation from the real NUL device?
Igor
[*] The implementation would be substantially the same as that for
/dev/zero, except for removing the test for FH_FULL and always setting len
to 0 in read().
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

Re: XP embedded

[Christopher Faylor]

On Wed, Apr 12, 2006 at 07:43:33AM -0400, Jeff Lange wrote:
>/dev/zero does work properly.  I changed line 68 in /etc/profile to
>use /dev/zero instead of /dev/null and I no longer get the bash error
>on start up.
>
>Perhaps the cygwin libraries should be modified so that if the windows
>NUL device doesn't exist, it should use a different method.

Sorry, no.  We already have enough special cases in the code.  We're not
going to start adding more for XP Embedded.

cgf

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

Re: Spam:Re: Find not working w/ Samba drive

[Corinna Vinschen]

On Apr 12 11:48, Corinna Vinschen wrote:
> On Apr 11 15:45, Stefan Vorkoetter wrote:
> > And here's one from a Samba 2.2.3a share, repeated twice. Notice the inodes 
> > are different each time.
> > 
> > ~/sandboxes/main/internal/src [920] $ ls -i 
> > v:/internal_html/2006-04-10/*.jpg
> > 3796172808 v:/internal_html/2006-04-10/17-50-56.jpg
> > [...]
> 
> I have a vague hope.  It really looks like the inode numbers sent by
> older Samba versions are 32 bit values, which would allow to distinguish
> between old and new versions.
> 
> Would you or anybody with an older Samba version mind to look into
> more directories on the share and try to figure out if the inode number
> is always smaller than UINT_MAX (4294967295)?  I just need a feedback
> of yes or no.

Btw., I have hacked together a tiny testcase which lists a directory and
evaluates the inode numbers using readdir and lstat.  I would be
interested to see the output for some smaller directories on shares
using pre-3.0 Samba versions.  This should also simplify testing in
general.


Corinna


 SNIP =
#include 
#include 
#include 
#include 
#include 

int
main(int argc, char **argv)
{
  DIR *dirp;
  int fd;
  struct stat sb;
  struct dirent *d;

  if (argc > 1)
{
  dirp = opendir(argv[1]);
  if (dirp)
{
  while (d = readdir (dirp))
{
  char buf[256];
  struct stat st;

  strcpy (buf, argv[1]);
  if (buf[strlen (buf) - 1] != '/')
strcat (buf, "/");
  strcat (buf, d->d_name);
  lstat (buf, &st);
  printf ("%24s d: %18.18llu, st: %18.18llu\n",
  d->d_name, d->d_ino, st.st_ino);
}
  closedir (dirp);
}
  else
  printf("dirp = NULL\n");
}
  return 0;
}
 SNAP =


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

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

[ANNOUNCEMENT] Updated [experimental]: tar-1.15.90-1

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A new release of tar, 1.15.90-1, is available for experimental use.

NEWS:
=
This is a new alpha-quality upstream release.  It also relies on features
that have been added to cygwin since cygwin-1.5.19 was released (such as
freopen(NULL) and d_ino).  In other words, to use this, you MUST install a
recent cygwin snapshot (20060329 or later), or wait for cygwin-1.5.20 to
be released.  If you are not sure what that means, then stick with the
stable tar-1.15.1-4.  A list of changes from the NEWS file is attached;
see also /usr/share/doc/tar-1.15.90/.

DESCRIPTION:

GNU Tar is an archiver program. It is used to create and manipulate files
that are actually collections of many other files; the program provides
users with an organized and systematic method of controlling a large
amount of data.  Despite its name, that is an acronym of "tape archiver",
GNU Tar is able to direct its output to any available devices, files or
other programs, it may as well access remote devices or files.  The main
areas of usage for GNU Tar are: storage, backup and transportation.

UPDATE:
===
To update your installation, click on the "Install Cygwin now" link on the
http://cygwin.com/ web page.  This downloads setup.exe to your system.
Save it and run setup, answer the questions and pick up 'tar' from the
'Base' category (it should already be selected).  Since this is an
experimental release, you must first install a recent cygwin snapshot, and
you will have to use the "Exp" radio button in setup.exe.

DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need to
find a mirror which has this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

- --
Eric Blake
volunteer cygwin tar maintainer

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message.  Send email
to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

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

http://sources.redhat.com/lists.html#unsubscribe-simple

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

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

iD8DBQFEPQMR84KuGfSFAYARAmOZAKDJ2rbcd9/1mYeH+020syY2R2dycwCfS8yh
PA1K+0BpyR+B53ok8HHtH1M=
=8tfO
-END PGP SIGNATURE-
GNU tar NEWS - User visible changes.
version 1.15.90 - Sergey Poznyakoff, 2006-02-19

* New features

* Any number of -T (--files-from) options may be used in the command line.
The file specified with -T may include any valid `tar' options,
including another -T option.
Compatibility note: older versions of tar would only recognize -C
as an option name within the file list file.  Now any file whose name
starts with - is handled as an option.  To insert file names starting with
dash, use the --add-file option.

* List files containing null-separated file names are detected and processed
automatically.  It is no longer necessary to give the --null option.

* New option --no-unquote disables the unquoting of input file names.
This is useful for processing output from `find dir -print0'.
An orthogonal option --unquote is provided as well.

* New option --test-label tests the archive volume label.
If an argument is specified, the label is compared against its value.
Tar exits with code 0 if the two strings match, and with code 2 if
they do not.

If no argument is given, the --verbose option is implied.  In this case,
tar prints the label name if present and exits with code 0.

* New option --show-stored-names.  When creating an archive in verbose mode,
it lists member names as stored in the archive, i.e., with any eventual
prefixes removed.  The option is useful, for example, while comparing
`tar cv' and `tar tv' outputs.

* New option --to-command pipes the contents of archive members to the
specified command.

* New option --atime-preserve=system, which uses the O_NOATIME feature
of recent Linux kernels to avoid some problems when preserving file
access times.

* New option --delay-directory-restore delays restoring modification times
and permissions of extracted directories until the end of extraction.
This is necessary for restoring from archives with unusual member
ordering (in particular, those created with --no-recursion option).
This option is implied when restoring from incremental archives.

* New option --restrict prohibits use of some potentially harmful tar
options.  Currently it disables '!' escape in multi-volume name menu.

* New 

Re: XP embedded

[Jeff Lange]

/dev/zero does work properly.  I changed line 68 in /etc/profile to
use /dev/zero instead of /dev/null and I no longer get the bash error
on start up.

Perhaps the cygwin libraries should be modified so that if the windows
NUL device doesn't exist, it should use a different method.

Thanks.
-Jeff


On 4/12/06, Corinna Vinschen <[EMAIL PROTECTED]> wrote:
> On Apr 11 14:22, Jeff Lange wrote:
> > Hi all,
> >   While searching though the mail list archives, I found a posting
> > back on March 9th asking about XP Embedded SP2 and the error
> > "/dev/null: No such file or directory".
> >
> > Everyone blasted the poster for running a really old version of Cygwin.
> >
> > Well I'm running into the exact same problem, except that I'm running
> > the latest version of Cygwin. When I start a console I get the message
> > "bash: /dev/null: No such file or directory"
> >
> > I did a little playing around and if I try to pipe anything out
> > /dev/null I get the error.  just for kicks I tried creating /dev/null
> > using mknod, but it failed saying that the file already exists
> >
> > I have the exact same installation on regular XP SP2 and this problem
> > does not exist
> >
> > Let me know if you have any ideas on what the issue might be.
>
> /dev/null in Cygwin is a direct connection to the NUL device of
> Windows.  It looks like this device simply doesn't exist on
> embedded XP.  However, further debugging would be required by
> somebody actually owning embedded XP (e.g. you).
>
> As a workaround, try redirecting output to /dev/zero which is not
> implemented using the Windows NUL device.
>
>
> Corinna
>
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader  cygwin AT cygwin DOT com
> Red Hat
>
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
>
>

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

Re: Fixing the state of C++ in Cygwin

[Corinna Vinschen]

On Apr 11 22:35, Steven Brown wrote:
> Christopher Faylor wrote:
> 
> >How about figuring out what the "for some reason" is that makes sed 4.1.5
> >(theoretically) fail?
> 
> The thread regarding sed 1.4.5 and libtool:
> http://www.cygwin.com/ml/cygwin/2006-02/msg00846.html
> 
> Wouldn't it be best to first return to sed 4.1.4 before debugging why 
> upgrading to sed 4.1.5 is problematic?  It's left Cygwin installs in a 
> broken state for C++ compiles since February.
> 
> I can look into the problem with sed 4.1.5 as well, but I'd like to see 
> Cygwin stay in a working state as much as possible.

 From the above thread you know what's the important difference between
Cygwin's sed 4.1.4 and 4.1.5.  There are three other major changes which
you will find in the NEWS file in the source code.  So the question is
this:

Is it a textmode/binmode issue and if so, why are the files created with
CRLF line endings at all?  If they are not created with CRLF line
endings on Linux, then there's no reason to create them with CRLF on
Cygwin.  As a first local solution, don't use textmode mounts.


Corinna

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

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

Re: SSH works, but SFTP fails on non-admin users

[Corinna Vinschen]

On Apr 11 23:03, DJ Lee wrote:
> Hello -
> 
> I just upgraded cygwin a few days ago (a lot of packages were upgraded), 
> and all of a sudden, I have an odd issue with SFTP.
> 
> On this box 'icenine', I have two users, one administrator, one 
> non-admin.  I can ssh and scp into the box with both users without 
> problems; I can also sftp into the box with the admin user.  But when I 
> try to sftp into icenine with the non-admin user, an error occurs on 
> icenine:
> 
> 
> "This application has failed to start because cygcrypto-0.9.8.dll was 
> not found. Re-installing the application may fix this problem."

Looks like a permission problem to me.  You must make sure that all
users have read and execute permission on all DLLs.


Corinna

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

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

Re: XP embedded

[Corinna Vinschen]

On Apr 11 14:22, Jeff Lange wrote:
> Hi all,
>   While searching though the mail list archives, I found a posting
> back on March 9th asking about XP Embedded SP2 and the error
> "/dev/null: No such file or directory".
> 
> Everyone blasted the poster for running a really old version of Cygwin.
> 
> Well I'm running into the exact same problem, except that I'm running
> the latest version of Cygwin. When I start a console I get the message
> "bash: /dev/null: No such file or directory"
> 
> I did a little playing around and if I try to pipe anything out
> /dev/null I get the error.  just for kicks I tried creating /dev/null
> using mknod, but it failed saying that the file already exists
> 
> I have the exact same installation on regular XP SP2 and this problem
> does not exist
> 
> Let me know if you have any ideas on what the issue might be.

/dev/null in Cygwin is a direct connection to the NUL device of
Windows.  It looks like this device simply doesn't exist on 
embedded XP.  However, further debugging would be required by
somebody actually owning embedded XP (e.g. you).

As a workaround, try redirecting output to /dev/zero which is not
implemented using the Windows NUL device.


Corinna

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

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

Re: awk -v BINMODE=rw '{print}' # future sed revs binary too?

[Corinna Vinschen]

On Apr 11 15:21, Tom Rodman wrote:
> On Tue 4/11/06 11:19 +0200 cygwin@cygwin.com wrote:
> > Use dos2unix/unix2dos in scripts.
> 
> So the change to sed is intentional, I assume.  I always thought 'sed' should 
> be
> binary by default, but for years the cygwin version was not.
> 
> Will you reassure me that sed will stay this way?  :->

Yes, no worries.  The fact that sed was textmode was a bug in the sed
sources.  Sed ships its own version of getline which special cases
Windows and DOS and, unfortunately, Cygwin, to always read its input in
textmode.  The new sed is only binmode because it's now using the Cygwin
(better: newlib) version of getline, which does not add a textmode hack.


Corinna

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

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

Re: Spam:Re: Find not working w/ Samba drive

[Corinna Vinschen]

On Apr 11 15:45, Stefan Vorkoetter wrote:
> And here's one from a Samba 2.2.3a share, repeated twice. Notice the inodes 
> are different each time.
> 
> ~/sandboxes/main/internal/src [920] $ ls -i 
> v:/internal_html/2006-04-10/*.jpg
> 3796172808 v:/internal_html/2006-04-10/17-50-56.jpg
> [...]

I have a vague hope.  It really looks like the inode numbers sent by
older Samba versions are 32 bit values, which would allow to distinguish
between old and new versions.

Would you or anybody with an older Samba version mind to look into
more directories on the share and try to figure out if the inode number
is always smaller than UINT_MAX (4294967295)?  I just need a feedback
of yes or no.


Corinna

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

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