On 2022-08-22 15:01, Dave Close wrote:
> But if I try to simplify that command by inserting the output of the
> ls command above, it doesn't work.
>
> $ grep CALL $( ls --quoting-style=shell-escape-always ? )
> grep: '#': No such file or directory
> grep: "'": No such file or directory
> g
On Thu, Aug 25, 2022 at 10:10:46PM -0700, L A Walsh wrote:
there's more to life than coreutils
-
But the OP was posting about inconsistencies in coreutils.
What you are saying is because coreutils is broken/inconsistent, use
'find'.
For programmatic use, definitely. When someone's trying
On 2022/08/24 10:31, Michael Stone wrote:
On Wed, Aug 24, 2022 at 10:17:49AM -0700, L A Walsh wrote:
On 2022/08/23 00:30, Mike Jonkmans wrote:
que
find is the path to go.
Because find isn't part of coreutils?
there's more to life than coreutils
-
But the OP was posting about inconsi
On Wed, Aug 24, 2022 at 10:17:49AM -0700, L A Walsh wrote:
On 2022/08/23 00:30, Mike Jonkmans wrote:
que
find is the path to go.
Because find isn't part of coreutils?
there's more to life than coreutils
find isn't consistent either:
find . -name \*.foo
gives you output from dir ".", but
On 2022/08/23 00:30, Mike Jonkmans wrote:
que
find is the path to go.
Because find isn't part of coreutils?
find isn't consistent either:
find . -name \*.foo
gives you output from dir ".", but you have to edit the output or add
other args to
get just the filenames, since there is n
On Tue, Aug 23, 2022 at 09:50:20AM +0900, Dominique Martinet wrote:
> Dave Close wrote on Mon, Aug 22, 2022 at 03:01:11PM -0700:
> > $ grep CALL ./* | wc
> > 16325 61444 950870
> > $ grep CALL $( ls ./* ) | wc
> > 16375 61601 953451
> >
> > So I almost have a solution. Except the ext
Dave Close wrote on Mon, Aug 22, 2022 at 03:01:11PM -0700:
> $ grep CALL ./* | wc
> 16325 61444 950870
> $ grep CALL $( ls ./* ) | wc
> 16375 61601 953451
>
> So I almost have a solution. Except the extra 50 lines found in the
> second command are disturbing. Thus far, it appears tha
