[bugs #11879] all mount-points lstat()-ed, but shouldn't be

[anonymous]

Follow-up Comment #6, bugs #11879 (project findutils):

(From Martin Buchholz <[EMAIL PROTECTED]>)



I still see hangs in find 4.2.18, despite the

ChangeLog entry that suggests this has been fixed.



Even find --version hangs with this stacktrace



(dbx) where

  [1] _lstat64(0x4, 0xffbff160, 0x1, 0xfeabbe60, 0x81010100, 0xff00), at
0xfeb1abac 

=>[2] optionp_stat(name = 0x7a548 "/java/tl", p = 0xffbff160), line 229 in
"find.c"

  [3] set_fstype_devno(p = 0x79b58), line 182 in "fstype.c"

  [4] get_mounted_devices(n = 0x71114), line 278 in "fstype.c"

  [5] init_mounted_dev_list(), line 668 in "find.c"

  [6] main(argc = 2, argv = 0xffbff3c4), line 448 in "find.c"



where /java/tl is the remotely mounted filesystem that

is "down" during command execution.



This is pretty serious.  In a large networked environment,

there is always some NFS server that is broken or very slow

at the moment.



The --version flag at the very least should be handled

before trying to "do" any real work.

___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12064] make distclean deletes a distributed file

[anonymous]

URL:
  

 Summary: make distclean deletes a distributed file
 Project: findutils
Submitted by: None
Submitted on: Sun 02/20/2005 at 23:30
Category: find
Severity: 5 - Average
  Item Group: Compilation Failure
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Martin Buchholz
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.18
   Fixed Release: None

___

Details:

make distclean removes gnulib/lib/regex.c, but that

file is needed by a subsequent configure; make



make -n distclean



test -z "gnulib/lib/regex.c" || rm -f gnulib/lib/regex.c





___

Carbon-Copy List:

CC Address  | Comment
+-
martin --DOT-- buchholz --AT-- sun --DOT-- com | Originator Email




___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12085] -printf pathname:%/0.000000 gives wrong result

[anonymous]

URL:
  

 Summary: -printf pathname:%h/%f gives wrong result
 Project: findutils
Submitted by: None
Submitted on: Tue 02/22/2005 at 01:56
Category: find
Severity: 5 - Average
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.1.20
   Fixed Release: None

___

Details:

Wrong result for files without slashes:



# find Makefile po/Makefile -printf 'pathname:%h/%f\n'

/Makefile  <= ??!

pathname:po/Makefile



Patch fixes this:

# find.fixed Makefile po/Makefile -printf 'pathname:%h/%f\n'

pathname:./Makefile

pathname:po/Makefile





___

Carbon-Copy List:

CC Address  | Comment
+-
vda --AT-- ilport --DOT-- com --DOT-- ua | Originator Email



___

File Attachments:


---
Date: Tue 02/22/2005 at 01:56  Name: findutils-4.1.20.dirprintf.patch  Size:
673B   By: None



___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12064] make distclean deletes a distributed file

[anonymous]

Follow-up Comment #2, bugs #12064 (project findutils):

(From Martin Buchholz)



I cvs'ed the distribution and

followed the instructions in README-CVS (for the first time).



Unfortunately, I couldn't perform my test, because

configure; make distclean

failed as follows



make[1]: Entering directory `/home/martin/src/findutils/findutils/gnulib'

Making distclean in m4

/home/martin/src/findutils/findutils/gnulib/m4

make[2]: Entering directory `/home/martin/src/findutils/findutils/gnulib/m4'

Makefile:289: *** missing separator.  Stop.

make[2]: Leaving directory `/home/martin/src/findutils/findutils/gnulib/m4'

make[1]: *** [distclean-recursive] Error 1

make[1]: Leaving directory `/home/martin/src/findutils/findutils/gnulib'





Looking at gnulib/m4/Makefile.in, I see:



.PHONY: all all-am check check-am clean clean-generic distclean \

distclean-generic distdir dvi dvi-am info info-am install \

install-am install-data install-data-am install-exec \

install-exec-am install-info install-info-am install-man \

install-strip installcheck installcheck-am installdirs \

maintainer-clean maintainer-clean-generic mostlyclean \

mostlyclean-generic pdf pdf-am ps ps-am uninstall uninstall-am \

uninstall-info-am



alloca.m4 \

...



The obvious thing to do was to add two missing backslashes.



Then

configure; make distclean

gives the desired result (regex.c not deleted).

And I confirmed that no other file was deleted,

and that all the generated files are also part of

the distribution tarball.



So findutils is now distclean-clean, at least on Linux.



Could you file a (serious) bug against gnulib?





___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12044] find still hangs on dead NFS filesystems on Solaris

[anonymous]

Follow-up Comment #3, bugs #12044 (project findutils):

The current situation of having find hang when any remote

NFS server is unreachable is unacceptable, since it makes

my carefully engineered scripts fail due to the whims of

a flaky network.  I carefully prune PATH, for example,

to have as few dependencies on NFS servers as possible.

Stating the roots of all remote filesystem is even an 

invitation to a denial-of-service attack.



It is also unacceptable to erroneously follow symlinks,

since this could lead to unexpected manipulation of

arbitrary files.



What to do?  I still think we can have a robust find.



To chdir() to a subdir, you

- stat("."); save dot_fd;

- st = lstat(file); if ISDIR {

  chdir(file);

  check stat(".") matches st inode and filesystem.

  if not, fchdir(dot_fd) and retry.



Keep track of retry count.  Retry at least once, but perhaps

only once.



Another robust approach is to stat("..") after chdir,

and compare with stat(".") before chdir.



Another comment -- O_NOFOLLOW is very fragile, since

a version check is used, which must be updated on a 

regular (yearly?) basis.  I think it might be too early

to use O_NOFOLLOW in production software.

___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12044] find still hangs on dead NFS filesystems on Solaris

[anonymous]

Follow-up Comment #6, bugs #12044 (project findutils):

Regarding the fragility of OS version checks:



It is well accepted now that OS version checks

are a maintenance nightmare.  The "configure revolution"

of relying as much as possible on feature tests, either

at compile time or run time has been a vast improvement.



Compare the convoluted version checks that still litter

emacs configuration code.



One nice free software property is forkability.

If I create Martix, which is identical to Linux

except for the string returned by uname -s,

how many things will stop working or will work less well

in some very subtle way?

___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12044] find still hangs on dead NFS filesystems on Solaris

[anonymous]

Follow-up Comment #7, bugs #12044 (project findutils):



>I can imagine situation where one can subvert subdirectory >with symlink to
another subdirectory in the same directory.

>Second check cannot catch this situation.



Very good!  You've found a hole in the stat("..") strategy.

I (Martin Buchholz) hereby retract that suggestion.

___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12085] -printf pathname:%/0.000000 gives wrong result

[anonymous]

Follow-up Comment #3, bugs #12085 (project findutils):

Thanks for such a quick reaction

--

vda

___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12044] find still hangs on dead NFS filesystems on Solaris

[anonymous]

Follow-up Comment #9, bugs #12044 (project findutils):

>Regarding the OS version check, I think it very unlikely that 
>if the Matrix fork of Linux was released, it would be based 
>on a version of Linux that is now over 7 yeard old. They'd 
>fork a more recent version. Hence the example you give is 
>spurious. Findutils would not "stop working". If you take a 
>look at the check_nofollow() code I'm sure you'll >understand.

My point was that if someone forked the very latest
version of Linux, findutils would work "less well", since
check_nofollow() would fail.  I don't have a fix,
merely pointing out that the current algorithm is
linux-fork-hostile.

Martin


___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12064] make distclean deletes a distributed file

[anonymous]

Follow-up Comment #4, bugs #12064 (project findutils):

I did some follow-up work on this.

The problem is that bash prints the current directory
after a `cd' if CDPATH is defined.

So this code in import-gnulib.sh:

printf "%s" "EXTRA_DIST = "
cd  gnulib/m4
ls *.m4 | sed -e 's/$/ \\/' | sed -e '$ s/\\$//'

had undesired extra output from the cd command.

([EMAIL PROTECTED]) ~/src/findutils/findutils $ diff -u import-gnulib.sh~
import-gnulib.sh
--- import-gnulib.sh~   2005-01-24 01:37:19.0 -0800
+++ import-gnulib.sh2005-02-27 14:49:28.0 -0800
@@ -32,6 +32,7 @@
 
 destdir="gnulib"
 
+unset CDPATH
 
 # Modules needed for findutils itself.
 findutils_modules="\

Note that automake, for example, is also careful to
unset CDPATH.

./share/autoconf/m4sugar/m4sh.m4:220:# CDPATH.
./share/autoconf/m4sugar/m4sh.m4:221:$as_unset CDPATH

If you don't have enough to worry about, you might
also want to worry about IFS...

Martin

___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12181] find -H/-L symlink_to_dir reports "Too many levels of symbolic links"

[anonymous]

Follow-up Comment #3, bugs #12181 (project findutils):

To obtain the CVS code, please follow the instructions at
http://savannah.gnu.org/cvs/?group=findutils and then read the file
"README-CVS".   If you don't want to do that, you can wait for the next
release.

___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12235] POSIX/SUS compatibility not existing

[anonymous]

URL:
  

 Summary: POSIX/SUS compatibility not existing
 Project: findutils
Submitted by: None
Submitted on: Sun 03/06/2005 at 19:39
Category: xargs
Severity: 5 - Average
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

xargs does not support SUS options as laid out in
http://www.opengroup.org/onlinepubs/7990989775/xcu/xargs.html
A patch for adding some missing options was posted to bug-findutils in MARCH
2004:
http://lists.gnu.org/archive/html/bug-findutils/2004-03/msg5.html





___

Carbon-Copy List:

CC Address  | Comment
+-
gnu --AT-- andreas --DOT-- syndrom23 --DOT-- de | Originator Email




___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12235] POSIX/SUS compatibility not existing

[anonymous]

Follow-up Comment #2, bugs #12235 (project findutils):

Looks like problem comes due to old versions of findutils on the only linuxes
I have for testing (RH9, latest official findutils packages). 
Sorry for the bug report sounding rude, I was heavily annoyed while porting
software from linux, and because I did not see any answer to the cited thread
in bug-findutils, making me believe the options are still not available.

Bug can be closed if findutils are now posixly correct.


___

This item URL is:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bugs #12491] updatedb broken with solaris su

[anonymous]

URL:
  

 Summary: updatedb broken with solaris su
 Project: findutils
Submitted by: None
Submitted on: Mon 03/28/2005 at 08:36
Category: updatedb
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Tim Bishop
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

This is a problem with 4.2.20 (it's not in the Release box on the bug report
form).

The solaris su doesn't support the -s flag. So when update db runs something
like "su -s /bin/sh -c command" it ends up just starting /bin/sh.

Not sure on the best fix - I guess some way of disabling this feature at
runtime? It's worth noting that the FreeBSD su also doesn't support this
behaviour. Is it a linux-only feature?



___

Carbon-Copy List:

CC Address  | Comment
+-
tim --AT-- bishnet --DOT-- net  | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #12503] find dir -depth -empty returns not found

[anonymous]

URL:
  

 Summary: find dir -depth -empty returns not found
 Project: findutils
Submitted by: None
Submitted on: Tue 03/29/2005 at 14:35
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

In the latest findutils; 4.2.20

mkdir -p ~/test/blah; find ~/test -depth -empty

returns:

/mega/home/han/test/blah
find: /mega/home/han/test: No such file or directory




___

Carbon-Copy List:

CC Address  | Comment
+-
han --AT-- mijncomputer --DOT-- nl  | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #12503] find dir -depth -empty returns not found

[anonymous]

Follow-up Comment #1, bug #12503 (project findutils):

recompiling find fixed the problem... Suspicious...

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #12503] find dir -depth -empty returns not found

[anonymous]

Follow-up Comment #2, bug #12503 (project findutils):

Hmm it happens again and a recompile doesn't fix it this time:

% ls -R ~/.tmp
/mega/home/han/.tmp:
empty/
/mega/home/han/.tmp/empty:

Here is a strace:

execve("/usr/bin/find", ["find", "/mega/home/han/.tmp", "-depth", "-empty"],
[/* 38 vars */]) = 0
uname({sys="Linux", node="marsupilami", ...}) = 0
brk(0)  = 0x8056000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=51522, ...}) = 0
mmap2(NULL, 51522, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0QR\1\000"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1015160, ...}) = 0
mmap2(NULL, 978272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7ef1000
mmap2(0xb7fda000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe9) = 0xb7fda000
mmap2(0xb7fde000, 7520, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fde000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7ef
mprotect(0xb7fda000, 4096, PROT_READ)   = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ef0ac0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
munmap(0xb7fe, 51522)   = 0
open("/dev/urandom", O_RDONLY)  = 3
read(3, "\325\f\20\374\247\"\224\207\377T\355\256\247\205\304e{"..., 32) =
32
close(3)= 0
uname({sys="Linux", node="marsupilami", ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...})
= 0
time(NULL)  = 1112619350
brk(0)  = 0x8056000
brk(0x8077000)  = 0x8077000
open(".", O_RDONLY|O_LARGEFILE) = 3
fchdir(3)   = 0
lstat64(".", {st_mode=S_IFDIR|0755, st_size=96, ...}) = 0
open("/mega/home/han", O_RDONLY|O_LARGEFILE) = 4
fchdir(4)   = 0
close(4)= 0
lstat64(".tmp", {st_mode=S_IFDIR|0755, st_size=573440, ...}) = 0
open(".tmp", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=573440, ...}) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
getdents64(4, /* 3 entries */, 4096)= 80
getdents64(4, /* 0 entries */, 4096)= 0
close(4)= 0
open(".tmp", O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 4
fchdir(4)   = 0
close(4)= 0
lstat64("empty", {st_mode=S_IFDIR|0755, st_size=1, ...}) = 0
open("empty", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=1, ...}) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
getdents64(4, /* 2 entries */, 4096)= 48
getdents64(4, /* 0 entries */, 4096)= 0
close(4)= 0
open("empty", O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 4
fchdir(4)   = 0
close(4)= 0
open("..", O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 4
fchdir(4)   = 0
close(4)= 0
open("empty", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=1, ...}) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
getdents64(4, /* 2 entries */, 4096)= 48
getdents64(4, /* 0 entries */, 4096)= 0
close(4)= 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fec000
write(1, "/mega/home/han/.tmp/empty\n", 26) = 26
fchdir(3)   = 0
open(".", O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 4
fchdir(4)   = 0
close(4)= 0
open(".tmp", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No
such file or directory)
write(2, "find: ", 6)   = 6
write(2, "/mega/home/han/.tmp", 19) = 19
write(2, ": No such file or directory", 27) = 27
write(2, "\n", 1)   = 1
fchdir(3)   = 0
close(1)= 0
munmap(0xb7fec000, 4096)= 0
exit_group(1)   = ?


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinf

[bug #12503] find dir -depth -empty returns not found

[anonymous]

Follow-up Comment #4, bug #12503 (project findutils):

That seems to fix the issue; Thanks!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #12966] (touch .p.; find . -name '*.') problem

[anonymous]

Follow-up Comment #1, bug #12966 (project findutils):

I confirm the bug, but there is a typo in original post.
Correct command is:
 touch .p.; find . -name '*.'
^^^
The dot after find was missing in the original post.
Otherwise, the bug is reproducible.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #12966] (touch .p.; find . -name '*.') problem

[anonymous]

URL:
  

 Summary: (touch .p.; find . -name '*.') problem
 Project: findutils
Submitted by: None
Submitted on: Wed 05/04/2005 at 13:04
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Yakov Lerner
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.20
   Fixed Release: None

___

Details:

I observed that 
   find -name '*.' 
does not report names beginning with '.' and ending with '.'.

For example:
 touch .p.; find -name '*.'
does not report '.p.'
 
Is this intentional, or a bug ?

Yakov Lerner



___

Carbon-Copy List:

CC Address  | Comment
+-
qlerner --AT-- netvision --DOT-- net --DOT-- il | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13041] -i and - shouldn't be exclusive

[anonymous]

URL:
  

 Summary: -i and - shouldn't be exclusive
 Project: findutils
Submitted by: None
Submitted on: Mon 05/09/2005 at 23:59
Category: xargs
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Alejandro Forero Cuervo
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.1.20
   Fixed Release: None

___

Details:

I can't xargs to work as I would expect it when I give it both the ‘-i’ and
‘-l’ args.  Using ‘-i’ specifies ‘-l1’ (as the documentation indicates) and
using ‘-l’ seems to disable the functionality provided by ‘-i’.

This can be evidenced by using the following program:

main ( int argc, char **argv ) { int i; for (i = 0; i < argc; i ++) {
printf("Arg %d: [%s]\n", i, argv[i]); } }

When I build it and run it from xargs, I get the following:

> echo -e 'a\nb\nc' | xargs -l10 -i ./test {}
Arg 0: [./test]
Arg 1: [a]
Arg 0: [./test]
Arg 1: [b]
Arg 0: [./test]
Arg 1: [c]
> echo -e 'a\nb\nc' | xargs -i -l10 ./test {}
Arg 0: [./test]
Arg 1: [{}]
Arg 2: [a]
Arg 3: [b]
Arg 4: [c]
> 

I was expecting to be able to combine ‘-i’ and ‘-l’ to get:

Arg 0: [./test]
Arg 1: [a]
Arg 2: [b]
Arg 3: [c]

I don't see anything in the semantics of ‘-i’ and ‘-l’ that makes them
exclude each other.  Of course, in ‘-i’, the replace string (‘{}’) would get
replaced with as many tokens from the input as permitted.



___

Carbon-Copy List:

CC Address  | Comment
+-
bachue --AT-- bachue --DOT-- com| Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13041] -i and - shouldn't be exclusive

[anonymous]

Follow-up Comment #1, bug #13041 (project findutils):

BTW, I am aware that in this case I can just omit the ‘-i’ and the replace
string ‘{}’.  However, in the general case, I want to run “scp {}
[EMAIL PROTECTED]:dir”, without having one separate process for each file (which
requires separate authentication for each file).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #4016] not gettextizing debugging messages

[anonymous]

URL:
  

 Summary: not gettextizing debugging messages
 Project: findutils
Submitted by: None
Submitted on: Sat 05/14/2005 at 13:08
Category: find bugfix
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

Most findutils debugging messages are not gettextized, but some are.  As
normal users will never see these messages, there is no need to translate
them. The patch undoes the unneeded gettextizations.






___

File Attachments:


---
Date: Sat 05/14/2005 at 13:08  Name: findutils--debug-non-gettext.patch 
Size: 3.76KB   By: None
removes gettextization of debugging messages


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13098] find complains that 'paths must precede expression' even when they do

[anonymous]

URL:
  

 Summary: find complains that 'paths must precede expression'
even when they do
 Project: findutils
Submitted by: None
Submitted on: Mon 05/16/2005 at 16:46
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Jesper Juhl
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

I often run into find complaining about  paths must precede expression  even
if the path(s) to search are indeed listed first.

This might be a user error on my part or a bug in find, I'm not sure, but
this seems wrong :

[EMAIL PROTECTED]:~/download/kernel$ cat /etc/slackware-version
Slackware 10.1.0
[EMAIL PROTECTED]:~/download/kernel$ uname -a
Linux dragon 2.6.12-rc4-mm2 #2 Mon May 16 18:14:13 CEST 2005 i686 unknown
unknown GNU/Linux
[EMAIL PROTECTED]:~/download/kernel$ find --version
GNU find version 4.1.7
[EMAIL PROTECTED]:~/download/kernel$ pwd
/home/juhl/download/kernel
[EMAIL PROTECTED]:~/download/kernel$ ls -l -d patches-2.6.12-rc4*
drwxr-xr-x  2 juhl users 128 2005-05-15 00:52 patches-2.6.12-rc4
drwxr-xr-x  2 juhl users  88 2005-05-15 11:41 patches-2.6.12-rc4-mm1
[EMAIL PROTECTED]:~/download/kernel$ find ./patches-2.6.12-rc4* -name *s*
find: paths must precede expression
Usage: find [path...] [expression]
[EMAIL PROTECTED]:~/download/kernel$

I clearly list the directories to search as the first argument, but still
find complains.





___

Carbon-Copy List:

CC Address  | Comment
+-
jesper --DOT-- juhl --AT-- gmail --DOT-- com | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13212] -newer only examines it's target once at the start

[anonymous]

URL:
  

 Summary: -newer only examines it's target once at the start
 Project: findutils
Submitted by: None
Submitted on: Fri 05/27/2005 at 15:48
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Barry Dobyns
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.1.20
   Fixed Release: None

___

Details:

Actually Release 4.1.7, debian woody.  Debian is always so up-to-date.

-newer only examines the target once

Consider the case where I'm trying to write a script that sets some "target"
file to the latest time of a large number of other files that I'm using find
to traverse.  

I write 

find $START -f -newer $TARGET -exec touch -r "{}" $TARGET ";"

but this only gets the time set to the last file that find examines  that was
-newer than the $TARGET's mod time before the command began to execute.

My work-around for the line above is to execute until it produces no output,
but that's unpleasant, especially if the structure traversed by find is
large.

while true
do
   findout=`find $START -f -newer $TARGET \
-exec touch -r "{}" $TARGET ";" -print | tail -1`
   if [ -z $findout ] ; then break ; fi
done

After some reflection, I believe that the general case of this sort of
problem occur when I'm using -exec.

So, I can understand a line of argument that goes that mine is an exceptional
case, and the current behavior of -newer works well for everyone else in the
world.  Indeed, in the general case where the action of the -exec command
does not modify one of the predicates, only taking the time once is a
reasonable and much-to-be-desired optimization.

Anywho, please consider changing the behavior of -newer such that it performs
the current behavior (check the time once) if and only if there are no -exec
arguments elsewhere in the predicate, and check the time every time if there
are -exec arguments elsewhere.  

Or, (ugh!) add either another time test predicate that checks every time (for
use with find | xargs constructions).




___

Carbon-Copy List:

CC Address  | Comment
+-
barry --AT-- dobyns --DOT-- com | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13363] Typos in find and locate manpages.

[anonymous]

Follow-up Comment #3, bug #13363 (project findutils):

Forwarded comment by A. Costa:

-
On Sat, 11 Jun 2005 07:09:07 +
 
James Youngman <[EMAIL PROTECTED]> wrote:  
 
  
 
> The patch I have actually applied is attached (I don't think 'writable' is a
 
> spelling error).
 
  
 
Did you mean: 
 
  
 
1) I don't think 'writable' is a spelling error   
 
2) I don't think 'writeable' is a spelling error  
 
  
 
Cause you wrote #1, but judging from context probably meant #2.   
 
  
 
In any case "writEable" is an error:  
 
  
 
% echo writable | ispell -l -d american | ispell -l -d british ;echo
$? 
0   # no output, it's correct.
 
% echo writeable | ispell -l -d american | ispell -l -d british ;echo
$?
writeable   # not in dictionaries.
 
0 
 
  
 
And 'find' in 'findutils' v4.2.20-2 has:  
 
  
 
% man find | grep -n writeable
 
981:   Search for files which are writeable by somebody (their
owner, or their  
991:   symbolic form.  These commands all search for files which
are writeable  
993:   writeable by both the owner and group to be matched; either
will do. 
1000:   writeable by both their owner and their group.
 
  
 
Unfortunately it seems the modified patch here:   
 
  
 
   
http://savannah.gnu.org/bugs/download.php?item_id=13363&item_file_id=2591 
 
  
 
Omits my four corrections of 'writEable'.  :'(
 
  
 
If doubt remains, see also this search for 'writable':
 
  
 

[bug #13411] paths in --prunepaths ignored

[anonymous]

URL:
  

 Summary: paths in --prunepaths ignored
 Project: findutils
Submitted by: None
Submitted on: Wed 06/15/2005 at 15:39
Category: updatedb
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.20
   Fixed Release: None

___

Details:

i'm using findutils 4.2.20
i launched
updatedb --prunepaths='/2burn/ /data/ /home/ /mnt /tmp /proc'
but when it was finished, locate $something returned a result in /2burn , so i
presume the paths specified were NOT ignored.
i'm a totally stupid or i just found a huge bug ?




___

Carbon-Copy List:

CC Address  | Comment
+-
tazdev --AT-- punkass --DOT-- com   | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13381] infinite loop with -follow.

[anonymous]

Follow-up Comment #3, bug #13381 (project findutils):

Followup - this isn't a denial of updatedb service because updatedb  does not
use -follow or -L.  However, the problem is significant from a security
perspective in other contexts.

Once again, -L should not be used in security-sensitive environments in any
case.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13495] repetition operator syntax changed in 4.2.21

[anonymous]

Follow-up Comment #2, bug #13495 (project findutils):

I like the patch, but would prefer to switch back to RE_SYNTAX_EMACS as
default, which is *afaict* what find up to 4.2.20 used.

I've thought a little bit about this and have realized that breaking backwards
compability could be _very_ painful. (Breaking lots of scripts in non-obvious
ways, e.g  http://bugs.debian.org/315136)

thanks, cu andreas

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #12491] updatedb broken with solaris su

[anonymous]

Follow-up Comment #4, bug #12491 (project findutils):

Sorry for the massively late response. It seems the latet release (4.2.23)
works fine. Many thanks,

Tim Bishop.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13650] find -exec rm -i {} ; broken since 4.2.12

[anonymous]

Follow-up Comment #6, bug #13650 (project findutils):

Hello,
sorry my incoherent mail.

I was actually thinking about (the useless example)

find ... -ok rm -i {} \;

which I'd expect to ask twice: first find asks, and if that succeeded would
pass on stdin/out to rm which ask again.
cu andreas 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13650] find -exec rm -i {} ; broken since 4.2.12

[anonymous]

Follow-up Comment #8, bug #13650 (project findutils):

Jay wrote:
> I understand but that is not how -ok works

Yes I realized that. :-) Is it going to change or is it to difficult? (I am
sure somebody could come up with a sensible usage of -ok )

If changing is out of question (for whatever reason, be it difficult or you
thinking "stupid idea") could you apply attached patch to the documentation?

   thanks, cu andreas
___

Additional Item Attachment:

File name: patchdocs.diff Size:1 KB
document stdin redirection from /dev/null for find -ok(dir)


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13774] Why is updatedb prefering /var/tmp over /tmp for temporary files?

[anonymous]

URL:
  

 Summary: Why is updatedb prefering /var/tmp over /tmp for
temporary files?
 Project: findutils
Submitted by: None
Submitted on: Tue 07/12/05 at 13:05
Category: updatedb
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Arthur Korn
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

This was originally reported by Arthur Korn in http://bugs.debian.org/317815

updatedb by default uses /var/tmp for temporary files.

| We had a problem today on one system where /var would be full every
| night. We figured out that /var/tmp/ was full with hundreds of megabytes
| of files with names like 'sortXb87kd'. Some inspection led me to |
assumption that those are buffer files from sort, which it places | in TMPDIR,
which is set to /var/tmp/ here:

Afaict from reading FHS /var/tmp should only be used instead of /tmp if the
temporary files must not be deleted on reboot. I fail to see how this applies
to updatedb.
 thanks, cu andreas
PS: Sorry, I have not taken my savannah pasword with me.



___

Carbon-Copy List:

CC Address  | Comment
+-
317815-submitter --AT-- bugs --DOT-- debian --DOT-- org | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13774] Why is updatedb prefering /var/tmp over /tmp for temporary files?

[anonymous]

Follow-up Comment #2, bug #13774 (project findutils):

Jay wrote:
> If you want sort to use a different subdirectory I suggest you
> set TMPDIR in /etc/updatedb.conf. I will modify updatedb itself
> not to override TMPDIR if it is already set.

There is no change is necessary, this is already supported
  cu andreas

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13774] Why is updatedb prefering /var/tmp over /tmp for temporary files?

[anonymous]

Follow-up Comment #3, bug #13774 (project findutils):

Ok, I see the wisdom in this. Maybe this wisdom could be integrated into the
FHS as well.

The combination of millions of hardlinks with long names created by
storebackup and a not _that_ large /var/ partition where numerous other tasks
where working in led to the problems.

Resolved here by setting TMPDIR to /tmp/ and adding the backups to PRUNEPATH
(storebackup has it's own find tool which works on the filelists which it
maintains anyway).

I consider this issue closed, thanks.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13774] Why is updatedb prefering /var/tmp over /tmp for temporary files?

[anonymous]

Follow-up Comment #4, bug #13774 (project findutils):

> Therefore it's especially silly to use /tmp for scratch files
> on systems where this is actually stored in VM (e.g.
> Solaris). There have also been bug reports in the past caused
> by people running out of space in /tmp (or /). Some systems
> have a relatively vanilla root filesystem but vast numbers of
> files in other filsystems.
>
> In short, /var/tmp is traditionally bigger and that can
> sometimes make the difference between working and not
> working.

You are dictating policy here through updatedb though. This 
should be up to the sysadmin. If the sysadmin wants to put /tmp 
into VM that's up to him. And if he makes /tmp to small that's up to him as
well. It's the sysadmin who need to make reasonable decisions.

The updatedb behaveour however goes against the letter of the FHS:
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE
I'm not enough of a FHS expert to tell if it actually violates the standard.

Tomas Pospisek


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13815] Manpage fixes

[anonymous]

URL:
  

 Summary: Manpage fixes
 Project: findutils
Submitted by: None
Submitted on: Fri 07/15/05 at 12:01
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

Hello,
attached you'll find some fixes for find.1, courtesy by Greg Wooledge in
http://bugs.debian.org/318417
  thanks, cu andreas



___

Carbon-Copy List:

CC Address  | Comment
+-
318417-submitter --AT-- bugs --DOT-- debian --DOT-- org | Originator Email



___

File Attachments:


---
Date: Fri 07/15/05 at 12:01  Name: find.318417.patch  Size: 1.68KB   By: None
manpage corrections


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13880] find fails to descend into directories on HSFS filesystems on Solaris 9

[anonymous]

URL:
  

 Summary: find fails to descend into directories on HSFS
filesystems on Solaris 9
 Project: findutils
Submitted by: None
Submitted on: Thu 07/21/2005 at 14:52
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Bill Cole
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.23
   Fixed Release: None

___

Details:

This problem is reproducible with GNU find from the Sunfreeware package of
6/23/2002 (claims to be version 4.1) from the Sun Solaris 9 software companion
CD (claims to be version 4.1.20 of 2/6/2004) and version 4.2.23 freshly built
today. 

The following example shows what I get when looking for every file on a 2.8GB
filesystem which in fact contains tens of thousands of files:

[EMAIL PROTECTED]:findutils-4.2.23# truss find/find /mnt/solaris10/s0 -ls
2>trussout
 936962 dr-xr-xr-x   2 root sys  2048 Jan 23 05:24
/mnt/solaris10/s0
 937031 -r--r--r--   1 root root   93 Jan  6  2005
/mnt/solaris10/s0/.cdtoc
27419522 drwxr-xr-x   5 root other2048 Jan 23 05:24
/mnt/solaris10/s0/.install
 937100 lrwxrwxrwx   1 root other  33 Jan 23 05:22
/mnt/solaris10/s0/.install_config -> ./Solaris_10/Misc/.install_config
 937161 -r--r--r--   1 root root  462 Jan  6  2005
/mnt/solaris10/s0/.slicemapfile
 937201 -r--r--r--   1 root root   21 Jan  6  2005
/mnt/solaris10/s0/.volume.inf
 937241 -r--r--r--   1 root other  23 Jan 22 22:21
/mnt/solaris10/s0/.volume.inf.2
 937281 -r--r--r--   1 root other  23 Jan 22 22:21
/mnt/solaris10/s0/.volume.inf.3
 937321 -r--r--r--   1 root other  23 Jan 22 22:22
/mnt/solaris10/s0/.volume.inf.4
 937377 -r--r--r--   1 root root 6308 Jan  6  2005
/mnt/solaris10/s0/Copyright
 93740  449 -r--r--r--   1 root root   459760 Jan  6  2005
/mnt/solaris10/s0/JDS-THIRDPARTYLICENSEREADME
 937602 drwxr-xr-x   8 root root 2048 Jan 23 05:24
/mnt/solaris10/s0/Solaris_10
 937491 -rwxr-xr-x   1 root other 257 Jan 22 22:22
/mnt/solaris10/s0/installer
[EMAIL PROTECTED]:findutils-4.2.23#


The truss output from that run is attached. It shows no attempt to chdir into
either of the two directories found  under the starting point. 





___

Carbon-Copy List:

CC Address  | Comment
+-
william --DOT-- cole --AT-- gedas --DOT-- com | Originator Email



___

File Attachments:


---
Date: Thu 07/21/2005 at 14:52  Name: trussout  Size: 6.69KB   By: None
truss output from the example run.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13880] find fails to descend into directories on HSFS filesystems on Solaris 9

[anonymous]

Follow-up Comment #2, bug #13880 (project findutils):

I believe option #1 is the operative one. HSFS is High Sierra/ISO-9660, i.e.
read-only CD-ROM's, DVD's, and ISO images. All of the dozen CD's and images
from multiple sources that I've looked at on Solaris 8 and 9 systems show 2
links for . at the top level of the mounted HSFS filesystem. 




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13982] [whish list] backslash spaces

[anonymous]

Follow-up Comment #1, bug #13982 (project findutils):

I am thinking that this might make a good command line option.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #13982] [whish list] backslash spaces

[anonymous]

URL:
  

 Summary: [whish list] backslash spaces
 Project: findutils
Submitted by: None
Submitted on: Sat 07/30/2005 at 15:37
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Ken Estes
Originator Email: 
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

I often wish to use a combination of find and xargs on a filesystem which has
numerious files with spaces in their names.

If find would preceed each filename space by a backslash then I would be able
to run commands like "find . | args egrep NAME" on my filesystem.








___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14227] translation: german manual misleading/incomplete

[anonymous]

URL:
  

 Summary: translation: german manual misleading/incomplete
 Project: findutils
Submitted by: None
Submitted on: Fr 19.08.2005 um 13:02
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Peter Niederlag
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.22
   Fixed Release: None

___

Details:

lately I have discovered a small problem with the find manual.

trying to get into the details I discovered the '-prune' option of find. It
is missing an important point in the german translation of the manpage. 

--snipp-
-prune wahr, wenn die Option -depth gesetzt ist; sonst falsch
snapp---

As soon as I put my locale to 'C' i understood the '-prune' option.

I also noticed the german translation differs quite a little bit from the
original and a good deal of helpful context info is *not included* :-<

Debian/testing+unstable findutils 4.2.22

Thx,
Peter



___

Carbon-Copy List:

CC Address  | Comment
+-
pn --AT-- kreativwert --PUNKT-- de  | Originator Email




___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14243] Basic regular expressions does not work

[anonymous]

URL:
  

 Summary: Basic regular expressions does not work
 Project: findutils
Submitted by: None
Submitted on: Sun 08/21/05 at 09:29
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Yuri Karaban
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.20
   Fixed Release: None

___

Details:

If I type following command:

find . -printf '%f\n' | grep '.*[0-9]\{3\}.*'

I see matches.

But

find . -regex '.*[0-9]\{3\}.*'

does not work (does not return any result). It seems that bounds (\{ and \})
is not working in find.



___

Carbon-Copy List:

CC Address  | Comment
+-
tech --AT-- askold --DOT-- net  | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14243] Basic regular expressions does not work

[anonymous]

Follow-up Comment #4, bug #14243 (project findutils):

>From regex(7) (linux man pages collection
http://www.win.tue.nl/~aeb/linux/man/)

-[cut]--
   Obsolete  (``basic'')  regular  expressions differ in several
respects.
   `|', `+', and `?' are ordinary characters and there  is  no 
equivalent
   for  their functionality.  The delimiters for bounds are `\{' and
`\}',
   with `{' and `}' by themselves ordinary  characters.
-[cut]--

So I guess \{ \} are part of basic regular expressions?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #4340] Set ${NICE:0} value on "su command" clean environments

[anonymous]

URL:
  

 Summary: Set ${NICE:0} value on "su command" clean
environments
 Project: findutils
Submitted by: None
Submitted on: Wed 08/24/05 at 12:35
Category: updatedb bugfix
Priority: 3 - Low
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

Without it, nice values in updatedb.conf does not afect cron.daily/find
@nice@ command needs to be set somewhere





___

Carbon-Copy List:

CC Address  | Comment
+-
dick --AT-- inf --DOT-- ufsc --DOT-- br | Originator Email



___

File Attachments:


---
Date: Wed 08/24/05 at 12:35  Name: updatedb.diff  Size: 367B   By: None
added @nice@ command and use it with find


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14332] Compilation with CFLAGS+="-DAFS" fails

[anonymous]

URL:
  

 Summary: Compilation with CFLAGS+="-DAFS" fails
 Project: findutils
Submitted by: None
Submitted on: Tue 08/30/05 at 07:15
Category: find
Severity: 3 - Normal
  Item Group: Compilation Failure
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Stefaan
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.23
   Fixed Release: None

___

Details:

Because in find/fstype.c, in the function filesystem_type_uncached, the code
within "#ifdef AFS" uses a variable (path) that's not there anymore.  
Found on 4.2.23 and CVS, last one I checked that was ok is 4.1.20.

if x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gnulib/lib
-I../lib -I../gnulib/lib -I../intl -DLOCALEDIR=\"/usr/share/locale\"  -O2
-pipe -march=opteron -DAFS  -O2 -pipe -march=opteron -DAFS -MT util.o -MD -MP
-MF ".deps/util.Tpo" -c -o util.o util.c; \
then mv -f ".deps/util.Tpo" ".deps/util.Po"; else rm -f ".deps/util.Tpo";
exit 1; fi
fstype.c: In function `filesystem_type_uncached':
fstype.c:208: error: `path' undeclared (first use in this function)
fstype.c:208: error: (Each undeclared identifier is reported only once
fstype.c:208: error: for each function it appears in.)
make[3]: *** [fstype.o] Error 1




___

Carbon-Copy List:

CC Address  | Comment
+-
stefaan --DOT-- deroeck --AT-- gmail --DOT-- com | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #4340] Set ${NICE:0} value on "su command" clean environments

[anonymous]

Follow-up Comment #2, patch #4340 (project findutils):

When cron (in debian) starts the find job (present in /etc/cron.daily/), this
job calls updatedb. Then updatedb calls find in a command via su.

  su $LOCALUSER `select_shell $LOCALUSER` -c \   
 "$find $SEARCHPATHS $FINDOPTIONS etc etc etc

The resulting find only runs with the setted up nice value when this value is
passed in $find explicity. Even when i set cron process to run with a lower
nice value it does not inherit it.
An example:

nice -n 25 su testes mc

As root, It runs mc as user testes, but nice value is kept in 0.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14376] -follow -type l returns no results (when it should)

[anonymous]

URL:
  

 Summary: -follow -type l returns no results (when it should)
 Project: findutils
Submitted by: None
Submitted on: Fri 09/02/05 at 18:14
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Drew Van Zandt
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

mkdir followtest
touch test/realfile
ln -s test/realfile test/linkfile
find . -type l
find . -follow -type l



___

Carbon-Copy List:

CC Address  | Comment
+-
drew --DOT-- vanzandt --AT-- gmail --DOT-- com | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14376] -follow -type l returns no results (when it should)

[anonymous]

Follow-up Comment #1, bug #14376 (project findutils):

FYI: 
# find --version
GNU find version 4.1.20
# uname -a
Linux cam 2.4.27-2-386 #1 Mon May 16 16:47:51 JST 2005 i686 GNU/Linux


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14445] incorrect search depending on location in filesystem.

[anonymous]

URL:
  

 Summary: incorrect search depending on location in
filesystem.
 Project: findutils
Submitted by: None
Submitted on: Tue 09/06/05 at 11:48
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: celf
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.20
   Fixed Release: None

___

Details:

incorrect search:
- not all files can be found;
- depending on location in filesystem.

test case:
-
1.
I have next directory structure:
--snip
[EMAIL PROTECTED] scripts]$ ls -R /home/celf/scripts
/home/celf/scripts:
ba  cc

/home/celf/scripts/ba:
hspc-import-ba.pl  qtest.xml

/home/celf/scripts/cc:
hspc-import-cc.pl  issue  qtest.xml  test1.xml  test2.xml  test.xml 
wtest.xml
--snap

2.
when "I'm standing" in /home/celf directory I have:
--snip
[EMAIL PROTECTED] ~]$ pwd
/home/celf
[EMAIL PROTECTED] ~]$ find /home/celf/scripts/ -name *import*
/home/celf/scripts/ba/hspc-import-ba.pl
/home/celf/scripts/cc/hspc-import-cc.pl
--snap

3. when "I'm standing" in /home/celf directory I have:
--snip
[EMAIL PROTECTED] cc]$ pwd
/home/celf/scripts/cc
[EMAIL PROTECTED] cc]$ find /home/celf/scripts/ -name *import*
/home/celf/scripts/cc/hspc-import-cc.pl
--snap

4.
in short second file wasn't found.
-
 



___

Carbon-Copy List:

CC Address  | Comment
+-
asudakov --AT-- sw-soft --DOT-- com | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14459] xargs --show-limits is undocumented

[anonymous]

URL:
  

 Summary: xargs --show-limits is undocumented
 Project: findutils
Submitted by: None
Submitted on: Wed 09/07/05 at 14:39
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Eric Blake
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.25
   Fixed Release: None

___

Details:

When debugging a recent xargs failure on cygwin, caused by a bug in cygwin's
sysconf(_SC_ARG_MAX), I found in the source code that xargs supports
--show-limits, and it turned out to be very useful in diagnosing the problem.
 This option is not documented anywhere, in xargs --help, the man page, or the
info docs.  Also, the source code builds the --show-limits longopt as mapping
to 'S', but does not accept a short opt -S.

For the remainder of this bug report, you can feel free to ignore my
requests, so long as the documentation accurately reflects the actual
behavior (as long as it is undocumented, the behavior can be considered a
bug, but if it is well documented, then I wouldn't be confused in the first
place):
I thought it was rather confusing that --show-limits still insisted on
reading stdin.  I had to execute 'echo | xargs --show-limits' for a
non-blocking printout of the current limits.  I think it might be more
intuitive if --show-limits printed the limits, then quit without doing any
further action (thinking of --show-limits as a form of --help, but correctly
taking into account the affects of -s or other options).  On the other hand,
the limit information could also usefully be printed during --verbose, where
--verbose does imply continuing with execution by reading stdin.




___

Carbon-Copy List:

CC Address  | Comment
+-
ebb9 --AT-- byu --DOT-- net | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14550] xargs --help breaks with over-large environ

[anonymous]

URL:
  

 Summary: xargs --help breaks with over-large environ
 Project: findutils
Submitted by: None
Submitted on: Fri 09/16/05 at 16:19
Category: xargs
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Eric Blake
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.25
   Fixed Release: None

___

Details:

Background: A recent cygwin bug report exposed a flaw in some Windows
versions - Windows does not document a maximum environment size, only that
individual environment variables must not exceed 32k; meanwhile the command
line is in independent memory from environ and is capped at 32k.  This does
not map very well to cygwin and the idea of ARG_MAX.  As a result, it is
possible to have an environment that exceeds 32k, but which is still seen by
the child process.  For an example:
$ foo=`perl -e 'print "a"x31000'`
$ export foo
$ /bin/env | wc -c
34664

Bug: xargs ALWAYS tries to calculate its buffer range, prior to parsing argv.
 As a result, when the environment leads to an impossible situation (such as
cygwin having a larger environment than the useful 32k ARG_MAX), --help no
longer works:
$ xargs --help
xargs: environment is too large for exec
$ xargs --version
xargs: environment is too large for exec

Instead, xargs should parse argv FIRST, because --help and --version should
not fail (since xargs does not have to exec any subprocess).




___

Carbon-Copy List:

CC Address  | Comment
+-
ebb9 --AT-- byu --DOT-- net | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14587] -L does not default to -L1 and results in error

[anonymous]

URL:
  

 Summary: -L does not default to -L1 and results in error
 Project: findutils
Submitted by: None
Submitted on: Mon 09/19/05 at 18:25
Category: xargs
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Jason Pyeron
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.11
   Fixed Release: None

___

Details:



from man xargs:

 --max-lines[=max-lines], -L[max-lines]
 Use  at  most max-lines nonblank input lines per command line; max-lines
defaults to 1 if omitted.
 Trailing blanks cause an input line to be logically continued on the
next input line.  Implies -x.




[EMAIL PROTECTED] rpms.pdinc.us]$ find | perl -ne 'm/(.+)\/.+\.rpm$/ and
print $1, "\n";' | sort -u | xargs -L echo
xargs: invalid number for -l option
Usage: xargs [-0prtx] [-e[eof-str]] [-i[replace-str]] [-l[max-lines]]
   [-n max-args] [-s max-chars] [-P max-procs] [--null]
[--eof[=eof-str]]
   [--replace[=replace-str]] [--max-lines[=max-lines]] [--interactive]
   [--max-chars=max-chars] [--verbose] [--exit] [--max-procs=max-procs]
   [--max-args=max-args] [--no-run-if-empty] [--arg-file=file]
   [--version] [--help] [command [initial-arguments]]

Report bugs to .
[EMAIL PROTECTED] rpms.pdinc.us]$ find | perl -ne 'm/(.+)\/.+\.rpm$/ and
print $1, "\n";' | sort -u | xargs -l echo
./SRPMS
./foo bar
./i386
[EMAIL PROTECTED] rpms.pdinc.us]$ find | perl -ne 'm/(.+)\/.+\.rpm$/ and
print $1, "\n";' | sort -u | xargs -L1 echo
./SRPMS
./foo bar
./i386
[EMAIL PROTECTED] rpms.pdinc.us]$





___

Carbon-Copy List:

CC Address  | Comment
+-
jpyeron --AT-- pdinc --DOT-- us | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14696] failure of find to search the filetree properly

[anonymous]

URL:
  

 Summary: failure of find  to search the filetree properly
 Project: findutils
Submitted by: None
Submitted on: Mon 10/03/05 at 11:10
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: mimis koltsakis
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.19
   Fixed Release: None

___

Details:

I was disconcerted to get the following (erroneous) result:

 searching files ending in -comm from my home-dir:
[EMAIL PROTECTED]:~> find . -name *.comm | grep learning
./learning/aster/try1/demo001a.comm
./learning/aster/try2/try2.comm
./learning/aster/try3/try3.comm
./learning/aster/forma03a/forma03a.comm
./learning/aster/xxx1.comm
./learning/aster/121/121a.comm
./learning/aster/121/121b.comm
./learning/aster/121/121c.comm
./learning/aster/demo001a/demo001a.comm

 descending into learning/aster causes "find" to fail descending into the
tree (dirs try1, try2, try3 etc - only the file xxx1.comm is located)
[EMAIL PROTECTED]:~> cd learning/aster/
[EMAIL PROTECTED]:~/learning/aster> find . -name *.comm
./xxx1.comm

 my find version:
[EMAIL PROTECTED]:~/learning/aster> find --version
GNU find version 4.2.19

 my linux version (SuSE 9.3):
[EMAIL PROTECTED]:~/learning/aster> uname -a
Linux goldberg 2.6.11.4-20a-default #1 Wed Mar 23 21:52:37 UTC 2005 i686 i686
i386 GNU/Linux







___

Carbon-Copy List:

CC Address  | Comment
+-
mkolts --AT-- civil --DOT-- auth --DOT-- gr | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14802] man page for find has typo in -atime description

[anonymous]

URL:
  

 Summary: man page for find has typo in -atime description
 Project: findutils
Submitted by: None
Submitted on: Mon 10/17/05 at 00:54
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

The man page for find misspells "periods" in the -atime description.

"...how many 24-hour preiods ago the file..."







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14836] man page for find does not indicate correct default regexptype

[anonymous]

URL:
  

 Summary: man page for find does not indicate correct default
regexptype
 Project: findutils
Submitted by: None
Submitted on: Fri 10/21/05 at 07:57
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.25
   Fixed Release: None

___

Details:

There seems to be a descrepency in findutils-4.2.25 between the man page &
the code regarding the default regextype:

find/find.1
206:tests which occur later on the command line.  Currently-implemented
207-types are emacs, posix-awk, posix-basic (this is the default),
208-posix-egrep and posix-extended.

find/find.c
512:  options.regex_options = RE_SYNTAX_EMACS

bug #14243, comment 2 says the documentation was updated, but maybe this was
missed.


cheers ;]



___

Carbon-Copy List:

CC Address  | Comment
+-
michael --AT-- thinknasium --DOT-- org | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14854] symbolic perm broken, but octal is OK

[anonymous]

URL:
  

 Summary: symbolic perm broken, but octal is OK
 Project: findutils
Submitted by: None
Submitted on: Mon 10/24/05 at 23:20
Category: None
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: richard
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.25
   Fixed Release: None

___

Details:

attached file shows exactly the bug.

Note that the bug apparently exists only in the conversion from
symbolic mode to the octal equivalent. Given perm in octal the
correct result is produced.




___

Carbon-Copy List:

CC Address  | Comment
+-
rgollub --AT-- uninet --DOT-- com --DOT-- br | Originator Email



___

File Attachments:


---
Date: Mon 10/24/05 at 23:20  Name: find-bug.log  Size: 732B   By: None
list of commands depicting the error vis-a-vis a working version


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #14556] find.1 manpage still refers to "-perm +mode" instead of "-perm /mode"

[anonymous]

Follow-up Comment #4, bug #14556 (project findutils):

Done; in fact there were some other cases too (in find.1, locate.1 and
xargs.1) which I took care of.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15090] "Invalid" is better than "Illegal"

[anonymous]

Follow-up Comment #3, bug #15090 (project findutils):

Yes, but this is now fixed.  Thanks again.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #4371] Document interaction of -I with other options

[anonymous]

Follow-up Comment #5, patch #4371 (project findutils):

Agency providing outcall service to Miami, Fort Lauderdale and Boca Raton.
Offering on-line portfolios of upscale models. Open 24 hours!

Please visit our web sites:


Elite South Florida Escorts:
http://www.EliteSouthFloridaEscorts.com”>www.EliteSouthFloridaEscorts.com

Elite Miami Escorts:
http://www.EliteMiamiEscorts.com”>www.EliteMiamiEscorts.com

Elite Fort Lauderdale Escorts:
http://www.EliteFortLauderdaleEscorts.com”>www.EliteFortLauderdaleEscorts.com

Elite Boca Raton Escorts:
http://www.EliteBocaRatonEscorts.com”>www.EliteBocaRatonEscorts.com


Your can also enter directly to a specific section of our sites:

http://www.miami-escorts.elitemiamiescorts.com”>Our Ladies
http://www.rates.elitemiamiescorts.com”>Rates
http://www.reservations.elitemiamiescorts.com”>Reservations
http://www.about.elitemiamiescorts.com”>About Us


Our http://www.faq.elitemiamiescorts.com”>FAQ section offers
many articles and discussion about Miami, Fort Lauderdale and Boca Raton
escorts and provides answers to many questions you could have but were afraid
to ask. 

For example:

http://www.agency-vs-independent.faq.elitemiamiescorts.com”>Agency
vs. Independent
http://www.escort-reviews.faq.elitemiamiescorts.com”>Escort
Reviews
http://www.bait-and-switch.faq.elitemiamiescorts.com”>Bait and
Switch Issues
http://www.how-to-get-the-most.faq.elitemiamiescorts.com”> How to
get the most out of the date

Visit our http://www.faq.elitemiamiescorts.com”>FAQ section
for more.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15167] find . -type d output is not in order

[anonymous]

URL:
  

 Summary: find . -type d output is not in order
 Project: findutils
Submitted by: None
Submitted on: Wed 12/07/05 at 19:44
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.27
   Fixed Release: None

___

Details:

I have files located in directories that are sorted by date (-MM-DD) and
when I do a find . -type d they are outputted randomly.

[EMAIL PROTECTED] Photos]$ ls
2005-09-11  2005-09-22  2005-10-03  2005-10-15  2005-10-30  2005-11-14
2005-09-12  2005-09-23  2005-10-05  2005-10-17  2005-10-31  2005-11-18
2005-09-13  2005-09-24  2005-10-06  2005-10-18  2005-11-01  2005-11-19
2005-09-14  2005-09-25  2005-10-07  2005-10-19  2005-11-02  2005-11-24
2005-09-15  2005-09-26  2005-10-08  2005-10-22  2005-11-03  2005-11-25
2005-09-16  2005-09-27  2005-10-09  2005-10-23  2005-11-06  2005-11-27
2005-09-17  2005-09-28  2005-10-10  2005-10-24  2005-11-07  2005-11-30
2005-09-18  2005-09-29  2005-10-11  2005-10-25  2005-11-08  2005-12-01
2005-09-19  2005-09-30  2005-10-12  2005-10-26  2005-11-11  index.html
2005-09-20  2005-10-01  2005-10-13  2005-10-27  2005-11-12  memstick.ind
2005-09-21  2005-10-02  2005-10-14  2005-10-28  2005-11-13  mstk_pro.ind
[EMAIL PROTECTED] Photos]$ find . -type d
.
./2005-11-30
./2005-11-30/thumbs
./2005-11-30/scaled
./2005-09-16
./2005-09-16/thumbs
./2005-09-16/scaled
./2005-09-17
./2005-09-17/thumbs
./2005-09-17/scaled
./2005-10-26
./2005-10-26/thumbs
./2005-10-26/scaled
./2005-11-18
./2005-11-18/thumbs
./2005-11-18/scaled
./2005-10-06
./2005-10-06/thumbs
./2005-10-06/scaled
./2005-10-12
./2005-10-12/thumbs
./2005-10-12/scaled
./2005-09-13
./2005-09-13/thumbs
./2005-09-13/scaled
./2005-10-13
./2005-10-13/thumbs
./2005-10-13/scaled
./2005-11-27
./2005-11-27/thumbs
./2005-11-27/scaled
./2005-11-07
./2005-11-07/thumbs
./2005-11-07/scaled
./2005-11-25
./2005-11-25/thumbs
./2005-11-25/scaled
./2005-11-03
./2005-11-03/thumbs
./2005-11-03/scaled
./2005-09-22
./2005-09-22/thumbs
./2005-09-22/scaled
./2005-10-28
./2005-10-28/thumbs
./2005-10-28/scaled
./2005-10-24
./2005-10-24/thumbs
./2005-10-24/scaled
./2005-11-24
./2005-11-24/thumbs
./2005-11-24/scaled
./2005-10-17
./2005-10-17/thumbs
./2005-10-17/scaled

I can workaround it by piping it to the sort command, but this shouldn't be
needed.



___

Carbon-Copy List:

CC Address  | Comment
+-
dhammis --AT-- hotmail --DOT-- com  | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15211] --show-limits not listed in usage() and man-page

[anonymous]

URL:
  

 Summary: --show-limits not listed in usage() and man-page
 Project: findutils
Submitted by: None
Submitted on: Do 15.12.2005 um 12:43
Category: xargs
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Tobias Stoeckmann
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.27
   Fixed Release: None

___

Details:

The option "--show-limits" has been added to find.texi, but
in xargs.c [usage()] and xargs.1 the entry is missing.

I have copied the section from find.texi into xargs.1 and
added the option to usage, although I am not sure if it is
the right place ...



___

Carbon-Copy List:

CC Address  | Comment
+-
paldium --AT-- eyedacor --PUNKT-- org | Originator Email



___

File Attachments:


---
Date: Do 15.12.2005 um 12:43  Name: xargs.patch  Size: 1,91KB   By: None
Applied patches to xargs (4.2.27)


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15235] Leading directories are misparsed as expressions

[anonymous]

Follow-up Comment #7, bug #15235 (project findutils):

I've fixed the additional problems and applied the documentation parts of
your patch.   I edited the ChangeLog entry slightly before  prepending it.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15360] Erroneous message

[anonymous]

URL:
  

 Summary: Erroneous message
 Project: findutils
Submitted by: None
Submitted on: Tue 01/03/06 at 13:47
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Bill Gradwohl
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.20
   Fixed Release: None

___

Details:

This works as expected:
find . -maxdepth 1 -type d | while read x; do echo $x; done
But this doesn't:
find . -type d -maxdepth 1 | while read x; do echo $x; done
find: warning: you have specified the -maxdepth option after a non-option
argument -type, but options are not positional (-maxdepth affects tests
specified before it as well as those specified after it).  Please specify
options before other arguments.

The actual results are identical, but one blurts out an erroneous message on
stderr.




___

Carbon-Copy List:

CC Address  | Comment
+-
bill --AT-- ycc --DOT-- com | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15360] Erroneous message

[anonymous]

Follow-up Comment #2, bug #15360 (project findutils):

I checked man find and searched for the word "global" because you used that
word in your reply. The word "global" doesn't exist in my version (Fedora
Core 4) of find(1).

After your explanation, I re-read man find and discovered the following:
Except for -follow and -daystart, they always  take  effect, rather than
being processed only when their place in the expression is reached. 
Therefore, for clarity, it  is  best  to place  them at the beginning of the
expression.  A warning is issued if you don’t do this.

Please don't take offense at what I'm about to say, as I'm trying to help.

That first sentence - "Except for ... is reached." - is a bit tortured for an
English speaker. After your explanation that global options exist, I conclude
that the sentence should read as follows:
"Except for -follow and -daystart, they always  take  effect globally, rather
than being positionally processed when their place in the expression is
reached."

The following sentences then make perfect sense, as global options logically
should be specified before other options and tests. Previously, I had no idea
that there were global options and regular options, and was always confused by
the two headings "OPTIONS" in the man page.

With that change, it would also make sense to re-title the section its in to
"GLOBAL OPTIONS" instead of just "OPTIONS" under a sub heading of
"EXPRESSIONS". And if "GLOBAL OPTIONS" should preceed regular "OPTIONS", then
if might be better to change the order they appear in within the man page to
reinforce the concept.

Also, it might help to put up a prototype statement such as:
find [global options] [options] tests actions ...
to again reinforce the concepts.

I now understand that it was a documentation issue I was having a problem
with, but I hope you can also see that the documentation as written is a bit
confusing.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #3775] Reassigned item: reconciling man pages differences

[anonymous]

Follow-up Comment #3, patch #3775 (project findutils):

 dizzy,makable adoptions megavolt.beryllium?byte,chest.nanoinstructions
http://www.openlistings.net/best-poker-rooms-in-vegas.html";> video
poker game free best poker rooms in vegas  video poker game free best
poker rooms in vegas
http://www.openlistings.net/best-poker-rooms-in-vegas.html http://www.openlistings.net/best-poker-rooms-in-vegas.html";>http://www.openlistings.net/best-poker-rooms-in-vegas.html
 asterisks:coroner depositions whimsies http://www.openlistings.net/dead-money-poker.html";> no registration
free online video poker games   no registration free online video poker
games  http://www.openlistings.net/dead-money-poker.html http://www.openlistings.net/dead-money-poker.html";>http://www.openlistings.net/dead-money-poker.html
 lemming hurler:twelves electrophoresis burglarproofed http://www.openlistings.net/linux-based-poker-sites.html";> guide  
guide  http://www.openlistings.net/linux-based-poker-sites.html http://www.openlistings.net/linux-based-poker-sites.html";>http://www.openlistings.net/linux-based-poker-sites.html
 signet!gum http://www.openlistings.net/partypoker-emoticons.html";>
partypoker emoticons texas hold em advisor software   partypoker
emoticons texas hold em advisor software 
http://www.openlistings.net/partypoker-emoticons.html http://www.openlistings.net/partypoker-emoticons.html";>http://www.openlistings.net/partypoker-emoticons.html
 certainties!paleness consumed mammoth ashman http://www.openlistings.net/play-poker-with-others.html";> poker party
play poker with others  poker party play poker with others
http://www.openlistings.net/play-poker-with-others.html http://www.openlistings.net/play-poker-with-others.html";>http://www.openlistings.net/play-poker-with-others.html
 being bedders conversation.levelness http://www.openlistings.net/pocker-table.html";> poker t shirt pocker
table  poker t shirt pocker table
http://www.openlistings.net/pocker-table.html http://www.openlistings.net/pocker-table.html";>http://www.openlistings.net/pocker-table.html
 inheritances celestial imposition:leap deploy http://www.openlistings.net/poker-party-com.html";> wsop tryangle  
wsop tryangle  http://www.openlistings.net/poker-party-com.html http://www.openlistings.net/poker-party-com.html";>http://www.openlistings.net/poker-party-com.html
 intellectuals ranker Luther conspire http://www.openlistings.net/poker-tour-beer.html";> texas hold em in
michigan   texas hold em in michigan 
http://www.openlistings.net/poker-tour-beer.html http://www.openlistings.net/poker-tour-beer.html";>http://www.openlistings.net/poker-tour-beer.html
 Michelin:delineation,http://www.openlistings.net/pot-odds-poker.html";> 7 card stud hilo
strategy   7 card stud hilo strategy 
http://www.openlistings.net/pot-odds-poker.html http://www.openlistings.net/pot-odds-poker.html";>http://www.openlistings.net/pot-odds-poker.html
 disturbs agglomerates http://www.openlistings.net/rona-pocker.html";>
free no limit hold em tournaments   free no limit hold em tournaments 
http://www.openlistings.net/rona-pocker.html http://www.openlistings.net/rona-pocker.html";>http://www.openlistings.net/rona-pocker.html
 preservers typing.minimizers ready http://www.openlistings.net/royal-caribbean-poker-tournaments.html";>
mathematics of texas hold em poker   mathematics of texas hold em poker 
http://www.openlistings.net/royal-caribbean-poker-tournaments.html http://www.openlistings.net/royal-caribbean-poker-tournaments.html";>http://www.openlistings.net/royal-caribbean-poker-tournaments.html
 Orestes amends!forgiving!acuity http://www.openlistings.net/shareware-carribean-stud-poker.html";>
shareware carribean stud poker free play texas hold um for mac  
shareware carribean stud poker free play texas hold um for mac 
http://www.openlistings.net/shareware-carribean-stud-poker.html http://www.openlistings.net/shareware-carribean-stud-poker.html";>http://www.openlistings.net/shareware-carribean-stud-poker.html
 Carnegie:lacquer elapsing bandaging,femur http://www.openlistings.net/texas-holdem-tournaments.html";> texas
holdem tournaments no download poker online   texas holdem tournaments no
download poker online 
http://www.openlistings.net/texas-holdem-tournaments.html http://www.openlistings.net/texas-holdem-tournaments.html";>http://www.openlistings.net/texas-holdem-tournaments.html
 ... Thanks!!! 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15405] Seg Fault

[anonymous]

URL:
  

 Summary: Seg Fault
 Project: findutils
Submitted by: None
Submitted on: Sun 01/08/06 at 09:14
Category: updatedb
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.23
   Fixed Release: None

___

Details:

/usr/bin/updatedb: line 314: 12275 Segmentation fault  $find $SEARCHPATHS
$FINDOPTIONS \( $prunefs_exp -type d -regex "$PRUNEREGEX" \) -prune -o
$print_option

No wonder "locate" stopped returning results! ;-)




___

Carbon-Copy List:

CC Address  | Comment
+-
dave --AT-- joot --DOT-- com| Originator Email



___

File Attachments:


---
Date: Sun 01/08/06 at 09:14  Name: updatedb  Size: 8.44KB   By: None
Version of updatedb for SUSE 10.0


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #2108] Fixes incorrect globbing

[anonymous]

Follow-up Comment #3, patch #2108 (project findutils):

 subsegment muteness Daugherty amortizing tub acquisitions
Northrup:Bernini chestnut licensed denser!reels http://www.naturaldelights.net
/online-poker-sites-based-in-europe.html"> online poker sites based in europe
cheating in texas holdem   online poker sites based in europe cheating in
texas holdem  http://www.naturaldelights.net
/online-poker-sites-based-in-europe.html http://www.naturaldelights.net
/online-poker-sites-based-in-europe.html">http://www.naturaldelights.net
/online-poker-sites-based-in-europe.html  vanishes,wrongly dopes
satellite!http://www.naturaldelights.net /partypoker-moon-ad.html">
cheating in texas hold em   cheating in texas hold em 
http://www.naturaldelights.net /partypoker-moon-ad.html http://www.naturaldelights.net
/partypoker-moon-ad.html">http://www.naturaldelights.net
/partypoker-moon-ad.html  ... 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15405] Seg Fault

[anonymous]

Follow-up Comment #1, bug #15405 (project findutils):

I'm unable to reproduce this problem.  Are you pasing any options to
updatedb?  

Perhaps you could set 'ulimit -c unlimited' and run updatedb manually, and
tell me where the core file (which would be dumped in / unless you use the
--changecwd option) indicates the crash is occurring.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15405] Seg Fault

[anonymous]

Follow-up Comment #2, bug #15405 (project findutils):

Close this bug. It was an issue with my system. /dev was whacked to the point
that nothing could see inside the directory without core dumping.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #3775] Reassigned item: reconciling man pages differences

[anonymous]

Follow-up Comment #4, patch #3775 (project findutils):

 rush:eigenvector relents reaches,cooper Dortmund:steadfast!coerce
storming Mogadiscio?grouse http://www.birchfieldharriers.org/";>
texas hold em   texas hold em  http://www.birchfieldharriers.org/ http://www.birchfieldharriers.org/";>http://www.birchfieldharriers.org/
 starling.Gerber.plumage expounds,http://party-poker.poker-protection.com/";> party poker poker
terminology   party poker poker terminology 
http://party-poker.poker-protection.com/ http://party-poker.poker-protection.com/";>http://party-poker.poker-protection.com/
 pontific Hom http://online-poker-game.dedicated-poker.com/";> online
poker game bonuscodes party poker   online poker game bonuscodes party
poker  http://online-poker-game.dedicated-poker.com/ http://online-poker-game.dedicated-poker.com/";>http://online-poker-game.dedicated-poker.com/
 stapler dissatisfactions:http://play-texas-holdem.birchfieldharriers.org/";> play texas holdem
  play texas holdem  http://play-texas-holdem.birchfieldharriers.org/ http://play-texas-holdem.birchfieldharriers.org/";>http://play-texas-holdem.birchfieldharriers.org/
 here abolitionists Annalist islander precomputing http://hold-em-poker.affordableantiques.net/";> hold em poker   hold
em poker  http://hold-em-poker.affordableantiques.net/ http://hold-em-poker.affordableantiques.net/";>http://hold-em-poker.affordableantiques.net/
 previously musty http://party-poker-com.poker-protection.com/";>
party poker com bonus code poker room   party poker com bonus code poker
room  http://party-poker-com.poker-protection.com/ http://party-poker-com.poker-protection.com/";>http://party-poker-com.poker-protection.com/
 Dunedin setters maintenances reproducer!retainment http://pokerroom-com.poker-scan.com/";> pokerroom com   pokerroom
com  http://pokerroom-com.poker-scan.com/ http://pokerroom-com.poker-scan.com/";>http://pokerroom-com.poker-scan.com/
 bald glamorous disgraced http://play-texas-holdem.dedicated-poker.com/";> play texas holdem poker
images   play texas holdem poker images 
http://play-texas-holdem.dedicated-poker.com/ http://play-texas-holdem.dedicated-poker.com/";>http://play-texas-holdem.dedicated-poker.com/
 backhand?blackjack whittling equalize http://professional-poker.poker-protection.com/";> professional poker
five card stud poker   professional poker five card stud poker 
http://professional-poker.poker-protection.com/ http://professional-poker.poker-protection.com/";>http://professional-poker.poker-protection.com/
 skunks sees http://3-card-poker.birchfieldharriers.org/";> 3 card
poker poker room promotional code   3 card poker poker room promotional
code  http://3-card-poker.birchfieldharriers.org/ http://3-card-poker.birchfieldharriers.org/";>http://3-card-poker.birchfieldharriers.org/
 roared  

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15471] Wish: configurable output separator

[anonymous]

URL:
  

 Summary: Wish: configurable output separator
 Project: findutils
Submitted by: None
Submitted on: Wed 01/18/06 at 11:08
Category: xargs
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Alex
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

Hello developers,

I need xargs to provide the arguments as a series of comma separated items.
Could the output separator be made configurable?

Alex.



___

Carbon-Copy List:

CC Address  | Comment
+-
gaaf --AT-- gmx --DOT-- net | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #3775] Reassigned item: reconciling man pages differences

[anonymous]

Follow-up Comment #5, patch #3775 (project findutils):

 codfish rained Hieronymus twenty inquiries,toll propagandist combatant
http://www.poker-scan.com/";> poker how to play online poker 
poker how to play online poker http://www.poker-scan.com/ http://www.poker-scan.com/";>http://www.poker-scan.com/  shakiness
iron marvelled chastise http://online-poker.poker-scan.com/";>
shorthand poker strategy online poker  shorthand poker strategy online
poker http://online-poker.poker-scan.com/ http://online-poker.poker-scan.com/";>http://online-poker.poker-scan.com/
 gushes:Heine protocol stench northeaster http://texas-hold-em.birchfieldharriers.org/";> texas hold em  
texas hold em  http://texas-hold-em.birchfieldharriers.org/ http://texas-hold-em.birchfieldharriers.org/";>http://texas-hold-em.birchfieldharriers.org/
 courtier slug,assignee?ire!Christy http://tops-poker.dedicated-poker.com/";> card game poker rules tops
poker  card game poker rules tops poker
http://tops-poker.dedicated-poker.com/ http://tops-poker.dedicated-poker.com/";>http://tops-poker.dedicated-poker.com/
 burglar connotative exertion?indescribable.http://world-series-of-poker.poker-scan.com/";> world series of poker
  world series of poker  http://world-series-of-poker.poker-scan.com/ http://world-series-of-poker.poker-scan.com/";>http://world-series-of-poker.poker-scan.com/
 partly pimple airbags multidimensional http://play-texas-holdem.birchfieldharriers.org/";> texas poker strategy
play texas holdem  texas poker strategy play texas holdem
http://play-texas-holdem.birchfieldharriers.org/ http://play-texas-holdem.birchfieldharriers.org/";>http://play-texas-holdem.birchfieldharriers.org/
 chit continuation leaping Khartoum doles http://hold-em.poker-protection.com/";> no limit holdem tip hold em 
no limit holdem tip hold em http://hold-em.poker-protection.com/ http://hold-em.poker-protection.com/";>http://hold-em.poker-protection.com/
 carts values panthers:http://poker-websites.dedicated-poker.com/";>
poker websites bonus pacific poker   poker websites bonus pacific poker 
http://poker-websites.dedicated-poker.com/ http://poker-websites.dedicated-poker.com/";>http://poker-websites.dedicated-poker.com/
 bluntly!blankest halfhearted?adducible http://poker-play.poker-protection.com/";> poker play review poker
online   poker play review poker online 
http://poker-play.poker-protection.com/ http://poker-play.poker-protection.com/";>http://poker-play.poker-protection.com/
 fermentations macintosh wheat traded http://playing-poker.dedicated-poker.com/";> playing poker   playing
poker  http://playing-poker.dedicated-poker.com/ http://playing-poker.dedicated-poker.com/";>http://playing-poker.dedicated-poker.com/
 ... 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #4371] Document interaction of -I with other options

[anonymous]

Follow-up Comment #6, patch #4371 (project findutils):

Upscale escort service agency featuring portfolios of elite models. Providing
outcall service to Miami, Fort Lauderdale and Boca Raton. Full Service!

Please visit our web site:
http://www.EliteMiamiEscorts.com

Our Ladies:
http://www.miami-escorts.elitemiamiescorts.com

Anastasia:
http://www.anastasia.elitemiamiescorts.com

Anita:
http://www.anita.elitemiamiescorts.com

Bella:
http://www.bella.elitemiamiescorts.com 

Britney:
http://www.britney.elitemiamiescorts.com 

Celine:
http://www.celine.elitemiamiescorts.com

Diana:
http://www.diana.elitemiamiescorts.com

Francesca:
http://www.francesca.elitemiamiescorts.com

Isabelle:
http://www.isabelle.elitemiamiescorts.com

Irene:
http://www.irene.elitemiamiescorts.com

Lana:
http://www.lana.elitemiamiescorts.com

Nadine:
http://www.nadine.elitemiamiescorts.com

Natasha:
http://www.natasha.elitemiamiescorts.com 

Nina:
http://www.nina.elitemiamiescorts.com

Rebecca:
http://www.rebecca.elitemiamiescorts.com

Regina:
http://www.regina.elitemiamiescorts.com

Sabrina:
http://www.sabrina.elitemiamiescorts.com

Victoria:
http://www.victoria.elitemiamiescorts.com


Our web site also has the following sections:

Rates:
http://www.rates.elitemiamiescorts.com

Reservations:
http://www.reservations.elitemiamiescorts.com

FAQ:
http://www.faq.elitemiamiescorts.com

Employment:
http://www.employment.elitemiamiescorts.com

Links:
http://www.links.elitemiamiescorts.com

About Us:
http://www.about.elitemiamiescorts.com


In addition to Elite Miami Escorts our agency offers:

Elite Fort Lauderdale Escorts:
http://www.EliteFortLauderdaleEscorts.com

Elite Boca Raton Escorts:
http://www.EliteBocaRatonEscorts.com

Elite South Florida Escorts
http://www.EliteSouthFloridaEscorts.com


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #3775] Reassigned item: reconciling man pages differences

[anonymous]

Follow-up Comment #6, patch #3775 (project findutils):

Thank you!
http://www.dorank.com/improvepr/ improve
pagerank default. http://www.dorank.com ">PageRank 11: do
rank, google pagerank algorithm, testing of system. Also
[url]http://www.dorank.com/linksale/[/url] and
[link=http://www.dorank.com]google rank 20[/link] from pagerank .
___

Additional Item Attachment:

File name:Size:0 KB
http://www.yahoo.com\'>Thank you!
http://www.dorank.com/improvepr/ http://www.dorank.com\'>improve
pagerank default. http://www.dorank.com \">PageRank 11: do
rank, google pagerank algorithm, testing of system. Also
[url]http://www.dorank.com/linksale/[/url] and
[link=http://www.dorank.com]google rank 20[/link] from pagerank .


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #2108] Fixes incorrect globbing

[anonymous]

Follow-up Comment #4, patch #2108 (project findutils):

Thank you!
http://www.dorank.com/improvepr/ improve
pagerank default. http://www.dorank.com ">PageRank 11: do
rank, google pagerank algorithm, testing of system. Also
[url]http://www.dorank.com/linksale/[/url] and
[link=http://www.dorank.com]google rank 20[/link] from pagerank .
___

Additional Item Attachment:

File name:Size:0 KB
http://www.yahoo.com\'>Thank you!
http://www.dorank.com/improvepr/ http://www.dorank.com\'>improve
pagerank default. http://www.dorank.com \">PageRank 11: do
rank, google pagerank algorithm, testing of system. Also
[url]http://www.dorank.com/linksale/[/url] and
[link=http://www.dorank.com]google rank 20[/link] from pagerank .


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15587] static linking to glibc 2.3.6 fails

[anonymous]

URL:
  

 Summary: static linking to glibc 2.3.6 fails
 Project: findutils
Submitted by: None
Submitted on: Tue 01/31/06 at 08:55
Category: None
Severity: 3 - Normal
  Item Group: Compilation Failure
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: blindcoder
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.24
   Fixed Release: None

___

Details:

When trying to link findutils 4.2.24 statically to glibc 2.3.6 the following
error occurs:
i386-unknown-linux-gnu-gcc-34  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64   -o find  find.o fstype.o parser.o pred.o tree.o
util.o version.o ../lib/libfind.a ../gnulib/lib/libgnulib.a
pred.o: In function `pred_nogroup':pred.c:(.text+0x7b9): warning: Using
'getgrgid' in statically linked applications requires at runtime the shared
libraries from the glibc version used for linking
parser.o: In function `parse_group':parser.c:(.text+0x355): warning: Using
'getgrnam' in statically linked applications requires at runtime the shared
libraries from the glibc version used for linking
:parser.c:(.text+0x35c): warning: Using 'endgrent' in statically linked
applications requires at runtime the shared libraries from the glibc version
used for linking
parser.o: In function `parse_user':parser.c:(.text+0xc85): warning: Using
'getpwnam' in statically linked applications requires at runtime the shared
libraries from the glibc version used for linking
pred.o: In function `pred_nouser':pred.c:(.text+0x7d2): warning: Using
'getpwuid' in statically linked applications requires at runtime the shared
libraries from the glibc version used for linking
parser.o: In function `parse_user':parser.c:(.text+0xc8c): warning: Using
'endpwent' in statically linked applications requires at runtime the shared
libraries from the glibc version used for linking
/usr/src/lvp_0.5.2-dev/build/generic-TRUNK-x86-lvp/ROCK/tools.cross/i386-unknown-linux-gnu/lib/libc.a(regex.o):(.rodata+0x0):
multiple definition of `__re_error_msgid_idx'
../gnulib/lib/libgnulib.a(regex.o):(.rodata+0x0): first defined here
/usr/src/lvp_0.5.2-dev/build/generic-TRUNK-x86-lvp/ROCK/tools.cross/i386-unknown-linux-gnu/lib/libc.a(regex.o):(.rodata+0x60):
multiple definition of `__re_error_msgid'
../gnulib/lib/libgnulib.a(regex.o):(.rodata+0x60): first defined here
collect2: ld returned 1 exit status
make[3]: *** [find] Error 1
make[3]: Leaving directory
`/usr/src/lvp_0.5.2-dev/src.findutils.1138697359.24411.3717604258/findutils-4.2.24/find'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/usr/src/lvp_0.5.2-dev/src.findutils.1138697359.24411.3717604258/findutils-4.2.24/find'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/usr/src/lvp_0.5.2-dev/src.findutils.1138697359.24411.3717604258/findutils-4.2.24'
make: *** [all] Error 2

I 'fixed' it with the attached patch.



___

Carbon-Copy List:

CC Address  | Comment
+-
blindcoder --AT-- scavenger --DOT-- homeip --DOT-- net | Originator Email



___

File Attachments:


---
Date: Tue 01/31/06 at 08:55  Name: findutils_4224_glibc236_static.patch 
Size: 482B   By: None
patch


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15800] "Hard link count is wrong" reports wrong directory

[anonymous]

URL:
  

 Summary: "Hard link count is wrong" reports wrong directory
 Project: findutils
Submitted by: None
Submitted on: Sun 02/19/06 at 09:20
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Miloslav Trmac
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.27
   Fixed Release: None

___

Details:

With a filesystem with st_nlink == 2 and two subdirectories mounted
at /selinux, find reports that the hard link is wrong on "/"
if invoked as "find / ...".

The attached patch fixes that.



___

Carbon-Copy List:

CC Address  | Comment
+-
mitr --AT-- redhat --DOT-- com  | Originator Email



___

File Attachments:


---
Date: Sun 02/19/06 at 09:20  Name: findutils-4.2.27-linkcount.patch  Size:
664B   By: None
Use the correct file name for the hard link count warning


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #16269] The manual gives an incorrect example

[anonymous]

URL:
  

 Summary: The manual gives an incorrect example
 Project: findutils
Submitted by: None
Submitted on: Wednesday 04/05/06 at 07:35 UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: None
   Fixed Release: None

___

Details:

The manuals states:
NON-BUGS
   $ find . -name *.c -print
   find: paths must precede expression
   Usage: find [-H] [-L] [-P] [path...] [expression]

   This happens because *.c has been expanded by the  shell  resulting 
in
   find actually receiving a command line like this:

   find . -name bigram.c code.c frcode.c locate.c -print

   That  command  is of course not going to work.  Instead of doing
things
   this way, you should enclose the pattern in quotes:
   $ find . -name ´*.c´ -print

-

Those are the wrong sort of quotes.  You want 
find . -name '*.c' -print

instead.






___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #16269] The manual gives an incorrect example

[anonymous]

Follow-up Comment #1, bug #16269 (project findutils):

By 'manual' I mean the man page you get when you type

man find.

Laura ([EMAIL PROTECTED])

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15800] "Hard link count is wrong" reports wrong directory

[anonymous]

Follow-up Comment #2, bug #15800 (project findutils):

SO what is a guy to do with this attached file?


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #16378] find aborts on file with mode 0000

[anonymous]

URL:
  

 Summary: find aborts on file with mode 
 Project: findutils
Submitted by: None
Submitted on: Wednesday 04/19/06 at 04:28 UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Davyd Madeley
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.27
   Fixed Release: None

___

Details:

`find` will abort if it comes across a file with mode  giving an
assertion error:
find: pred.c:1329: pred_type: Assertion `state.type != 0' failed.

It gives no indication of what file it was up to at the time. Ideally it
would print a warning to stderr and keep on going, rather than abort. This
happens when using the type predicate.

At the very least a more verbose error would be nice.






___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #16378] find aborts on file with mode 0000

[anonymous]

Follow-up Comment #1, bug #16378 (project findutils):

Additionally, your bug tracker has decided that my email address is invalid.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #16378] find aborts on file with mode 0000

[anonymous]

Follow-up Comment #3, bug #16378 (project findutils):

This was reproducable on Fedora Core 4 and 5, we did not observe it on Redhat
8.

The error would occur with:
find mydir ! -type d
but not with:
find mydir

The file was on an NFS filesystem and was probably corrupt. `stat` informed
us that the mode on the file was . `ls` listed the permissions as
"?--". `fsck` later on picked up the inode as being inconsistant.

Given that find works without the predicate, it seems logical that it should
still work with the predicate. It may also make sense to mention a seemingly
corrupt file via stderr.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[patch #4371] Document interaction of -I with other options

[anonymous]

Follow-up Comment #7, patch #4371 (project findutils):

Miami Dream Girls is the most upscale escort service agency providing 24x7
service and offering the widest selection of the most beautiful, gorgeous,
charming, sophisticated, fabulous and sexy Miami escorts, Fort Lauderdale
escorts and Boca Raton escorts.   

Please call us any time at  305-695-2692

Please visit our web site: 
www.MiamiDreamGirls.com

Miami Dream Escorts: 
www.miamidreamgirls.com/girls.htm

Miami Escorts, Boca Raton Escorts and Fort Lauderdale Escorts Special offers:

www.miamidreamgirls.com/special_offers.htm

Miami Escorts, Boca Raton Escorts and Fort Lauderdale Escorts Rates: 
www.miamidreamgirls.com/reservations.htm

Miami Escorts, Boca Raton Escorts and Fort Lauderdale Escorts Reservations: 
www.miamidreamgirls.com/reservations.htm

Miami Escorts, Boca Raton Escorts and Fort Lauderdale Escorts Employment: 
www.miamidreamgirls.com/employment.htm

About Miami Dream Escorts: 
www.miamidreamgirls.com/index.html

• Why does Miami Dream Girls have the best Miami Escorts, Boca Raton
Escorts and Fort Lauderdale Escorts?
www.miamidreamgirls.com/index.html
  

Miami Dream Girls Escort Agency offers on-line portfolios of the most
beautiful Miami Escorts, Boca Raton Escorts and Fort Lauderdale Escorts:
Ingrid:  www.miamidreamgirls.com/Girls/Ingrid/Ingrid.htm  
Marcela:  www.miamidreamgirls.com/Girls/Marcela/Marcela.htm  
Bella: www.miamidreamgirls.com/Girls/Bella/Bella.htm
Mila: www.miamidreamgirls.com/Girls/Mila/Mila.htm 
Valentina: www.miamidreamgirls.com/Girls/Valentina/Valentina.htm
Angela: www.miamidreamgirls.com/Girls/Angela/Angela.htm
Bridgette: www.miamidreamgirls.com/Girls/Bridgette/Bridgette.htm


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #16605] Delimiter option is wrong

[anonymous]

URL:
  

 Summary: Delimiter option is wrong
 Project: findutils
Submitted by: None
Submitted on: Tuesday 05/16/06 at 20:09 UTC
Category: xargs
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: 4.2.27
   Fixed Release: None

___

Details:

on the man page I read:

--delimiter=delim, -d delim
  Input items are terminated by the specified character. (...)

when I run:

$find /usr/share/java | xargs -d :

this is the output:

/usr/share/java/antlr.debug.jar
/usr/share/java/antlr.jar
/usr/share/java/com-sun-javadoc.jar
/usr/share/java/antlrall.jar
(...)

while the following was expected:

/usr/share/java/antlr.debug.jar:/usr/share/java/antlr.jar:/usr/share/java/com-sun-javadoc.jar:/usr/share/java/antlrall.jar:(...)








___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #16605] Delimiter option is wrong

[anonymous]

Follow-up Comment #1, bug #16605 (project findutils):

You are misinterpreting the documentation.  Try this:
$ echo $PATH | xargs -d:


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #17587] print0 action causes false results to be printed

[anonymous]

URL:
  

 Summary: print0 action causes false results to be printed
 Project: findutils
Submitted by: None
Submitted on: Friday 09/01/2006 at 19:23 UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Saku
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.27
   Fixed Release: None

___

Details:

This was discovered in combination with -size test but after some tests it
proved to be there with other tests as well (-name).

I actually wonder if this is indeed a bug because it is too obvious to have
been ignored or not reported so far...

So the case is that

find . -size 0

finds nothing in the current directory.

find . -print0 -size 0

accepts *everything* as a correct match. As if

find . -print0 

was invoked.

Hopefully I am not reporting something silly here.

Thanks.



___

Carbon-Copy List:

CC Address  | Comment
+-
Available only the item webpage | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #15531] -prune misbehaving?

[anonymous]

Follow-up Comment #4, bug #15531 (project findutils):

Hello,

  I have also hit this bug, with the 4.3.0 version of findutils.
My system is linux gentoo.
The provided patch did indeed solve the problem (thanks by the way).
I spent 6 our tracking the problem down:( (hehe 2 hours spent learning find
syntax:).

Thanks,
Miro


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #11710] 4.2.13 Solaris build failure -- regex.c needs to be compiled

[anonymous]

Follow-up Comment #3, bug #11710 (project findutils):

The same thing happens again with AIX and findutils 4.2.28

cc -qlanglvl=ansi  -g   -o find  find.o fstype.o parser.o pred.o tree.o
util.o version.o ../lib/libfind.a ../gnulib/lib/libgnulib.a
ld: 0711-317 ERROR: Undefined symbol: .re_match
ld: 0711-317 ERROR: Undefined symbol: .re_set_syntax
ld: 0711-317 ERROR: Undefined symbol: .re_compile_pattern
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.

4.2.27 comiles fine.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

[anonymous]

URL:
  

 Summary: Invalid "No such file or directory" error on
filesystem without stable inode numbers
 Project: findutils
Submitted by: None
Submitted on: Thursday 09/28/2006 at 11:24 UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Miklos Szeredi
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.3.0
   Fixed Release: None

___

Details:

fts_safe_changedir() in gnulib/lib/fts.c return ENOENT error if inode number
of a directory changed.

There are several Linux filesystems (including smbfs, fat, and some FUSE
based ones) which cannot provide stable inode numbers for unreferenced files
or directories.

In their cases find may in rare circumstances (if the cached in-core inode is
evicted from the cache) erronously fail to recurse into these directories.

This bug seems to have appeared in 4.3.0.




___

Carbon-Copy List:

CC Address  | Comment
+-
Available only the item webpage | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #17951] find doesn't correctly stat directories

[anonymous]

URL:
  

 Summary: find doesn't correctly stat directories
 Project: findutils
Submitted by: None
Submitted on: Montag 09.10.2006 um 12:02 UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Ronny Peine
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.3.0
   Fixed Release: None

___

Details:

Following find commandline gives me "Permission denieds" for directories
which don't even match the expressions:
find /tmp -maxdepth 1 -mtime -1 -type f -name 'Acro*' -user "$LOGNAME"
-print0

LOGNAME is the user of the invoking command.
find-4.3.0 still seems to touch all the files in /tmp even the expression
Acro* doesn't match.

Given Output:
find: /tmp/kde-root: Permission denied
find: /tmp/.gnome: Permission denied
find: /tmp/.gnome_private: Permission denied

Expected Output:


Previous find versions were working correctly in this case.
The 'oldfind' binary works correctly, too.
For me this seems related to the new 'fts'.

Any advice or idea?



___

Carbon-Copy List:

CC Address  | Comment
+-
Available only the item webpage | Originator Email




___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #17951] find doesn't correctly stat directories

[anonymous]

Follow-up Comment #1, bug #17951 (project findutils):

Ok, i have found out what the problem is in detail:
find ... -maxdepth 0 not only uses lstat64 on the given directory /tmp but
also on all files in /tmp in the first hierarchylevel. oldfind ... -maxdepth
0 only uses lstat64 on /tmp. oldfind shows the same behaviour as find if
-maxdepth is set to 1. So oldfind -maxdepth x corresponds to find -maxdepth
x-1.
In the manpage for find it says:
-maxdepth levels
   Descend  at  most  levels  (a non-negative integer) levels of directories
below the command line arguments. `-maxdepth 0' means only apply the tests
and actions to the command line arguments.

My question now is: Does apply tests and actions to the given command line
include opening the directory and lstat64 all files in this directory?

This changed behaviour led to my first posted problem because find -maxdepth
1 ... wants to open each directory in /tmp to see for a file equal to 'Acro*'
but it should only see in /tmp if 'Acro*' exists, therefor the given
"Permission denied"-messages.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #17861] make of find fails on Solaris 2.8

[anonymous]

Follow-up Comment #1, bug #17861 (project findutils):

exactly same thing on Solaris 10, build of findutils
4.2.28 fails for same reason.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #18175] GPG Signature Does Not Match Key

[anonymous]

URL:
  

 Summary: GPG Signature Does Not Match Key
 Project: findutils
Submitted by: None
Submitted on: Thursday 11/02/2006 at 07:25 UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.2.28
   Fixed Release: None

___

Details:

The GPG signature ftp://ftp.gnu.org/gnu/findutils/findutils-4.2.28.tar.gz.sig
does not match any of the keys for the members on the keyring given at
http://savannah.gnu.org/projects/findutils/



___

Carbon-Copy List:

CC Address  | Comment
+-
Available only the item webpage | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #17951] find doesn't correctly stat directories

[anonymous]

Follow-up Comment #3, bug #17951 (project findutils):

Well, i think after reading the bugreport #17372 that it seems to be related,
maybe possibly the same error. So you can mark it as a duplicate if you want.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #18222] find -printf '%H %P' misbehaves with multiple paths

[anonymous]

URL:
  

 Summary: find -printf '%H %P' misbehaves with multiple paths
 Project: findutils
Submitted by: None
Submitted on: Tuesday 11/07/2006 at 07:22 UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: 4.3.1
   Fixed Release: None

___

Details:

When find is passed multiple paths, it misreports the printf fields %H and
%P. Specifically, it splits the second path using the field length of the
first path.

Example:
623 $ mkdir dir1
624 $ mkdir directory2
625 $ touch dir1/foo
626 $ touch directory2/bar
627 $ find dir1 directory2 -printf '%H %P\n'
dir1 
dir1 foo
dire
dire ctory2/bar

oldfind gives the expected output:
628 $ oldfind dir1 directory2 -printf '%H %P\n'
dir1 
dir1 foo
directory2 
directory2 bar


My find is:
GNU find version 4.3.1
Features enabled: O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS CBO(level=0) 

My uname -a is:
CYGWIN_NT-5.1 frederick 1.5.21(0.156/4/2) 2006-07-30 14:21 i686 Cygwin




___

Carbon-Copy List:

CC Address  | Comment
+-
Available only the item webpage | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #17951] find doesn't correctly stat directories

[anonymous]

Follow-up Comment #5, bug #17951 (project findutils):

Yes it fixes my problem, too. So i think it is correct that this bug has the
same source. Big thanks for your help.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #18222] find -printf '%H %P' misbehaves with multiple paths

[anonymous]

Follow-up Comment #2, bug #18222 (project findutils):

Thank you for fixing this bug so quickly.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #18375] Error messages with some patterns

[anonymous]

URL:
  

 Summary: Error messages with some patterns
 Project: findutils
Submitted by: None
Submitted on: Sunday 11/26/2006 at 01:22 UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Release: None
   Fixed Release: 4.2.27

___

Details:

Finding some patterns ends with an error message:

[EMAIL PROTECTED]:~$ sudo find / -name wol*
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]↵
[EMAIL PROTECTED]:~$ find -v

while others go normally:
[EMAIL PROTECTED]:~$ sudo find / -name gol*
/home/tibor/golden.txt
[EMAIL PROTECTED]:~$

and of course the problem is mainly with patterns I need...

Tibor



___

Carbon-Copy List:

CC Address  | Comment
+-
Available only the item webpage | Originator Email




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils