On 2020-05-27 20:42, m@d m0nk via Cygwin wrote:
> On Thu, May 28, 2020 at 8:10 AM Eliot Moss wrote:
>> On 5/27/2020 10:27 PM, m@d m0nk via Cygwin wrote:
>>> I am trying to understand the practical use of "--horizon-lines=lines"
>>> option in the diff utilit
wrote:
> > Hello All,
> >
> > I am trying to understand the practical use of "--horizon-lines=lines"
> > option in the diff utility.
> >
> > Can i get some pointers on two sample files which can demonstrate the
> > use of --horizon-lines=lines
> >
&
On 5/27/2020 10:27 PM, m@d m0nk via Cygwin wrote:
Hello All,
I am trying to understand the practical use of "--horizon-lines=lines"
option in the diff utility.
Can i get some pointers on two sample files which can demonstrate the
use of --horizon-lines=lines
I understood
Hello All,
I am trying to understand the practical use of "--horizon-lines=lines"
option in the diff utility.
Can i get some pointers on two sample files which can demonstrate the
use of --horizon-lines=lines
I understood the theory / definition from the info / man file.
However, I am
When a .gitattributes file specifies a diff and the locale is utf8,
"git diff --color-words" fails with the message "fatal: Invalid
regular expression
[a-zA-Z_][a-zA-Z0-9_]*|[-+0-9.e]+[fFlL]?|0[xXbB]?[0-9a-fA-F]+[lLuU]*|[-+*/<>%&^|=!]=|--|\+\+|<<=?|>>=?|&
repository, right-click
> any commit, pick "show changes as unified diff", there's an error
> dialog:
>
> ```
> Could not get unified diff.
>1 [main] git 2292 child_copy: cygheap read copy failed,
> 0x180302408..0x18030F230, done 0, windows pid 2292, Win32 err
onder if anybody
else is using TortoiseGit with Cygwin's git and "Show changes as
unified diff" in TortoiseGit's log work for them?
--
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
Hi Gene,
On Thu, Nov 17, 2016 at 12:42 AM, Gene Pavlovsky wrote:
> Hey everybody!
>
> I'm using TortoiseGit with Cygwin git (Cygwin workarounds enabled in
> advanced TortoiseGit settings). For the most part, everything works
> correctly.
Although this is probably unrelated, I've had problems with
Hey everybody!
I'm using TortoiseGit with Cygwin git (Cygwin workarounds enabled in
advanced TortoiseGit settings). For the most part, everything works
correctly.
The only problem: in TortoiseGit log for any repository, right-click
any commit, pick "show changes as unified diff", t
Wb Yang wrote:
> 3. I also tried to run this with gdb this afternoon. How ever, since
> the 1.9.1-1's "subversion-debuginfo" is not available from the
> setup-x86_64.exe yet, I was not able to figure out the exact exception
> source. Do you know where-else can I download a copy of the debug
> inf
Thanks Dave,
1. I didn't type in the command correctly, it was like "svn diff -c
12345 MY-REPO-URL";
2. Your recipe works fine here;
3. I also tried to run this with gdb this afternoon. How ever, since
the 1.9.1-1's "subversion-debuginfo" is not available from t
Wb Yang wrote:
> Segmentation fault happens 100% when calling:
>
> svn diff -c .
"svn diff -c ." is not a valid command. The "-c" switch expects a
numeric argument. I get an error message when I try it, not a segfault.
Does this recipe work for you?
% mkdir /tmp
This is the "cygcheck.out".
I removed the information under "id.exe" and "UATDATA" since it's my
company's working desktop:
///
Cygwin Configuration Diagnostics
Current System Time: Thu Sep 10 07:50:41
Segmentation fault happens 100% when calling:
svn diff -c .
In "svn.exe.stackdump":
/
Exception: STATUS_ACCESS_VIOLATION at rip=001801
>> Volume Name:
> >> Serial Number : 3357258338
> >
> > This was it. I changed the Volume Serial Number with a Sysinternals tool
> > (https://technet.microsoft.com/en-us/sysinternals/bb897436.aspx)
> > and after a reboot diff now recurses into t
Serial Number with a Sysinternals tool
> (https://technet.microsoft.com/en-us/sysinternals/bb897436.aspx)
> and after a reboot diff now recurses into the directories in question.
>
> Now is this a Cygwin bug or am I doing something terribly unsupported?
The serial number is used
als tool
> (https://technet.microsoft.com/en-us/sysinternals/bb897436.aspx)
> and after a reboot diff now recurses into the directories in question.
> Now is this a Cygwin bug or am I doing something terribly unsupported?
Volume serial numbers are supposed to be unique... At least within
>
>-Original-Nachricht-
>Betreff: Re: diff -r won't recurse
>Datum: Sat, 04 Apr 2015 20:29:40 +0200
>Von: "lemke...@t-online.de"
>An: cygwin@cygwin.com
>
>>On Sat, 04 Apr 2015 20:09:56 +0200 I wrote:
>>On Fri, 03 Apr 2015 16:50:09 +0200 And
>On Sat, 04 Apr 2015 20:09:56 +0200 I wrote:
>On Fri, 03 Apr 2015 16:50:09 +0200 Andrey Repin wrote:
>>> I've got a strange problem: diff -r /d /g won't recurse into the two
>>> directories. /d and /g are the
>>> roots of two disks where /g is
On Fri, 03 Apr 2015 16:50:09 +0200 Andrey Repin wrote:
>> I've got a strange problem: diff -r /d /g won't recurse into the two
>> directories. /d and /g are the
>> roots of two disks where /g is a clone (disk2vhd) of /d. ls -R and other
>> tools have no pro
Greetings, Erwin Waterlander!
>> I've got a strange problem: diff -r /d /g won't recurse into the two
>> directories. /d and /g are the
>> roots of two disks where /g is a clone (disk2vhd) of /d. ls -R and other
>> tools have no problems
>> to walk
Op 3-4-2015 om 16:17 schreef lemke...@t-online.de:
I've got a strange problem: diff -r /d /g won't recurse into the two
directories. /d and /g are the
roots of two disks where /g is a clone (disk2vhd) of /d. ls -R and other tools
have no problems
to walk the tree. strace doesn&#
Greetings, lemke...@t-online.de!
> I've got a strange problem: diff -r /d /g won't recurse into the two
> directories. /d and /g are the
> roots of two disks where /g is a clone (disk2vhd) of /d. ls -R and other
> tools have no problems
> to walk the tree. strace doe
I've got a strange problem: diff -r /d /g won't recurse into the two
directories. /d and /g are the
roots of two disks where /g is a clone (disk2vhd) of /d. ls -R and other tools
have no problems
to walk the tree. strace doesn't give me a clue. Any ideas?
>On 2/11/2013 12:49 PM, Ken Brown wrote:
>> On 2/11/2013 12:09 PM, Rockefeller, Harry wrote:
>>> When using subversion 1.7.8-2 in emacs 24.2.93-1 "vc-dir" mode and I
>>> "vc-dir-mark" a file then move cursor to a different file and attempt
>>&
On 2/11/2013 12:49 PM, Ken Brown wrote:
On 2/11/2013 12:09 PM, Rockefeller, Harry wrote:
When using subversion 1.7.8-2 in emacs 24.2.93-1 "vc-dir" mode
and I "vc-dir-mark" a file then move cursor to a different file and
attempt "vc-diff" the diff is always perfor
On 2/11/2013 12:09 PM, Rockefeller, Harry wrote:
When using subversion 1.7.8-2 in emacs 24.2.93-1 "vc-dir" mode
and I "vc-dir-mark" a file then move cursor to a different file and
attempt "vc-diff" the diff is always performed on the marked file
and not the one unde
On 12/01/2012 09:17, Fergus wrote:
> Hello,
> I want to compare the contents of two large directories whilst omitting
> two subdirectories console5/ and console7/ common to both. But using any
> combination of
> diff -rq /d1 /d2 -x console
> diff -rq /d1 /d2 -x console.
>
Hello,
I want to compare the contents of two large directories whilst omitting
two subdirectories console5/ and console7/ common to both. But using any
combination of
diff -rq /d1 /d2 -x console
diff -rq /d1 /d2 -x console.
diff -rq /d1 /d2 -x "console./"
(and several others I tho
On Mon, May 9, 2011 at 3:11 PM, retrodans wrote:
>
> Okay, that seems much better, for some reason the file wasn't going onto the
> root of c, but running it directly to desktop worked a treat, so have
> attached the file now.
If you run from the command prompt, then your current directory is
/ho
hem." -- Linus Torvalds
>
> --
> 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
>
>
>
http:/
On Mon, May 9, 2011 at 1:52 PM, retrodans wrote:
>
> diffutils appears to be there, so I went to run cygcheck for you as per the
> link you sent, but that doesn't appear to create a file on my c: amd just
> returns several warnings along the lines of:
> OpenService failed for
>
> This is for thing
apper, RpcSs
Do I need to install a specific package for this to work?
Václav Haisman wrote:
>
> retrodans wrote, On 9.5.2011 13:26:
>>
>> I am trying to run what is a basic diff of 2 tags in a repo, to see what
>> changes have occurred between the 2. But whenever I att
retrodans wrote, On 9.5.2011 13:26:
>
> I am trying to run what is a basic diff of 2 tags in a repo, to see what
> changes have occurred between the 2. But whenever I attempt to in cygwin I
> get the below error. Is this a known issue, or do I need to set something
> up specia
I am trying to run what is a basic diff of 2 tags in a repo, to see what
changes have occurred between the 2. But whenever I attempt to in cygwin I
get the below error. Is this a known issue, or do I need to set something
up specially to get this working. Sorry I am newish to cygwin as use
mount command.
Now commands like 'ls' and 'find' all show that the shadow copy is
properly mounted.
When I run 'diff' on an *individual* file to check for differences
between the shadow copy and the original it works perfectly.
HOWEVER, when I run 'diff -ruw&#x
Greetings, Csaba Raduly!
> Andrey Repin wrote:
>>>>> When I'm comparing them with my usual macro
>>>>> diff -bdu -x "CVS" -x ".svn" -I "\$Id.*\$" -I "\$Revision.*\$" -I
>>>>> "\$Date.*\$"
Greetings, Brian Wilson!
> Lastly do you need to use the "-x PATtern" exclusion options? You are
> already specifying the two files to diff
> so you shouldn't need these options.
It is part of my shell macro, so I can compare CVS/Subversion working copies
without m
Andrey Repin wrote:
>>>> When I'm comparing them with my usual macro
>>>> diff -bdu -x "CVS" -x ".svn" -I "\$Id.*\$" -I "\$Revision.*\$" -I
>>>> "\$Date.*\$" -I "\$Author.*\$" --strip-trailing-
>> The new version I've imported to Subversion:
>>>
>>> > @echo off
>>> > rem $Id: backup.bat 10 2010-09-30 01:22:14Z anrdaemon $
>>> > rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list
>>>
>>> When I'm comparing
7 01:53:30 Daemon Exp $
>> > rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list
>>
>> The new version I've imported to Subversion:
>>
>> > @echo off
>> > rem $Id: backup.bat 10 2010-09-30 01:22:14Z anrdaemon $
>> > rar a -ag--MM-D
> rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list
>
> The new version I've imported to Subversion:
>
> > @echo off
> > rem $Id: backup.bat 10 2010-09-30 01:22:14Z anrdaemon $
> > rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list
>
>
@MinerTimer.list
The new version I've imported to Subversion:
> @echo off
> rem $Id: backup.bat 10 2010-09-30 01:22:14Z anrdaemon $
> rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list
When I'm comparing them with my usual macro
diff -bdu -x "CVS" -x "
> Found it.
> Fixed in CVS.
Downloaded cygwin1-20100824.dll.
Working perfectly. Thanks so much.
Fergus
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin
Greetings, Corinna Vinschen!
>> >> The change from binmode to textmode seems to be induced by the
>> >> command mount -c "/" [...]
>>
>> > Found it. The method to compute the mount flags from the options
>> > given to the mount(1) command have been changed and accidentally the
>> > default is 0,
On Aug 24 22:24, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
> >> The change from binmode to textmode seems to be induced by the
> >> command mount -c "/" [...]
>
> > Found it. The method to compute the mount flags from the options
> > given to the mount(1) command have been changed and
Greetings, Corinna Vinschen!
>> The change from binmode to textmode seems to be induced by the
>> command mount -c "/" [...]
> Found it. The method to compute the mount flags from the options
> given to the mount(1) command have been changed and accidentally the
> default is 0, instead of MOUNT_
On Aug 24 14:12, Fergus wrote:
> >> Would you mind to paste the file content of /etc/fstab and, if it
> >> exists, /etc/fstab.d/$USER into your reply?
>
> > Oh and, btw., could you please test if this still occurs with the
> > latest developer snapshot from http://cygwin.com/snapshots/
>
> Thanks
>> Would you mind to paste the file content of /etc/fstab and, if it
>> exists, /etc/fstab.d/$USER into your reply?
> Oh and, btw., could you please test if this still occurs with the
> latest developer snapshot from http://cygwin.com/snapshots/
Thanks as usual for taking an interest and trying
On Aug 24 10:09, Corinna Vinschen wrote:
> On Aug 24 07:17, Fergus wrote:
> > This is an utterly horrid change (binmode to textmode) but I guess
> > it is intended (and was probably discussed forever in advance of
> > making it). Please can you confirm (intended change), or is this a
> > glitch (u
On Aug 24 07:17, Fergus wrote:
> >I'd suspect that /m and /d are on text mounts
> >and your home directory is on a binary mount, or vice versa.
>
> Thank you. Something's changed though not quite as described above.
>
> Has something changed in the conventions for default mounts? I've
> either mi
I'd suspect that /m and /d are on text mounts
and your home directory is on a binary mount, or vice versa.
Thank you. Something's changed though not quite as described above.
Has something changed in the conventions for default mounts? I've either
missed something, or I'm doing something wrong
On 2010-08-23 09:57, Fergus wrote:
Somehow diff identifies differences in two identical binary files. In
the following example two duplicate files are located (i) in my home
directory (/m/home/user) and (ii) at the root of a different drive (D:).
[snip]
~> diff -s INTERVAL.pdf /d/INTERVAL.
On 23 August 2010 14:57, Fergus wrote:
> (Very sorry if this arrives twice: one sent 3H ago seems not to have made it
> and I think maybe a AV induced signature was the cause: not provided with
> this despatch.)
>
> Ouch, this is weird and inexplicable.
>
> Somehow diff iden
o
directories explored below have identical contents, not the 3
differences identified:
~> diff -rq /home /l/home
Files /home/user/sav/bookmarks.html and /l/home/user/sav/bookmarks.html
differ
Files /home/user/sav/userTheme.Theme and
/l/home/user/sav/userTheme.Theme differ
Files /home/user/tex/sho
~> diff -s INTERVAL.pdf /d/INTERVAL.pdf
Files INTERVAL.pdf and /d/INTERVAL.pdf differ
~> diff -s ./INTERVAL.pdf /d/INTERVAL.pdf
Files ./INTERVAL.pdf and /d/INTERVAL.pdf differ
~> diff -s ~/INTERVAL.pdf /d/INTERVAL.pdf
Files /home/user/INTERVAL.pdf and /d/INTERVAL.pdf differ
~> diff -
(Very sorry if this arrives twice: one sent 3H ago seems not to have
made it and I think maybe a AV induced signature was the cause: not
provided with this despatch.)
Ouch, this is weird and inexplicable.
Somehow diff identifies differences in two identical binary files. In
the following
On Aug 19 19:31, Pedro Izecksohn wrote:
> ChangeLog entry:
>
> 2010-08-19 Pedro Izecksohn
>
> * endian.h [_BSD_SOURCE || ! _POSIX_SOURCE] (htobe16, htobe32)
> (htobe64, be16toh, be32toh, be64toh, htole16, htole32, htole64)
> (le16toh, le32toh, le64toh): Macros defined.
>
>
ChangeLog entry:
2010-08-19 Pedro Izecksohn
* endian.h [_BSD_SOURCE || ! _POSIX_SOURCE] (htobe16, htobe32)
(htobe64, be16toh, be32toh, be64toh, htole16, htole32, htole64)
(le16toh, le32toh, le64toh): Macros defined.
I modified endian.h again:
*** /usr/include/endi
On Aug 17 22:44, Pedro Izecksohn wrote:
> --- Corinna Vinschen wrote:
> >
> > For this patch, given that it is just a bunch of rather obvious
> > defines, I don't think we have to treat the patch as significant.
>
> I do not think that these macros are obvious. I think that I was
> there when th
--- Corinna Vinschen wrote:
>
> For this patch, given that it is just a bunch of rather obvious
> defines, I don't think we have to treat the patch as significant.
I do not think that these macros are obvious. I think that I was
there when these macros were first implemented at 1987: I talked wi
Pedro,
first of all, did you read http://cygwin.com/contrib.html? Especially
the "Before you get started" section.
For this patch, given that it is just a bunch of rather obvious
defines, I don't think we have to treat the patch as significant.
However, please don't use _BSD_SOURCE. The newli
As this thread went nowhere, I searched for the BSD code:
http://svn.freebsd.org/viewvc/base/stable/8/sys/sys/endian.h?revision=199583&view=markup
It uses x to represent the variable as I did; but it also casts the variable.
I think that casting is not desirable because I like to see warnin
--- I wrote:
>> The x glyph represents the different ways to represent the same number:
>> ...
>> I thought to use (i) of integer, but its glyph does not remember the
>> proverb about Rome.
--- Corinna Vinschen asked:
> You mean "What have the Romans ever done for us?"
"All roads lead to Rome."
On Aug 13 19:11, Pedro Izecksohn wrote:
> I thought to use (i) of integer, but its glyph does not remember the
> proverb about Rome.
You mean "What have the Romans ever done for us?"
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader
> Umm - did you copy straight from glibc's endian.h? That's a no-no;
> cygwin generally doesn't want to borrow LGPL sources to avoid any
> licensing questions (borrowing from BSD is okay, on the other hand).
> You would have to implement things from scratch from a documentation
> page, or copy fro
--- Eric Blake wrote:
>
> Umm - did you copy straight from glibc's endian.h? That's a no-no;
> cygwin generally doesn't want to borrow LGPL sources to avoid any
> licensing questions (borrowing from BSD is okay, on the other hand).
> You would have to implement things from scratch from a document
On 08/12/2010 06:35 PM, Pedro Izecksohn wrote:
> --- I wrote:
>> Defines macros for to convert the endianness of 16, 32 and 64 bits
>> integer types.
>>
>> diff -c /usr/include/endian.orig.h /usr/include/endian.h
>
> My previous diff is wrong. The right one fo
--- I wrote:
> Defines macros for to convert the endianness of 16, 32 and 64 bits
> integer types.
>
> diff -c /usr/include/endian.orig.h /usr/include/endian.h
My previous diff is wrong. The right one follows:
*** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010
--- /usr/incl
--- Eric Blake wrote:
> Christopher Faylor wrote:
>> I wrote:
>>> I hope this list accepts attachments.
>>
>> It does but the list mind-reading gizmo is on the fritz.
>
> Translation - a ChangeLog entry justifying your changes, a diff in
> unified or co
On 08/12/2010 04:58 PM, Christopher Faylor wrote:
> On Thu, Aug 12, 2010 at 07:56:31PM -0300, Pedro Izecksohn wrote:
>> I hope this list accepts attachments.
>
> It does but the list mind-reading gizmo is on the fritz.
Translation - a ChangeLog entry justifying your changes, a
On Thu, Aug 12, 2010 at 07:56:31PM -0300, Pedro Izecksohn wrote:
> I hope this list accepts attachments.
It does but the list mind-reading gizmo is on the fritz.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://
I hope this list accepts attachments.
endian.h.diff
Description: Binary data
--
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
x27;t remove any patterns that are already in that list.
So, I tried to create a generic facility where you could, for instance, do:
DIFF_NO_EXCLUDES="configure Makefile.in *.m4"
and then cygport would ensure that, even if it ordinarily would exclude
a file from the diff, if tha
/Test_Setup_Diff_2.t
xt
Is this large diff file produced because one program is using cr & lf
while
the other program just uses a cr or a lf?
In Xemacs I just hit "enter", then do a destruc
On Tue, Mar 16, 2010 at 5:00 PM, David Eisner wrote:
> Cygwin versions (2.8.7 and 2.5.8 respectively). When I get a chance,
> I'll try the newer versions on Linux and see what happens.
Also works fine on Linux with patch 2.5.8 (and diff 2.9 -- version
2.8.7 was never a stable relea
ris 10). This was
running CentOS 5.4, GNU diff 2.8.1, patch 2.5.4. These are the same
versions on the Solaris box as it turns out. Both are older than the
Cygwin versions (2.8.7 and 2.5.8 respectively). When I get a chance,
I'll try the newer versions on Linux and see what happens.
&g
Hello David,
* On Tue, Mar 16, 2010 at 03:15:13PM -0400 David Eisner wrote:
> I'm running into a problem when applying patches. Here's a toy
> example. I have a file, test.txt, with a one line change. I use diff
> -u to generate a patch, and then I use patch to apply it.
&
I'm running into a problem when applying patches. Here's a toy
example. I have a file, test.txt, with a one line change. I use diff
-u to generate a patch, and then I use patch to apply it.
With unix-style line-endings (\n), everything works fine:
$ file {a,b}/test.txt
a/test.txt: AS
PACKAGE DESCRIPTION
===
Homepage: http://www-verimag.imag.fr/~moy/opendocument
License : GPL
A git diff filter program to make it possible to diff OpenDocument
(OpenOffice, Koffice ...) documents. A wrapper script to odt2txt
program.
CHANGES SINCE LAST RELEASE
On Monday, October 26, 2009, Kenneth Chiu wrote:
> cmp doesn't recurse, though, at least as far as I can tell.
> In theory, I could use find, then cmp, plus some scripting,
> but seems simpler to just write a small C program
> to do it.
Well, as a start, you could try this:
find "$src" -type f -
-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
Of Buchbinder, Barry (NIH/NIAID) [E]
Sent: Monday, October 26, 2009 2:49 PM
To: cygwin@cygwin.com; Kenneth Chiu
Subject: RE: How to increase the memory available to diff in cygwin 1.7?
Kenneth
Well, it really depends on one's familiarity. I can run
find on both directory roots, to get a list of all files. I
want breadth-first, but I think find can do that.
The output needs to be sorted for each directory, since I
also need to find files in one that are not in the other. I
am not sure
Kenneth Chiu writes:
" cmp doesn't recurse, though, at least as far as I can tell.
" In theory, I could use find, then cmp, plus some scripting,
" but seems simpler to just write a small C program
" to do it.
Really? Your definition of 'simpler' may differ from mine, but
given an existing tool fo
cmp doesn't recurse, though, at least as far as I can tell.
In theory, I could use find, then cmp, plus some scripting,
but seems simpler to just write a small C program
to do it.
On Mon, Oct 26, 2009 at 2:48 PM, Buchbinder, Barry (NIH/NIAID) [E]
wrote:
> Kenneth Chiu sent the following at Monday
Kenneth Chiu sent the following at Monday, October 26, 2009 2:29 PM
>
>Considering that I only want to know whether or not two files differ,
>this should not require any significant memory usage. (In other words,
>don't use mmap().)
If you only want to know whether or not they are identical, use c
Hm...I thought that discussion was actually about grep, but,
nonetheless, it does seem increasingly likely that this
is just a problem with diff.
Considering that I only want to know whether or not two files
differ, this should not require any significant memory usage.
(In other words, don'
On Mon, Oct 26, 2009 at 11:41:13AM -0400, Kenneth Chiu wrote:
>I'm trying to diff two large directories, recursively, and
>I'm getting this error:
>
>$ diff -rq B B2 >diff.out
>diff: memory exhausted
>
>I looked at this URL
>
>http://cygwin.com/c
I'm trying to diff two large directories, recursively, and
I'm getting this error:
$ diff -rq B B2 >diff.out
diff: memory exhausted
I looked at this URL
http://cygwin.com/cygwin-ug-net/setup-maxmem.html
but it seemed out-of-date. There was no such key in the
regi
On Tue, Oct 20, 2009 at 02:56:11PM +0100, Fergus wrote:
>Windows 7, Cygwin [1.7] latest snapshot 20091012.
>Comparing two large subdirectories with diff leads to error msg.
>Output from cygcheck -srv attached.
>
>~> diff -rq /d/home /m/home
> 6 [main] diff 3720 sig_send:
Windows 7, Cygwin [1.7] latest snapshot 20091012.
Comparing two large subdirectories with diff leads to error msg.
Output from cygcheck -srv attached.
~> diff -rq /d/home /m/home
6 [main] diff 3720 sig_send: error sending signal -34 to pid
3720, pipe handle 0x10C, Win32 error 998
5069
On Tue, Sep 01, 2009 at 04:47:16PM +0200, Torsten Sch?tze wrote:
>Christopher Faylor wrote:
>Okay, here we are. Using the 2009-09-01 snapshot
>(cygwin1-20090901.dll.bz2, cygwin1-20090901.dbg.bz2) I obtain:
>
>First, in directory 2009 (corresponds to diff.exe.stackdump-1), see
>attachment diff.exe.s
Christopher Faylor wrote:
> On Tue, Sep 01, 2009 at 04:01:06PM +0200, Torsten Sch?tze wrote:
>> Hi,
>>
>> I've installed Cygwin Beta 1.7.0 (version -51) around mid of July.
>> Currently, version -60 is installed. Now (at least since version -53 or
>> so)
On Tue, Sep 01, 2009 at 04:01:06PM +0200, Torsten Sch?tze wrote:
>Hi,
>
>I've installed Cygwin Beta 1.7.0 (version -51) around mid of July.
>Currently, version -60 is installed. Now (at least since version -53 or
>so) I repeatedly encounter a bug with diff (diffutils 2.8.
Hi,
I've installed Cygwin Beta 1.7.0 (version -51) around mid of July.
Currently, version -60 is installed. Now (at least since version -53 or
so) I repeatedly encounter a bug with diff (diffutils 2.8.7-1). I use
diff to compare my working directory with the files on an usb stick. The
On Wed, Aug 5, 2009 at 6:18 AM, Dave Korn wrote:
> Paul McFerrin wrote:
>> I believe this is a non-problem.
> This is a 1.7-vs-1.5 difference in the underlying Cygwin DLL then, and not
> related to ksh; yes?
What part of "non-problem" do you not understand, Dave? ;)
Seriously, is it a differenc
Paul McFerrin wrote:
> I believe this is a non-problem. The cause: human error. Doing a
>cd /c/Doc*/pa*/App*is not the same as
>cd /c/Doc*/Pa*/App*
> Wildcard lookups are always case sensitive. I must not have been
> consistant when switching between Windows.
This is a 1.7-vs-1.
I believe this is a non-problem. The cause: human error. Doing a
cd /c/Doc*/pa*/App*is not the same as
cd /c/Doc*/Pa*/App*
Wildcard lookups are always case sensitive. I must not have been
consistant when switching between Windows.
Paul McFerrin wrote:
Dave: Let's put this prob o
Dave: Let's put this prob on hold for a while. At least til I
investigate it some more. Something is acting weird. This prob has
disappeared! I tried unloading everything just in case some name cache
had it already expanded. I did get correct results from using latest
pdksh. Weird.
Dav
Paul McFerrin wrote:
> Just want to point out a slightly difference in behavior of ksh
>@(#)PD KSH v5.2.14 99/07/13.2
> between Cygwin 1.5 & 1.7 First, the above is a older version of pdksh
> that I had to tweek the cygwin sources a l-o-n-g time ago. Under 1.5,
> the following does work prope
1 - 100 of 208 matches
Mail list logo
