le:
grep -q foo <(sh -c 'printf foo ; sleep 30' &)
with:
grep -q foo <(sh -c 'printf foo ; echo ; sleep 30' &)
In any case, grep is quite line oriented, as implied by an early
sentence in the man page grep(1):
"PATTERNS is one or more pattern
gt; For the time being, I hacked together a tool that does just what I need
Bingo.
Given that our talents and resources are finite, and our various
needs and situations infinite, it's impossible to have general
purpose tools that are ideal for every situation.
We can do the rest, individually.
--
Paul Jackson
jack...@fastmail.fm
would think that minimizing the attack surface on common commands
by not linking in non-essential compression libraries would be a no brainer.
--
Paul Jackson
jack...@fastmail.fm
d half the command lines I type at a shell prompt fail "command not
found".)
--
Paul Jackson
jack...@fastmail.fm
let all of us see that file.list, then any of us should
be able to easily reproduce this problem.
--
Paul Jackson
jack...@fastmail.fm
wild guess speculation would be that you're hitting some unknown limit on
xargs when invoked with an argument list that is right at the limit of what
your system allows. But I wouldn't bet a cheap beer on that guess being right.
--
Paul Jackson
jack...@fastmail.fm
ot; 2>/dev/null ) | grep -c "^${V}$") -gt 0 ]];
then
Or, more efficiently, just "grep -q" directly in TMPOUT and skip the echo and
pipe entirely:
if grep -q "^${V}$" "${TMPOUT}"; then
--
Paul Jackson
jack...@fastmail.fm
me in my book.
But, yes, as Paul Eggert notes, command line parsing of 'grep -A 123' would be
ambiguous. Is "123" a filename, or a parameter to the "-A" argument?
--
Paul Jackson
jack...@fastmail.fm
derived from some
parsimonious variant of my above paragraph, explaining both the "-h" and "-H"
options.
--
Paul Jackson
jack...@fastmail.fm
Paul Eggert wrote:
>> yup
However, perhaps my "little" essay answers some of sur-behoffski's
considerations.
--
Paul Jackson
jack...@fastmail.fm
x27;stdout_error' flag being set,
that leads to the additional error output.
--
Paul Jackson
jack...@fastmail.fm
ew. MinGW needs to be "quarantined" in this circumstance,
which is what the test for a non-zero inode would (apparently, from what you
say)
accomplish.
In other words, our special handling for MinGW should not alter how we handle
everyone else.
--
Paul Jackson
p...@usa.net
Pádraig Brady wrote:
>> How about a linux kernel version check at build time?
Binaries are not always executed on the same kernel on which they are built.
--
Paul Jackson
p...@usa.net
four red numbers "1234".
I did not double check the perfection of the above details,
so might be off by one or two, here or there.
But I'd guess that this might be a "bug" (unexpected feature)
in the terminal emulator's handling of ANSI color escape
sequences, rather than a bug in grep.
--
Paul Jackson
p...@usa.net
m either of the last two test cases above, with the
red "1234" numbers
NOT appearing in an 80 wide xterm or uxterm, but appearing ok if I widen the
terminal.
--
Paul Jackson
p...@usa.net
only make sense if you're burning lots of
CPU time or project time, on this particular scan.
--
Paul Jackson
p...@usa.net
an be cast in this form, the "1.6 seconds" for even a
rather large example is compelling. In my most common use case,
I am dealing with over 10 million entries in one or the other of the
words I am looking for, or the search space I am looking in.
No variant of "grep -f" that I have ever seen can handle such problems.
--
Paul Jackson
p...@usa.net
l inside the $( ... ) or ` ... ` command substitution, and thus equal
to '{}', with $a not yet set to "i" by the final execution of the xargs
invocation of the output from that command substitution.
--
Paul Jackson
p...@usa.net
depends on which version of "ed"
is used, I don't need to rename my preferred, archaic, "ed".
But, perhaps L. A. Walsh might choose to do with "grep" as I have
done with "ed" ... put an old version ahead of the current version
on $PATH.
(wave to "law" ... hope you're doing well.)
--
Paul Jackson
p...@usa.net
n order
that it can then scan backwards, once it finds a match.
The usual line oriented buffering doesn't work so well when
the input file might have no, or at least infrequent, line breaks.
--
Paul Jackson
p...@usa.net
ratherthan emit nothing in case of an encoding error.
However, I can't imagine that this is worth the effort, and
(being a stickin the mud old fart) I usually recommend against incompatible
changes
unless strongly necessary.
So ... whatever ... nevermind ... as they say.
--
Paul Jackson
p...@usa.net
ts first character was a
space.
The escaped single quotes around the "$1" parameter meant that you were
not looking for the three character pattern "sys", but rather for the five
character pattern "'sys'" (which is less likely to have appeared in your
test data.)
--
Paul Jackson
p...@usa.net
f8noss (struct dfa *d)
--
Paul Jackson
p...@usa.net
want, then I
think you have it.
I am a bit surprised that this pattern works, as the [...] class lacks a
closing ']' character.
The following alternative is shorter, does the same thing, and I find less
surprising:
sed -e 's/[]\\[?+{|()]/\\&/g'
--
Paul Jackson
p...@usa.net
the
same results as the command "grep somepattern somefile | wc -l" (each matching
line counts once.)
--
Paul Jackson
p...@usa.net
The following awk command will do this (so long as filenames don't have ':'
colon chars):
grep IP /etc/protocols /etc/services |
awk -F: '
$1 != fname { print $1 ":"; fname = $1; }
{ sub("^[^:]*:", ""); print; }
'
--
Paul Jackson
p...@usa.net
o they hang? Do they report a fifo or socket file type? Do they
also hang, perhaps on a non-responsive network file system?
--
Paul Jackson
p...@usa.net
Gary wins the sharp eyes of the day award.
Paul retreats to the kitchen to make a cup of coffee.
:)
--
Paul Jackson
p...@usa.net
any results at all.
My strace observations in the previous paragraph are probably
reliable. My guess as to the logic grep is using to determine
it's process exit status are probably not reliable.
--
Paul Jackson
p...@usa.net
rsed by the "-q" option.
--
Paul Jackson
p...@usa.net
into the future, I'll follow up with an
update pointing to my "ftest" command on github.
--
Paul Jackson
p...@usa.net
ing one usage of grep slower in order
to make some other usage faster, and would risk some nasty bugs.
--
Paul Jackson
p...@usa.net
ot;cat" above refers to four legged felines, not to the
concatenate command line utility.)
--
Paul Jackson
p...@usa.net
]'", does nothing that I can see,
on your data, since every line has at least one character that is
not an [A-Z] upper case letter, so every line matches that pattern.
I would suggest that using "grep -E" (or "egrep") is clearer
than using "grep" and escaping the '|' symbols.
--
Paul Jackson
p...@usa.net
oh - and the exclusion of lines with the pattern "^\t\t$"
makes no difference on your dataset, since that dataset
has no lines consisting solely and exactly of two tabs.
--
Paul Jackson
p...@usa.net
Watson's libpipeline:
http://libpipeline.nongnu.org
--
Paul Jackson
p...@usa.net
P.S. -- on multi-core systems (which most are these days),
piping data between executables working in parallel can
be a good way to reduce the elapsed clock time of a job,
albeit at the expense of higher system CPU utilization.
--
Paul Jackson
p...@usa.net
the code
to be consistent with what Andi, reasonably
enough, expected.
Every time any little detail like this changes,
somebody's code breaks quietly in the night.
However since I'm not volunteering to submit
the documentation (or code) patch, my vote
counts for little :).
Carry on.
--
t;xargs -0", in order to avoid some
ancient and regrettable nasty irregularities in how xargs otherwise
handles embedded spaces and unbalanced quotation marks in the
input stream.
See my xargs wrapper for a convenient workaround for this nastiness:
http://thepythoniccow.us/x.c.txt
--
t;0.12>
21:07:25.408260 read(0, "", 4096) = 0 <1.992492>
21:07:27.400830 fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 <0.19>
21:07:27.400921 close(1)= 0 <0.18>
21:07:27.400979 close(2)= 0 <0.19>
21:07:27.401046 exit_group(1) = ?
21:07:27.401259 +++ exited with 1 +++
--
Paul Jackson
p...@usa.net
attern than was grep. See the "Comparative Performance"
section of rawscan's github page for these results:
https://github.com/ThePythonicCow/rawscan
--
Paul Jackson
p...@usa.net
criptor 1) for the data it should search.
--
Paul Jackson
p...@usa.net
ds in parallel, and took
about 1/4 the time, otherwise performing rather like xargs, which ran one grep
command at a time.
(Granted, reading either the 'parallel' or 'xargs' man pages is not easy
.)
--
Paul Jackson
p...@usa.net
ustify
the coding, documentation, and maintenance effort.
I would expect the time to read the large file in from disk to
dominate the total elapsed time in any case.
(or maybe I am just jealous that I didn't think of that parallel
grep use case myself .)
--
Paul Jackson
p...@usa.net
grees that its
interface is somewhat borked. See a note Gellis posted a decade after writing
xargs, which I include in the above "x.c" source. An amusing bit of history ...
--
Paul Jackson
p...@usa.net
>> grep '...' 2>&1
But won't that send all error messages into the stdout stream,
not just the "binary file matches" messages?
--
Paul Jackson
p...@usa.net
already know what they are reading..
--
Paul Jackson
p...@usa.net
the "binary file
matches" error
message might come out on the "wrong" (for your use case) file descriptor, and
leave all
the other grep work to whatever the currently installed "real" grep does.
--
Paul Jackson
p...@usa.net
--
Paul Jackson
p...@usa.net
onable set of tradeoffs, and explained their decisions.
Thank-you, Paul Eggert, and others, for continuing to keep ed(1)
alive and well. It's been my "standard text editor" for 45 years
now, and counting. I'm glad it's in good hands.
--
Paul Jackson
p...@usa.net
k 'NR == 1 || /carenas/'
USER,TIP
john,0
jane,10
carenas,100
@@
USER,TIP
carenas,100
awk 'NR == 1 || /carenas/' 0.00s user 0.00s system 88% cpu 0.002 total
As I expected, sed is fastest, grep next, and awk slowest of the three,
but the 1, 2, and 3 millisecond totals are within the margin of test error.
--
Paul Jackson
p...@usa.net
oops - grep slower than awk, not the other way around,
on these _highly_ inconclusive timings.
--
Paul Jackson
p...@usa.net
erl used to be the King of such challenges.
--
Paul Jackson
p...@usa.net
53 matches
Mail list logo
