On 08/20/2014 02:58 PM, ml...@bogusville.us wrote:
> using CYGWIN_NT-6.1, bash 4.1.11(2) and find 4.5.12, the following returns
> immediately
>
>find . -name \*.cs -o -name \*.h -o -name \*.cpp -exec ls {} \;
This parses as:
find . -name \*.cs -o -name \*.h -o \( -name \*.cpp -exec ls {} \; \
Greetings, ml...@bogusville.us!
> using CYGWIN_NT-6.1, bash 4.1.11(2) and find 4.5.12, the following returns
> immediately
>find . -name \*.cs -o -name \*.h -o -name \*.cpp -exec ls {} \;
> pick your favorite for 'ls'
$ uname -a
CYGWIN_NT-5.1 daemon2 1.7.32s(0.274/5/3) 20140807 16:26:58 i68
On Aug 20, 2014, at 16:58 , ml...@bogusville.us wrote:
> using CYGWIN_NT-6.1, bash 4.1.11(2) and find 4.5.12, the following returns
> immediately
>
> find . -name \*.cs -o -name \*.h -o -name \*.cpp -exec ls {} \;
Not a Cygwin problem. Try:
find . \( -name \*.cs -o -name \*.h -o -na
using CYGWIN_NT-6.1, bash 4.1.11(2) and find 4.5.12, the following returns
immediately
find . -name \*.cs -o -name \*.h -o -name \*.cpp -exec ls {} \;
pick your favorite for 'ls'
this works as expected
find . -name \*.cs -o -name \*.h -o -name \*.cpp
it's probably not a horrible problem
On May 16 13:29, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > Fixed in CVS.
>
> Thank you!
>
> > Dunno where the man page error stems from
>
> Still, it'd be great to fix that, too.
>
> > -f, --trace-children trace child processes (toggle - default
> > true)
>
> But somehow when -
> Fixed in CVS.
Thank you!
> Dunno where the man page error stems from
Still, it'd be great to fix that, too.
> -f, --trace-children trace child processes (toggle - default
> true)
But somehow when -f is specified, strace can't continue but gets stuck
waiting for the child process to
On May 16 01:56, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> $ strace --help
> ...
> -V, --versionoutput version information and exit
> ...
>
> So man page needs to be more *case-sensitive*. Also, it looks like -f
Dunno where the man page error stems from, but the official do
> I meant /cygdrive/c/...
... and I was trying to identify the problem myself but got into another thing,
now with strace:
when trying to use the "-f" flag that I used to use on Linux to trace
child processes, the entire command just hanged:
$ strace -f -o find.strace find . -name dir -type d -e
> The same at either Windows-native drive (/cygwin/c/...)
I meant /cygdrive/c/...
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
Hello,
I'm using 32-bit Cygwin 1.7.18. The problem I'm seeing can
be replayed with this sequence of commands:
-- begin --
$ mkdir dir
$ ls -d dir
dir
$ find . -type d -name dir -print
./dir
$ find . -type d -name dir -exec rm -rf {} \;
find: './dir': Not a directory
-- end --
The same at eith
On 12/07/2010 01:02 PM, qatmo-gi...@stanfordalumni.org wrote:
>
> When I updated the findutils package to 4.5.9-2, find no longer works.
>
> It returns nothing when run. Not even `/bin/find --help` or `/bin/find
> -version` return anything.
You have a missing dll, and/or conflicting versions of
find --version works fine for me.
Perhaps it's time for the -srv...
--
Lee Maschmeyer
Wayne State University Computing Center
5925 Woodward, #281
Detroit MI 48202
USA
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: h
When I updated the findutils package to 4.5.9-2, find no longer works.
It returns nothing when run. Not even `/bin/find --help` or `/bin/find
-version` return anything.
cygcheck -s shows the new findutils as 4.5.9-2
When I roll back to 4.5.8-1, all the above work as expected.
Didn't see any m
On Apr 16 12:58, Gary . wrote:
> $ find / -name pg_hba.conf -print
> find:
> `/proc/registry/HKEY_CLASSES_ROOT/*/shellex/PropertySheetHandlers/CryptoSignMenu':
> Bad address
> assertion "ent->fts_info == FTS_NSOK || state.type != 0" failed: file
> "/usr/src/findutils-4.5.5-1/src/findutils-4.5.5/fi
$ find / -name pg_hba.conf -print
find:
`/proc/registry/HKEY_CLASSES_ROOT/*/shellex/PropertySheetHandlers/CryptoSignMenu':
Bad address
assertion "ent->fts_info == FTS_NSOK || state.type != 0" failed: file
"/usr/src/findutils-4.5.5-1/src/findutils-4.5.5/find/ftsfind.c", line
477, function: consider
All,
I have the same problem as highlighted in this post:
http://www.cygwin.com/ml/cygwin/2005-10/msg00510.html
I updated Cygwin for the first time in many months, and now
'find' is broken. I actually discovered it by running 'updatedb', which
produces no results right now because of 'find' being
I would like to report that "find -printf %n" appends a spurious 'd' to the
output produced.
This happens also for %G, %U, %b, %D, %k format directives.
Under Cygwin:
=
% cygcheck -v -s | grep ^find
findutils 20041227-1
% for i in G U b D k n; do
fmt="%12$i\t%f\n"
echo \"$fmt\":
On Wed, Oct 13, 2004 at 07:43:33PM -0700, Joshua Daniel Franklin wrote:
>On Tue, 12 Oct 2004 12:04:11 -0600, Mark Paulus <[EMAIL PROTECTED]> wrote:
>> Thanks. I was not aware of the -print0 option. This is
>> what I love about *n*x: Always something new to learn,
>> or another way to find a solu
On Tue, 12 Oct 2004 12:04:11 -0600, Mark Paulus <[EMAIL PROTECTED]> wrote:
> Thanks. I was not aware of the -print0 option. This is
> what I love about *n*x: Always something new to learn,
> or another way to find a solution.
What! Do NOT use -print0! It will null-terminate EVERY LINE!
--
Unsu
Mark Paulus wrote:
>
> Another issue I've run into with find, but typically when I pipe
> it to xargs is that directories/files with spaces in the names cause
> all kind of disruption.
Add "-print0" to your find arguments and "-0" to your xargs arguments
and that problem will disappear.
Brian
-
Thanks. I was not aware of the -print0 option. This is
what I love about *n*x: Always something new to learn,
or another way to find a solution.
On Tue, 12 Oct 2004 13:14:12 -0400, Christopher Faylor wrote:
>On Tue, Oct 12, 2004 at 11:00:35AM -0600, Mark Paulus wrote:
>>Another issue I've r
On Tue, 12 Oct 2004, Mark Paulus wrote:
> Another issue I've run into with find, but typically when I pipe
> it to xargs is that directories/files with spaces in the names cause
> all kind of disruption.
Not related to this thread, and actually not Cygwin-specific. Use "find
... -print0 | xargs
On Tue, Oct 12, 2004 at 11:00:35AM -0600, Mark Paulus wrote:
>Another issue I've run into with find, but typically when I pipe
>it to xargs is that directories/files with spaces in the names cause
>all kind of disruption.
So use "find -print0 | xargs -0".
cgf
--
Unsubscribe info: http://cyg
Another issue I've run into with find, but typically when I pipe
it to xargs is that directories/files with spaces in the names cause
all kind of disruption.
On Tue, 12 Oct 2004 12:25:15 -0400 (EDT), Igor Pechtchanski wrote:
>On Tue, 12 Oct 2004, Daniel Miller wrote:
>> On linux systems, I typic
> On Tue, 12 Oct 2004, Daniel Miller wrote:
>
> > On linux systems, I typically to global searches with a command such as:
> >
> > find . -name "*.[ch]*" -exec grep -H -n stuff {} \;
> >
> > and this works nicely. However, when I try the same command under
Cygwin
> > (from a 4NT prompt, not Ba
On Tue, 12 Oct 2004, Daniel Miller wrote:
> On linux systems, I typically to global searches with a command such as:
>
> find . -name "*.[ch]*" -exec grep -H -n stuff {} \;
>
> and this works nicely. However, when I try the same command under Cygwin
> (from a 4NT prompt, not Bash), I get "f
On linux systems, I typically to global searches with a command such as:
find . -name "*.[ch]*" -exec grep -H -n stuff {} \;
and this works nicely. However, when I try the same command under Cygwin
(from a 4NT prompt, not Bash), I get "find: missing argument to '-exec' ".
I tried a vari
Sorry, I just wanna know why I used 'find' several days before and it worked fine
(without any error message).
After something unclear happened, cygdrive appear to my root. And I don't know if it
is related, find any file from the root up
always encounter the error of saying
find: /cygdrive/c/Doc
At 06:09 PM 5/7/2004, you wrote:
>Maybe I shall rephrase this.
>If 'find' command keep looking for files in cygdrive it will always screw up when it
>encounter directories that it doesn't have
>access.
>
>- Original Message -
>> If 'find' command keep looking for files in cygdrive it will
Maybe I shall rephrase this.
If 'find' command keep looking for files in cygdrive it will always screw up when it
encounter directories that it doesn't have
access.
- Original Message -
> If 'find' command keep looking for files in cygdrive it will always screw up when it
> encounter di
After I re-examine my root path I found there is something different in my /.
When I type ls I get
drwx--+ 4 mcdikcl2 None0 Apr 20 13:50 bin
dr-xr-xr-x7 00 0 Jan 1 1970 cygdrive
drwx--+ 26 mcdikcl2 None0 Apr 7 13:46 etc
-rw-r--r--
Alvyn Liang wrote:
$ find / -name 'inline*'
find: /cygdrive/c/Documents and Settings/Administrator: No such file or directory
There's nothing wrong here. It's just that you don't have permission to
open the Administrator home directory.
On Windows, sometimes you'll see the "no such file or direc
On Sat, Mar 27, 2004 at 12:05:22PM -0500, Pierre A. Humblet wrote:
>At 03:03 PM 3/26/2004 -0500, Christopher Faylor wrote:
>>[just to provide a non-flip answer to this subject]
>>On Wed, Mar 24, 2004 at 09:39:29PM -0500, Pierre A. Humblet wrote:
>>>On Wed, Mar 24, 2004 at 04:42:39PM -0500, Christop
At 03:03 PM 3/26/2004 -0500, Christopher Faylor wrote:
>[just to provide a non-flip answer to this subject]
>On Wed, Mar 24, 2004 at 09:39:29PM -0500, Pierre A. Humblet wrote:
>>On Wed, Mar 24, 2004 at 04:42:39PM -0500, Christopher Faylor wrote:
>>I wonder if
>> char *p = strrchr (src, '\0');
[just to provide a non-flip answer to this subject]
On Wed, Mar 24, 2004 at 09:39:29PM -0500, Pierre A. Humblet wrote:
>On Wed, Mar 24, 2004 at 04:42:39PM -0500, Christopher Faylor wrote:
>As you know isdirsep would take 1 extra compare per character.
>
>FWIW I see one place where we could avoid th
On Mar 24 23:15, Christopher Faylor wrote:
> On Wed, Mar 24, 2004 at 09:39:29PM -0500, Pierre A. Humblet wrote:
> >On Wed, Mar 24, 2004 at 04:42:39PM -0500, Christopher Faylor wrote:
> >>On Wed, Mar 24, 2004 at 04:30:57PM -0500, Pierre A. Humblet wrote:
> >>>
> >>>I also had a look at the code and
On Wed, Mar 24, 2004 at 11:33:44PM -0500, Larry Hall wrote:
>At 11:15 PM 3/24/2004, cgf wrote:
>>I'm quitting my job and getting a job as a psychic in the carnival!
>
>Aha! CGF unmasked! All his meanness stems from his frustrated, deep-
>rooted desire to be a 'carnie'!! Now it all makes sense.
>
>T
At 11:15 PM 3/24/2004, you wrote:
>On Wed, Mar 24, 2004 at 09:39:29PM -0500, Pierre A. Humblet wrote:
>>On Wed, Mar 24, 2004 at 04:42:39PM -0500, Christopher Faylor wrote:
>>>On Wed, Mar 24, 2004 at 04:30:57PM -0500, Pierre A. Humblet wrote:
I also had a look at the code and reached pretty
On Wed, Mar 24, 2004 at 09:39:29PM -0500, Pierre A. Humblet wrote:
>On Wed, Mar 24, 2004 at 04:42:39PM -0500, Christopher Faylor wrote:
>>On Wed, Mar 24, 2004 at 04:30:57PM -0500, Pierre A. Humblet wrote:
>>>
>>>I also had a look at the code and reached pretty much the same conclusion
>>>as Volker.
On Wed, Mar 24, 2004 at 04:42:39PM -0500, Christopher Faylor wrote:
> On Wed, Mar 24, 2004 at 04:30:57PM -0500, Pierre A. Humblet wrote:
> >
> >I also had a look at the code and reached pretty much the same conclusion
> >as Volker. Replacing all 'isslash (*src)' and 'isslash (src[x])' in
> >normali
On Wed, Mar 24, 2004 at 06:12:05PM -0500, Volker Quetschke wrote:
>>>I also had a look at the code and reached pretty much the same conclusion
>>>as Volker. Replacing all 'isslash (*src)' and 'isslash (src[x])' in
>>>normalize_posix_path by "isdirsep ()" would yield more consistent results.
>>>I kn
With the small problem that we're still working on src and not
dst, and we cannot do the replacement on src because it is const.
But I think you got the idea. Sorry
This is not done for "normal" DOS paths, IMHO consistency
would require that all remaining "\" are converted to "/" for all
paths. Is
I also had a look at the code and reached pretty much the same conclusion
as Volker. Replacing all 'isslash (*src)' and 'isslash (src[x])' in
normalize_posix_path by "isdirsep ()" would yield more consistent results.
I know this code is delicate but the possible drawback isn't obvious.
speed disadv
On Wed, Mar 24, 2004 at 04:30:57PM -0500, Pierre A. Humblet wrote:
>On Wed, Mar 24, 2004 at 03:56:44PM -0500, Christopher Faylor wrote:
>> On Wed, Mar 24, 2004 at 02:52:34PM -0500, Volker Quetschke wrote:
>> >Hi Corinna,
>> >
>> >>>Looks pretty similar to me, but I was looking for the following:
>>
Hi!
Sorry, I just have to ask this, see below.
So again, is this an expected/tolerated behaviour?
Yes, it's by design. The answer is "don't use DOS paths".
It's nice to be mean, isn't it?
How about some clarification: "Don't use DOS paths if you want
consistent i-nodes?"
You're welcome to use DO
On Wed, Mar 24, 2004 at 03:56:44PM -0500, Christopher Faylor wrote:
> On Wed, Mar 24, 2004 at 02:52:34PM -0500, Volker Quetschke wrote:
> >Hi Corinna,
> >
> >>>Looks pretty similar to me, but I was looking for the following:
> >>>
> >>>$ ls -ldin .\\tmp ./tmp
> >>>2919335057drwxr-xr-x 4 1006
On Wed, Mar 24, 2004 at 02:52:34PM -0500, Volker Quetschke wrote:
>Hi Corinna,
>
>>>Looks pretty similar to me, but I was looking for the following:
>>>
>>>$ ls -ldin .\\tmp ./tmp
>>>2919335057drwxr-xr-x 4 1006 513 0 Mar 10 13:06 ./tmp/
>>>2805415844195 drwxr-xr-x 4 1006 513
Hi Corinna,
Looks pretty similar to me, but I was looking for the following:
$ ls -ldin .\\tmp ./tmp
2919335057drwxr-xr-x 4 1006 513 0 Mar 10 13:06 ./tmp/
2805415844195 drwxr-xr-x 4 1006 513 0 Mar 10 13:06 .\tmp/
I came to that "program" by reducing the find soure to the b
On Mar 23 17:11, Volker Quetschke wrote:
> $ ls -ldin tmp tmp/.
> 2919335057 drwxr-xr-x 4 1006 513 0 Mar 10 13:06 tmp/
> 2919335057 drwxr-xr-x 4 1006 513 0 Mar 10 13:06 tmp/./
>
> Looks pretty similar to me, but I was looking for the following:
>
> $ ls -ldin .\\tmp ./tmp
> 2919
Hi Kaz,
I just found a strange problem when using find on a FAT drive.
I got: "find: .\tmp changed during execution of find"
OK, I analyzed the problem a bit and found that lstat can
give different inode numbers on fat, see the attached testcase.
Structurally, FAT does not have inodes or hard link
On Tue, 23 Mar 2004, Volker Quetschke wrote:
> Date: Tue, 23 Mar 2004 14:45:41 -0500
> From: Volker Quetschke <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [cygwin] lstat on FAT - Was: Problem with find on FAT drives
>
> > Hi!
> >
> > I just found
Hi!
I just found a strange problem when using find on a FAT drive.
I got: "find: .\tmp changed during execution of find"
OK, I analyzed the problem a bit and found that lstat can
give different inode numbers on fat, see the attached testcase.
To test this you have to have a directory called tmp in
Hi!
I just found a strange problem when using find on a FAT drive.
I got: "find: .\tmp changed during execution of find"
-- in bash shell --
[EMAIL PROTECTED] /cygdrive/d
$ find .\\tmp -name *.test
find: .\tmp changed during execution of find
[EMAIL PROTECTED] /cygdrive/d
$ find ./tmp -name *.test
Hi Mike,
>Also I didn't understand that
>shell stomps
>the ; and also, also I didn't know that the space was required
Well, I know, because I'd once stumbled, too .
>(the second
>line of the man page for find -exec doesn't have a space btw).
Uups. IIRC I *had* problems without the space.
>T
Hi Mike,
>find . -xdev -exec 'grep -l -F "string" {}';
>I'd be grateful if anyone can see what I'm doing wrong,
excerpt from the man page:
-exec command ;
Execute command; true if 0 status is returned. All following
arguments
to find are taken to be argume
Hi,
I'm using Cyywin on Win 98 SE and I have a problem with the find command.
The command I am trying to run is :
find . -xdev -exec 'grep -l -F "string" {}';
This command works fine on another flavour of unix but under Cygwin it gives
me the error :
find: missing argument to `-exec'
I'v
56 matches
Mail list logo
