> "JY" == James Youngman writes:
JY> On Sat, Sep 21, 2013 at 11:46 PM, wrote:
>> Have it your way.
JY> Wow, what did I say to provoke that reaction?
I don't know if it is worth implementing either. I apparently did at one
time but it would take a lot of concentration for me to figure out w
P.S. odd how one is forced to search Google
http://www.google.com/search?q=%22Re%3A+Can%27t+say+%22up+to+and+including%22+with+-newer+without+a+symmetrical+-older%22
for the original message, given the headers I received.
Have it your way. What really bothers me is cpio's saying it won't copy
because an older or same version exists. Why can't it cough up which and
not leave the user the task...
Gentlemen,
man cat says
SEE ALSO
tac(1)
The full documentation for cat is maintained as a Texinfo manual. If
the info and cat programs are properly installed at your site, the com-
mand
info coreutils 'cat invocation'
should give you access to
On man find you had better add some more explanation to
%H Command line argument under which file was found.
%P File's name with the name of the command line argument
under which it was found removed.
else nobody knows what you are talk
> "EB" == Eric Blake writes:
EB> Yes, I think your reading of POSIX shows we have a bug in xargs.
Go get em'! I mean how can anybody use the thing with all that junk
erupting in one's face in the simplest case of -p with no redirection
etc. etc. Thanks!
What good is this?
$ seq 111|xargs -n 5 -p
echo 1 2 3 4 5 ?...
echo 6 7 8 9 10 ?...
echo 11 12 13 14 15 ?...y
echo 16 17 18 19 20 ?...11 12 13 14 15
You need to do the operation first before issuing the next prompt!
It should look like
$ seq 111|xargs -n 5 -p
echo 1 2 3 4 5 ?...
echo 6 7 8 9 10
X-Debbugs-Cc: bug-findutils@gnu.org
Package: findutils
Version: 4.5.9-1
Severity: wishlist
# man oldfind|wc
13309696 78854
# man find|wc
13309696 78854
# man oldfind|grep -ci oldfind
0
# which oldfind|xargs ls -l
-rwxr-xr-x 1 root root 154520 May 8 2010 /usr/bin/oldfind
# which
Regarding: -newerXY reference
Say if X and Y refer to the same file or not.
Give a valid example and explain what it does.
$ for i in w x y; do sleep 4; touch $i; done
$ find ? -newer x
y
$ find ? ! -newer x
w
x
OK, so how does one find just
x
y
?
No easy way, as you have a unsymmetrical -newer without a matching -older.
One must resort to big hassles to work around your unsymmetrical
offering of commands.
You migh
$ w3m -dump http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576772|grep
^Version
Version: 4.5.7-1
findutils:
Installed: 4.5.7-1
Anyway, I have shown %Y is moody and not to be trusted.
I will now step back and hand the baton to others.
So I thought cd'ing to /tmp would help
(cd /tmp
find "${DESTDIR}" -type l -printf '%p %Y\n' | sed -n 's/ [LN]$//p' \
| xargs --verbose -rL1 rm -f
)
however the files got zapped anyway. So it's back to the random %Y
accuracy theory.
Apparently it is affected by CWD:
14:21 ~$ cd -
/tmp
14:21 tmp$ find /tmp -name sleep -printf %Y\\n
f
f
14:21 tmp$ cd -
/home/jidanni
14:21 ~$ find /tmp -name sleep -printf %Y\\n
N
N
14:21 ~$ cd -
/tmp
14:22 tmp$ find /tmp -name sleep -printf %Y\\n
f
f
14:22 tmp$ mount|egrep /home\|/tmp
/dev
X-debbugs-Cc: m...@stro.at, 576...@bugs.debian.org, bug-findutils@gnu.org
Package: findutils
Version: 4.5.7-1
Dear Find Sirs, as you can see on
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576677#130
for the %Y code to function properly, one must give the full path to the
file, not just a high
What's barfy is it turns out the same command sometimes gives different output!
$ mount|grep /tmp #df shows plenty of space too.
tmpfs on /tmp type tmpfs (rw)
14:04 ~$ find /tmp/NOSHUCH -printf %Y\\n
N
14:05 ~$ find /tmp/sleep -printf %Y\\n
f
14:05 ~$ find /tmp -name sleep -printf %Y\\n ###COMPAR
> "JY" == James Youngman writes:
JY> On Wed, Jan 13, 2010 at 11:06 PM, wrote:
>> -readable
>> Matches files which are readable...
>> Also mention "by the current user" I suppose.
JY> Since there is more than one possible interpretation of the "current
JY> user" this clari
Gentlemen, some of these are clearer than man test or
(info "(coreutils) Access permission tests")
bash$ help test|grep you
-r FILETrue if file is readable by you.
-w FILETrue if the file is writable by you.
-x FILETrue if the file is executable by you.
-readable
Matches files which are readable...
Also mention "by the current user" I suppose.
And perhaps mention a way to see if they are readable by the general public...
> "JM" == Jim Meyering writes:
JM> James Youngman wrote:
>> On Sat, Sep 19, 2009 at 4:41 PM, wrote:
EB> Untested, but:
EB> -type d \! -readable -prune
EB> seems like it should do the trick of telling find to not descend into
EB> unreadable directories.
>>>
>>> Well, I hope there can be an e
EB> Untested, but:
EB> -type d \! -readable -prune
EB> seems like it should do the trick of telling find to not descend into
EB> unreadable directories.
Well, I hope there can be an example added to the find man page.
Anyway, in the general case ... there needs to be a way...
$ chmod 0 jidanni.o
>> It seems there is no way to tell find to look before it leaps,
>>
>> $ find /tmp -user $LOGNAME -type f -mtime +1 -exec rm {} \;
EB> Have you looked at using -ok instead of -exec?
It's a total batch job, -ok not OK, OK?
I'm trying to tell find:
do what you need to do, but if you encounter an
It seems there is no way to tell find to look before it leaps,
$ find /tmp -user $LOGNAME -type f -mtime +1 -exec rm {} \;
find: /tmp/mc-jidanni3: Permission denied
$ find /tmp -depth -user $LOGNAME -type d -empty -mtime +1 -exec rmdir {} \;
find: /tmp/mc-jidanni3: Permission denied
Is there any
> Additional Item Attachment, bug #26701 (project findutils):
> File name: test.shSize:0 KB
Great, 0 KB. Scare the user. I would round up.
Mention both your ways
JY> ed $(find -name '*.c' -ok echo {} \; )
JY> xargs -a <(find -name '*.c') -n1 -p ed
and mine.
P.S., today is the first time I ever saw "<(...)", OK, I see it on the
bash man page under Process Substitution.
JY> If you would like to propose an illustrative problem for which
JY> your workaround is the most effective solution, we can probably
JY> include that in the documentation as an example.
OK, please mention something like:
-ok in contrast to -exec, has its stdin redirected for various reasons.
To
OK, but considering
> A workaround to revive stdin on -ok is: -ok true \; -exec
Will you
A. Clamp down stdin on -exec too, for my own good; or
B. Mention the workaround on the man page; or
C. Stop clamping stdin on -ok, as people will just workaround it
anyway, and just say you will read up to a RE
Regarding "-ok": if you want to type y but by mistake you type
anything else, you have to start all over again. Therefore there
should also be a "p" offered: "bring me back to the previous line
and ask me again".
By the way,
-ok command ;
Like -exec but ask the user first (on
On the find man page
-cnewer file
File's status was last changed more recently than file was modi-
fied. If file is a symbolic link and the -H option or the -L
option is in effect, the status-change time of the file it
points
I'm trying to say that find -newer is affected by the same problem as
this thread, for better or worse:
http://lists.gnu.org/archive/html/bug-coreutils/2008-03/msg00252.html
JY> The -newer test, and find generally, deals only with the information
JY> the OS gives it.
Yes, but then a decision is m
Oops, pasted wrong. OK:
$ cd /some_Linux_dir; stat y
Modify: 2008-04-09 11:11:11.0 +0800
$ cp -a y /vfat
$ umount /vfat; mount /vfat
$ stat /vfat/y
Modify: 2008-04-09 11:11:10.0 +0800
Anyway, please try
$ cd some_[V]FAT_directory_of_yours
$ stat *|perl -nwe 'print if /(Access|Modif
find -newer will have the same problem on FAT filesystems as cp -u:
http://lists.gnu.org/archive/html/bug-coreutils/2008-04/msg00027.html
$ touch -d 11:11:11 y
$ stat y
Access: 2008-04-09 11:11:11.0 +0800
$ cp -a y /vfat
$ umount /vfat; mount /vfat
$ stat /vfat/y
Modify: 2008-04-09 11:11:10
OK, then at least two out of the three %'s can still be given.
JY> If you would like to propose some specific replacement text
I am just saying that the man page leaves dead ends for average users.
This is getting beyond my dwindling mental resources... excuse me,
must step out of discussion here.
> "JY" == James Youngman <[EMAIL PROTECTED]> writes:
JY> On Sun, Mar 23, 2008 at 9:29 PM, <[EMAIL PROTECTED]> wrote:
>> `%S'
>> File's sparseness. This is calculated as `(BLOCKSIZE*st_blocks /
>> st_size)'.
>>
>> OK, but then mention the -printf % keys for st_blocks and st_size!
JY> They'r
Please don't say on your man page
Other comments about find(1) and about the findutils package in
general can be sent to the bug-findutils mailing list. To join
the list, send email to [EMAIL PROTECTED]
Do like coreutils and just give the address.
Otherwise you instill doubt as
`%S'
File's sparseness. This is calculated as `(BLOCKSIZE*st_blocks /
st_size)'.
OK, but then mention the -printf % keys for st_blocks and st_size!
36 matches
Mail list logo
