On 5/5/2019 9:50 AM, James Youngman wrote:
> On Wed, Apr 17, 2019 at 8:09 AM Bernhard Voelker wrote:
>
>> IMO starting to add one of such ideas to find(1) would open a can of
>> worms, like "what are my MP3 files with genre 'bluegrass'?".
>> Furthermore, there are specialized tools to do that
Thinking more about the usefulness of the first, though if
added, adding the 2nd operator would make sense.
It might be nice if the classification functionality of 'file'
was more accessible in a find with some type of
find -mtime -60 -mtype shell
would find files newer than 60 days and with a
On 11/18/2018 6:59 PM, L A Walsh wrote:
I was doing a "diff...
oops: reposted on diffutils...
(Too many of my tools are partly automated, so combining some
gnu tools into 1 folder occasionally has side effects -- oops, sorry for
noise)
I was doing a "diff -rq ./src ./dev
to find areas of 'dev' that hadn't been rolled into src when I
realized some patches had gone into src directly. Rather than
just telling me files "differed", it really would be useful,
sometimes, to know which of two files under a recursive
tree-diff was newer
Morgan Weetman wrote:
I'm not sure this is the correct list for your query... but does your diff
not have a '--no-dereference' option?
Ahhh...it does -- just not documented in the man page.
As for sending to wrong list..look at that address.
"bug-diffut...@gnu.org"
of course I just
Problem I'm running into is comparing two copies of tree that also
contains multiple symlinks.
First -- I see no way of telling diff not to follow symlinks in
doing comparisons. This seems non-standard for unix/linux utils and in
this case is causing alot of needless comparing like
trying to
Bernhard Voelker wrote:
On 03/03/2017 02:23 AM, L A Walsh wrote:
Why would there be anyone else on my systems?
You never walk alone:
$ ps -ae -o uid | grep -v UID | sort -u | wc -l
10
But those *are* 'me'... (18 of them). In many cases
I've forced proc
Eric Blake wrote:
For the record, POSIX
That's already been stated in the prior conversation, even though
you claim you know that:
"Please don't assume that I haven't been following the conversation".
So why are you repeating closed issues?
find ''
magically starting t
Eric Blake wrote:
Ah, but that's where you're missing the point. Changing interactive
behavior does NOT require that you are forced to always type the new
command-line option, because you are free to set up a wrapper function,
alias, or script on $PATH, which will supply that option on your beh
Eric Blake wrote:
On 03/02/2017 01:25 AM, L A Walsh wrote:
However given that some like the current behavior, a way to
allow users a choice of of no-path being the same as "." or
not-prepending "dot" would be the addition of an ENV var
along the lines of "FIND_N
Had a final(?) thought on this of a way it could be done.
Since, as james mentioned, POSIX doesn't specify the behavior
of the case where no paths are given, it would have been
ideal for not prepending "./" to names as the current behavior
also comes from starting with "." as a path.
However giv
Dale R. Worley wrote:
I think these show that the current 'find' behavior is desirable.
As you note in a later message, 'du' does take '.' as its default
argument, and that shows up in its output.
'ls' also takes '.' as its default argument, and that does not show up
in its output, but that's
Oops... correction, 'du' does prepend, 'ls' does not.
So either behavior could be justified...on that basis... ;-)
Bernhard Voelker wrote:
On 02/26/2017 08:44 AM, L.A. Walsh wrote:
Adding "./" when the user doesn't want it is unsafe because they
will remove it, creating another source of errors.
Thus said, treating the empty '' argument as "." for the traversal
but at the same time not doing so fo
James Youngman wrote:
Because, typically, -printf is used for output intended for humans
rather than programs.
Ahh... This is your 1st mistake. Interactive forms, and the
ones used most often are supposed to be the shortest forms. Go back
and look at early unix design docs. The de
Bernhard Voelker wrote:
On 02/20/2017 08:52 PM, L A Walsh wrote:
Would it be possible or not unduly difficult to change
'find' to recognize/allow a null path ("") specifically
to allow find to start at the current directory (much like
not specifying any paths), B
Would it be possible or not unduly difficult to change
'find' to recognize/allow a null path ("") specifically
to allow find to start at the current directory (much like
not specifying any paths), BUT also suppress the prepending
of "./" at the beginning of every result?
Almost every usage of ".
17 matches
Mail list logo
