Bob Proulx wrote:
> Then I would use this following technique since it effectively exactly
> answers the question you asked. Try this:
>
> find . -size +1k -exec sh -c 'ls -1sd "$@"' sh {} +
Berny asked me why I chose to do it that way instead of the s
Yuen, Kam-Kuen CIV USARMY DEVCOM SC (USA) wrote:
> But I try the following and has the attached sample output.
>
> find . -size +1k -ls
>
> Q) Where can I find the columns heading? The standard ls command does not
> have the first two columns data.
> Is there a good documentation that I can
Yuen, Kam-Kuen CIV USARMY DEVCOM SC (USA) via Bug reports for the GNU find
utilities wrote:
> I am running the following command and the "ls" command gives error
> message that the file cannot be found. The problem is that the
> filename has spaces as part of the filename.
In addition to everyth
Chun Yip Wong wrote:
> I prefer using find with script in this way: find $dir $pattern.where
> pattern=" -name *.sh ! -name *.txt ... etc."
There is a problem with insufficiently quoted shell file glob meta
characters in that pattern. That's a problem unrelated to find.
> The built findutils ver
Follow-up Comment #2, bug #55095 (project findutils):
This would be counter to the Unix philosophy of small programs that do one
thing well that can be combined together to perform new useful things.
This is just one example of something that is unpredictably needed but can be
created as needed u
James Youngman wrote:
> Bob Proulx wrote:
> > If stdout is a tty then the newline is mapped to '?'. But it isn't
> > mapped if the output is redirected to a pipe or a file. This applies
> > to the printf %p format too.
>
> Yes. This is delib
Undocumented behavior. Here is the test case:
mkdir /tmp/testdir
mkdir /tmp/testdir/"newline
newline"
find /tmp/testdir -print
/tmp/testdir
/tmp/testdir/newline?newline
Note the '?' in the above. No '?' in the below that is redirected.
find /tmp/testdir -print | head
/tmp/testdir
/tmp/testdir
Kevin Buchs wrote:
> I often find myself wanting to use find, but avoid searching any
> subdirectories called .snapshot, which contain our hourly online backups.
> My attempt below seems to fail, for find is trying to access subdirectories
> of .snapshot, for which I have no permission and I get th
James Youngman wrote:
> I understand that "locate -r" works differently between GNU locate on
> the one hand, and both mlocate and slocate on the other. GNU
> locate uses Emacs-dialect regular expressions. Both mlocate and
> slocate use POSIX BREs.
That does seem to be a gratuitous differenc
RB wrote:
> > Would the two of you be able to be able to pull this into a
> > (what-I-wanted-to-achieve, command, explanation-of-how-it-works) form
> > so that we can put it into the Texinfo documenation? (And, length
> > permitting, the manual page).
>
> Never done a Texinfo doc, but no bet
RB wrote:
> > Using the above test case the following seems to work.
> >
> > find srcdir \( -exec test -d {}/CVS \; -o -exec test -d {}/.svn \; -o
> > -exec test -d {}/.git \; \) -print -prune | sort
>
> That works for me as well; I knew I had to be a few sandwiches short!
> It also has the add
RB wrote:
> In short, I'm looking for a clean way to find the shallowest 'CVS',
> '.svn', or what have you in a given directory structure without
> ignoring sibling directories. If a project publishes multiple trees
> (trunk, branch, etc.) with no common VCS parent, it's difficult to
> cleanly cat
James Youngman wrote:
> James Youngman wrote:
> > [EMAIL PROTECTED] wrote:
> > > AFAICS there's no way to have directory names with spaces in the
> > > mentioned paths.
> > >
> > > Shall we define one?
> >
> > I'm generally in favour.
> ...
> Pinging bug-findutils members for any comments
I am
Eric Blake wrote:
> #include
> int main()
> {
> return execl("ls", "Makefile", 0);
> }
Use of 'execl' is a good point. It is not possible to prototype that
function such that an integer zero can be known by a standard compiler
as a pointer and so get automatic conversion into a pointer type.
Since this is not about any particular patch to findutils I have moved
the discussion.
http://lists.gnu.org/archive/html/findutils-patches/2007-06/msg00034.html
Eric Blake-1 wrote:
> But that is bug-prone.
>
> Consider:
>
> printf("%p%d", NULL, 1);
> vs.
> printf("%p%d", 0, 1);
You make a co
James Youngman wrote:
> I tried doing this automatically with
> git-config --add format.headers '"To: [EMAIL PROTECTED]"'
I think there are one too many sets of quotes there.
> ... but that made git-format-patch add the To: header in between the
> start of the Subject: header and its continuation
Update of bug #20245 (project findutils):
Assigned to:None => rwp
Open/Closed:Open => Closed
___
Follow-up Comment #1:
The problem you
James Youngman wrote:
> Eric Blake wrote:
> >Say, do you have your git repository published somewhere? Is it worth
> >getting it added to git.sv.gnu.org/gitweb?
>
> Yes and no. There is a public repo, but it's downstream of CVS.
Being an advocate for git I thought I would mention here that it
Nix wrote:
> btw, I wonder what's up with the interestingly named list
> [EMAIL PROTECTED] It seems to have received a single
> legitimate message at list creation and then become a pure spam
> mine...)
That is pretty funny. The mailing list information for it says:
"Temporary test list for exci
James Youngman wrote:
> Nix wrote:
> > [This is a 3rd resend, since repeated attempts to send this to to
> > bug-findutils@gnu.org have failed; the email vanished without trace;
> > maybe they're stuck in a moderation queue somewhere, but maybe they're
> > lost. Apologies if they turn up after I se
On Mon, 18 Dec 2006 22:05:17 +0900 aforce ma wrote:
> When I try to use the command belows to delete empty
> directories,there always comes error messages,however the empty
> directory has been deleted already,Is this a Bug? or how can I do to
> make the error do not come?
>
> find -type d -empty
James Youngman wrote:
> Bob Proulx wrote:
> > find . -name "foo*" -exec sh -c "file {} >{}.tmp" \;
> [...]
> >What problem should I be aware of in the above?
>
> touch '/tmp/foo; echo foo: empty; rm -rf $HOME'
Yep. That would do it.
For
James Youngman wrote:
> While "-exec sh ..." would change this behaviour, don't do that as it is
> very insecure.
Insecure? In what way?
I envision something like this:
find . -name "foo*" -exec sh -c "file {} >{}.tmp" \;
Of course running this repeatedly is a problem unless it gets more
co
The Wanderer wrote:
> What I was doing at the time, so far as I remember, was:
>
> for i in `ls path/to/directory1/ path/to/directory2/` ; do ls -l $i &&
> $i ; done
>
> but that didn't work because the filename printed by the subshell did
> not exist in the present directory.
Would this have
James Youngman wrote:
> The Wanderer wrote:
> >For the little it's worth, I also find myself wanting to do something
> >like this from time to time, usually in a context in which find is not a
> >satisfactory alternative - or, at best, in which it would be awkward and
> >potentially difficult to co
James Youngman wrote:
> Bob Proulx <[EMAIL PROTECTED]> wrote:
> > Subject: bug in FIND: argument list too damn long using -exec chmod 440
> > {} +
> >
> > But that should not suffer from an argument list too long problem.
> > The command is being execute
Gabriel Petit N. wrote:
> I'm trying to updatedb but always says: "updatedb: new database would be
> empty"
> I'm using debian from a knoppix hd installation, kernel 2.6.15.2 (it
> happens with any kernel).
Thank you for your report. Note that Knoppix is not really Debian.
It has a basis in Deb
D Antryg M Revok wrote:
> you /probably/ don't care, since it's been "good enough" for the GNU
> tradition ( to be arbitrary and broken ) for years, but incompetence is
> incompentence.
>
> If I rig my work to abuse all into obedience, everyone has the right to
> call-me on it, and some program
Han Boetes wrote:
> And then ran the following command:
>
> find . -printf '%F %p\n'
>
> And the result was that all files were of the type unknown.
What does 'df' say?
df -TP .
That command also lists out the type of the filesystem.
What system are you running on?
uname -a
Follow-up Comment #4, bug #14615 (project findutils):
> Maybe I should change my .emacs configuration to add "untabify" to
write-file-hooks.
I wouldn't. The find code right now matches the defacto standard of mod8
tabs. This is the same as other GNU projects and is the default for emacs,
vi, v
Follow-up Comment #2, bug #14615 (project findutils):
> findutils is consistent in that \t is always treated as 8 columns
> If your editor cannot properly be configured to treat tab characters as
eight columns, then I would argue it is a bug in your editor
Agreed. The standards only say that ho
Eric Blake wrote:
> Chris Faylor (one of the cygwin maintainers) proposed a benchmark that
> times the entire operation, not just the xargs invocation:
> http://sources.redhat.com/ml/cygwin-patches/2005-q3/msg00107.html
>
> His numbers, with a modified xargs that ignored the _SC_ARG_MAX limit,
> s
Eric Blake wrote:
> But even if cygwin 1.5.19 were to define ARG_MAX and changes
> sysconf(_SC_ARG_MAX) to 32k instead of 1 meg, this would unfairly
> penalize cygexec mounts, which can handle much bigger command lines.
I know this sounds like it would unfairly limit all uses because some
uses are
Jens Schleusener wrote:
> Oh, just I found in /usr/include/fcntl.h the lines
>
> /* Redefine open and creat for large file enabled programming environment.
> */
> #ifdef _LARGE_FILES
> #define open open64
> #define creat creat64
> #endif
>
> just a line as you suspected in your previous
Follow-up Comment #5, bug #14243 (project findutils):
> So I guess \{ \} are part of basic regular expressions?
No. In basic regular expressions those would be invalid character escapes.
So that is not a valid POSIX basic regular expression. Because you would not
find those in a valid POSIX B
Follow-up Comment #3, bug #14243 (project findutils):
Note that GNU grep uses an GNU regular expression engine which is compliant
with POSIX but extents it. In particular \{ and \} are extensions. Normally
those would not be valid escape sequences. Those invalid basic regular
expression sequenc
Werner Brennecke - rockenstein AG wrote:
> das Kommando find hat scheinbar ein Problem mit gemounteten NFS-Shares.
>
> Hier erscheint immer find "Value too large for defined data type"
The 'find' command that you are using appears to be compiled without
large file support. "large file support" m
James Youngman wrote:
> The Findutils documentation (in the development CVS tree) now includes
> two longer worked examples which include several possible approaches
> to solving some common problems with a discussion of why some ways of
> solving the problem are better than others.
I think having
> 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 f
James Youngman wrote:
> 2. call the option "--all" instead of "-and" to not have the short
> form "-a". This allows us the option to later implement "-a" like
> find.
>
> Any comments from other list members?
I would prefer if all long options followed the double dash convention
allowing shor
er address to myself so that I can give the list
improved attention.
Bob
--
Bob Proulx <[EMAIL PROTECTED]>
http://www.proulx.com/~bob/
___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils
James Youngman wrote:
> Findutils 4.2.1 made this change - see the NEWS file.
I value compatibility between systems and so I think that is probably
a good change.
Bob
___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/l
Darrell Tangman wrote:
> I just installed findutils 4.2.20 and am finding that existing scripts
> need tweaking. The latest problem (and the only thing that appears to be
> an actual bug, and not just an incompatibility) is that the command
>
>find . -name '*' -print
>
> begins its output w
Substantially this same message was posted to bug-coreutils too. I
followed up to the poster with a response to it there that is also
appropriate here. Here is a pointer to it in the mail archive.
http://lists.gnu.org/archive/html/bug-coreutils/2005-04/msg00167.html
The archive does not show
Linda A. W. wrote:
> I think this has been the case a few times. As for worrying about
> quotes within my filenames, yes, it could be a concern, but quotes in
> file
> names are less likely than spaces in my usage.
But that is just trading one problem for the same problem with a
dif
Linda A. W. wrote:
> It would be nice if xargs had an option to enclose the arguments it reads
> in in either double or single quotes before passing them to a program.
>
> This would be especially useful for files with "spaces" in them.
> :-)
Trying to quote files with spaces is troublesome. Wha
46 matches
Mail list logo
