-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A new release of findutils, 4.3.1-2, is available, replacing 4.3.1-1 as
current.
NEWS:
=
This is a minor patch release. It adds a proposed patch being discussed
upstream that fixes behavior with 'find -prune' that works with
/bin/oldfind but was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Loh, Joe on 11/2/2006 5:29 PM:
> Really appreaciate the recommendation that Dave Korn suggested. We went
> ahead and modified the cygwin1.dll for version 1.5.19-4, which is the
> one we have installed for testing. In the event of checkin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Matthew Woehlke on 11/2/2006 2:23 PM:
> Eric Blake wrote:
>> And while I'm at it, maybe I will figure out how to name my release
>> bash-3.1.3-
>> 5, so that the bash patchlevel is included in the cygwin release number.
>
> I thought that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Howard Mak on 11/2/2006 12:31 PM:
> Using "-path '*/.*' -prune" prunes too many files from find output when files
> to prune actually exists.
>
> Problem occurs in both version 4.3.0 + 4.3.1 of find.
> Problem does *not* occur in version
- Original Message -
From: "Corinna Vinschen" <[EMAIL PROTECTED]>
To:
Sent: Friday, November 03, 2006 9:48 AM
Subject: Please test the latest developer's snapshot
Hi,
The latest developer snapshot from http://cygwin.com/snapshots/ contains
a couple of patches which are supposed to ge
Really appreaciate the recommendation that Dave Korn suggested. We went
ahead and modified the cygwin1.dll for version 1.5.19-4, which is the
one we have installed for testing. In the event of checking out our
change we found a bug in the current SCSI device handling of major
number 65, i.e. any
Hi,
The latest developer snapshot from http://cygwin.com/snapshots/ contains
a couple of patches which are supposed to get Cygwin running better on
the upcoming Windows Vista.
The important change here is a slightly different memory allocation
scheme. I'd like to hear if this version still runs
Eric Blake wrote:
And while I'm at it, maybe I will figure out how to name my release bash-3.1.3-
5, so that the bash patchlevel is included in the cygwin release number.
I thought that was just a matter of what appears in setup.ini? (But
maybe I am wrong...)
--
Matthew
$ kill bill
kill: can
On Nov 2 10:56, Linda Walsh wrote:
> You somewhat answered my question, indirectly.
> I wasn't aware windows had a "group" security descriptor
> in addition to the user-owner-creator field.
> Where does it store the information?
In the security descriptor. There's no such thing as a "group se
On 11/2/06, Linda Walsh <> wrote:
You somewhat answered my question, indirectly.
I wasn't aware windows had a "group" security descriptor
in addition to the user-owner-creator field.
Where does it store the information?
Dave Roth has a pretty good description of the various ACLs that Windows us
On 11/02/2006, Nicolas Roche wrote:
Will try Dan solution with the new version of bash. As I said in my
previous mail, if you are interesting in the results I will send them.
Why not.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 8
Using "-path '*/.*' -prune" prunes too many files from find output when files
to prune actually exists.
Problem occurs in both version 4.3.0 + 4.3.1 of find.
Problem does *not* occur in version 4.2.27.
Is this problem related to the following bug?
http://sourceware.org/ml/cygwin/2006-07
Eric Blake byu.net> writes:
> According to David Picton on 10/31/2006 1:12 PM:
> > Unfortunately I have to report that both versions of bash don't
> > implement the igncr setting if
> > commands are read from a sourced file.
>
> Thanks for the report. I'll investigate it, and hopefully bash-3.2
You somewhat answered my question, indirectly.
I wasn't aware windows had a "group" security descriptor
in addition to the user-owner-creator field.
Where does it store the information?
It seems odd to have a Windows group field that no Windows utils
would be able to set (or view). Is the win
Larry Hall (Cygwin) a écrit :
Nicolas Roche wrote:
Larry Hall (Cygwin) a écrit :
On 11/02/2006, Nicolas Roche wrote:
I am using bash version:
3.1.17(9)
I have tried to use shopt -s igncr but I have an issue with the
following shell construct:
t=`gcc --print-multi-lib` where gcc is a mingw
Wilks, Dan a écrit :
So you could give the new experimental version of Bash a try
Thanks for your answer. Will make a try. Should I send my results ?
I tried to found the answer by myself but this change has generated so
much discussion, mostly concerning running scripts containing CR/LF
whi
Nicolas Roche wrote:
Larry Hall (Cygwin) a écrit :
On 11/02/2006, Nicolas Roche wrote:
I am using bash version:
3.1.17(9)
I have tried to use shopt -s igncr but I have an issue with the
following shell construct:
t=`gcc --print-multi-lib` where gcc is a mingw gcc.
As my gcc is a mingw prog
Nicolas Roche wrote:
> t=`gcc --print-multi-lib` where gcc is a mingw gcc.
>
> As my gcc is a mingw program, it outputs CR/LFs. In previous versions
> bash used to ignore the CR, so t variable was not containing any CR.
> Now this is no more the case and this is causing some troubles
Looking back
Larry Hall (Cygwin) a écrit :
On 11/02/2006, Nicolas Roche wrote:
I am using bash version:
3.1.17(9)
I have tried to use shopt -s igncr but I have an issue with the
following shell construct:
t=`gcc --print-multi-lib` where gcc is a mingw gcc.
As my gcc is a mingw program, it outputs CR/LFs
On 11/02/2006, Nicolas Roche wrote:
I am using bash version:
3.1.17(9)
I have tried to use shopt -s igncr but I have an issue with the following
shell construct:
t=`gcc --print-multi-lib` where gcc is a mingw gcc.
As my gcc is a mingw program, it outputs CR/LFs. In previous versions bash
us
Hi,
I saw that there was some changes in bash concerning handling of CR
(that raise a lot of discussion :-))
I am using bash version:
3.1.17(9)
I have tried to use shopt -s igncr but I have an issue with the
following shell construct:
t=`gcc --print-multi-lib` where gcc is a mingw gcc.
As
21 matches
Mail list logo
