On Thursday, January 17, 2013 9:33:53 pm David Xu wrote:
I am trying to fix a bug in GNU grep, the bug is if you
want to skip FIFO file, it will not work, for example:
grep -D skip aaa .
it will be stucked on a FIFO file.
Here is the patch:
http://people.freebsd.org/~davidxu/patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/18/13 08:39, John Baldwin wrote:
I (disclaimer: not bsdgrep person) have just tested that bsdgrep
handle this case just fine.
The non-blocking part is required to make the code function, otherwise
the system will block on open() if fifo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/18/13 08:39, John Baldwin wrote:
On Thursday, January 17, 2013 9:33:53 pm David Xu wrote:
I am trying to fix a bug in GNU grep, the bug is if you want to
skip FIFO file, it will not work, for example:
grep -D skip aaa
I am trying to fix a bug in GNU grep, the bug is if you
want to skip FIFO file, it will not work, for example:
grep -D skip aaa .
it will be stucked on a FIFO file.
Here is the patch:
http://people.freebsd.org/~davidxu/patch/grep.c.diff2
Is it fine to be committed ?
Regards,
David Xu
On 2012-12-20 08:13, Eitan Adler wrote:
in xrealloc_impl
338 new_ptr = realloc(ptr, new_size);
339 if (new_ptr != NULL)
340 {
341 hash_table_del(xmalloc_table, ptr);
^^^ isn't this a use-after-free of ptr?
Yes, realloc does not guarantee the realloc'd space will be at the same
On Thu, Dec 20, 2012 at 01:19:07PM +0100, Dimitry Andric wrote:
On 2012-12-20 08:13, Eitan Adler wrote:
in xrealloc_impl
338 new_ptr = realloc(ptr, new_size);
339 if (new_ptr != NULL)
340 {
341 hash_table_del(xmalloc_table, ptr);
^^^ isn't this a use-after-free of ptr?
Hey,
in xrealloc_impl
338 new_ptr = realloc(ptr, new_size);
339 if (new_ptr != NULL)
340 {
341 hash_table_del(xmalloc_table, ptr);
^^^ isn't this a use-after-free of ptr?
§7.22.3.5.2 says that ptr is deallocated after the call to realloc.
342 hash_table_add(xmalloc_table,
Hi Alfred,
Hello,
Where is diff/sdiff projects?
there's an incomplete version of diff in my perforce branch. I added
wchar support but it introduced some regresssions. No progress since
then. As for sdiff, Steven Kreuzer did some progress there but I don't
know details.
Gabor
* Gabor Kovesdan ga...@kovesdan.org [100330 08:52] wrote:
On 30/03/2010 20:00, Mark nesterovych wrote:
Hi all.
Decided to write BSD licensed grep and provide it to FreeBSD project if
success.
Dear Mark,
this project is already completed and is going to be integrated to the
base
Hi all.
Decided to write BSD licensed grep and provide it to FreeBSD project if
success.
But encountered with a problem, which I can resolve.
I looked through the gnu, OpenBSD sources and posix requirements to this
utility, and can't find a solution.
Problem is next. System have few utilities [e
Mark nesterovych m.nesterov...@gmail.com writes:
Decided to write BSD licensed grep and provide it to FreeBSD project if
success.
There is one already: textproc/bsdgrep.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org
2010/3/30 Dag-Erling Smørgrav d...@des.no:
Mark nesterovych m.nesterov...@gmail.com writes:
Decided to write BSD licensed grep and provide it to FreeBSD project if
success.
There is one already: textproc/bsdgrep.
Which is the basis for both NetBSD's and OpenBSD's implementations.
Also, you
On Tue, Mar 30, 2010 at 10:15, Mark nesterovych m.nesterov...@gmail.com wrote:
Decided to write BSD licensed grep and provide it to FreeBSD project if
success.
How far along are you in this project?
--
James P. Howard, II, MPA MBCS
j...@jameshoward.us
On 30/03/2010 20:00, Mark nesterovych wrote:
Hi all.
Decided to write BSD licensed grep and provide it to FreeBSD project if
success.
Dear Mark,
this project is already completed and is going to be integrated to the
base system once portmgr can run an experimental build to make sure
On 30/03/2010 16:15, Mark nesterovych wrote:
Decided to write BSD licensed grep and provide it to FreeBSD project if
success.
But encountered with a problem, which I can resolve.
I looked through the gnu, OpenBSD sources and posix requirements to this
utility, and can't find a solution
On Tue, 2010-03-30 at 11:01 -0400, James P. Howard, II wrote:
2010/3/30 Dag-Erling Smørgrav d...@des.no:
Mark nesterovych m.nesterov...@gmail.com writes:
Decided to write BSD licensed grep and provide it to FreeBSD project if
success.
There is one already: textproc/bsdgrep.
Which
0.02 sys
0.26 real 0.22 user 0.02 sys
0.44 real 0.35 user 0.01 sys
= grep
0.04 real 0.04 user 0.00 sys
4.45 real 4.15 user 0.01 sys
2.00 real 1.81 user 0.00 sys
0.02 sys
0.26 real 0.22 user 0.02 sys
0.44 real 0.35 user 0.01 sys
= grep
0.04 real 0.04 user 0.00 sys
4.45 real 4.15 user 0.01 sys
2.00 real 1.81 user 0.00
On Wednesday 04 November 2009 13:49:54 Mel Flynn wrote:
Using env MALLOC_OPTIONS= also has no impact at all (just in case defaults
aren't that). Since fgrep is fast and basically seeds the cache for grep,
I'm ruling out disks/io reads. In fact, /tmp on this laptop is memory disk
(one reason
. PCRE provides a POSIX-compliant interface to deal with
Perl-compatible regex for those, who are already familiar with the
former but it's still Perl regex and not POSIX! That's why some people
get confused when PCRE comes to the topic.
On i386 machines, grep -i is significantly slower:
i386, 7.2
Hi,
attached a little test script for grep's -i performance. I tried a few
different machines and the 64-bit 7.2 machine I could steal doesn't seem to be
affected and out performs pcregrep.
On i386 machines, grep -i is significantly slower:
i386, 7.2-STABLE of Sep 8, load averages: 0.00, 0.02
0.44 real 0.35 user 0.01 sys
= grep
0.04 real 0.04 user 0.00 sys
4.45 real 4.15 user 0.01 sys
2.00 real 1.81 user 0.00 sys -- [fF][Oo][Oo]
Just did a quick test on the 8.0-RC2/i386 with very old Athlon
.
I realize this, but for the case in question it does not matter. Both
'regexes' should do the same in PCRE and POSIX. I provided the comparison to
show that the 'problem of case insensitive comparison' is solvable, at the
very least for the simple case.
On i386 machines, grep -i
Andrey Chernov ha scritto:
Just from quick looking at the sources...
This code looks suspicious:
wend = sscanf(l-dat[pmatch.rm_eo], %lc, wend);
Perhaps it should be
if (sscanf(l-dat[pmatch.rm_eo], %lc, wend) != 1)
r = REG_NOMATCH;
The next thing is that perhaps each r = REG_NOMATCH;
Hello all,
I've reviewed BSD grep based on your comments and the bug reports I
received. The new version is committed to the ports tree as
textproc/bsdgrep and there is a base patch available:
http://kovesdan.org/patches/grep-base.diff
I've asked portmgr to test my patch on pointyhat
On Tue, Aug 26, 2008 at 08:25:01PM +0200, Gabor Kovesdan wrote:
Hello all,
I've reviewed BSD grep based on your comments and the bug reports I
received. The new version is committed to the ports tree as
textproc/bsdgrep and there is a base patch available:
http://kovesdan.org/patches/grep
Gábor Kövesdán wrote:
Well, it seems you have missed the first nits of the discussion. GNU
grep has some regression test, which doesn't pass completely itself
either. :) I've mentioned here that I used those tests to find out
what incompatible options are there. Unfortunately, I have to say
Well, it seems you have missed the first nits of the discussion. GNU
grep has some regression test, which doesn't pass completely itself
either. :) I've mentioned here that I used those tests to find out
what incompatible options are there. Unfortunately, I have to say
that BSD grep won't
in different single
and multi-byte locates for grep/sort/etc could also be a big help.
What regression suites do other implementations have? e.g. the GNU
textutils.
Kris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman
On Mon, Jul 07, 2008 at 10:06:31PM +0200, Kris Kennaway wrote:
What regression suites do other implementations have? e.g. the GNU
textutils.
They basically have regex tests, but nothing locale specific, since locale
ordering is different from platform to platform (until Unicode Collation
Andrey Chernov wrote:
On Mon, Jul 07, 2008 at 10:06:31PM +0200, Kris Kennaway wrote:
What regression suites do other implementations have? e.g. the GNU
textutils.
They basically have regex tests, but nothing locale specific, since locale
ordering is different from platform to platform
platform to platform (until Unicode
Collation Algorithm will win).
OK. Well at least it is a start - passing those existing regression
tests should be a goal.
Well, it seems you have missed the first nits of the discussion. GNU
grep has some regression test, which doesn't pass completely
1) You can't convert just whole buffer after fread() since it can be
ended in the middle of multibyte sequence on BUFSIZ edge. Look how GNU
utils do it.
OK, now I haven't thought of this aspect. What about this?
#define iswbinary(ch) (!iswspace((ch)) iswcntrl((ch)))
int
On Tue, Jun 24, 2008 at 10:32:17PM +0200, Gabor Kovesdan wrote:
ch = fgetwc(f);
You must clear errno before and handle EILSEQ possible coming after
fgetwc() somehow. Perhaps by return ret = 1 (binary), I am not sure.
fgetwc() returns WEOF in that case which is not true end of
On Wed, Jun 25, 2008 at 01:04:20AM +0400, Andrey Chernov wrote:
if ((s = mbstowcs(NULL, f-base, 0)) == -1)
return (0);
The same here. Check EILSEQ and return 1
BTW, do you realyze that this code malloc()s _whole_file_ into memory
(which not fits for very big
Andrey Chernov escribió:
On Wed, Jun 18, 2008 at 12:40:24PM +0200, Dag-Erling Sm??rgrav wrote:
For grep, I believe it should simply be a matter of calling setlocale(),
using wide strings, and using a multibyte regex engine (for appropriate
values of simply).
See my prev reply telling
On Sun, Jun 22, 2008 at 02:58:17PM +0200, Gabor Kovesdan wrote:
Andrey Chernov escribi?:
On Wed, Jun 18, 2008 at 12:40:24PM +0200, Dag-Erling Sm??rgrav wrote:
For grep, I believe it should simply be a matter of calling setlocale(),
using wide strings, and using a multibyte regex engine
Maxim Sobolev wrote:
Good regression test suite which would include cases in different
single and multi-byte locates for grep/sort/etc could also be a big help.
I will implement test cases for sort in UTF-8 as part of my project.
___
freebsd-hackers
Konrad Jankowski [EMAIL PROTECTED] writes:
BOM's should be handled at the program level.
Yeah, that makes sense; libc has no way of knowing whether the start of
the string you're processing is actually the start of the file.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
Andrey Chernov [EMAIL PROTECTED] writes:
BSD sort as an idea will be a good project indeed, but BSD sort
implementation we currently have at hand is totally misleading and should
be rewritten from the scratch, I realize it when long time ago I try to
localize it for single byte locales.
I
On Tue, Jun 17, 2008 at 12:58:12PM +0200, Gabor Kovesdan wrote:
Yes, and once this is done, sort will work out of he box, if it uses
strcoll. Already tried on a prototype.
Only GNU sort for multibyte chars. BSD sort is programmed too badly and
can't be fixed even for single byte
On Wed, Jun 18, 2008 at 10:22:31AM +0200, Dag-Erling Sm??rgrav wrote:
I think part of the problem is that there aren't enough people who truly
understand localization. I think I understand most of it, but I'm
pretty sure I *don't* understand how collation works, or is supposed to
work.
strings to strings that can be compared directly with strcmp()?
In any case, this is a libc issue, right? As long as sort / grep uses
the API correctly, they will work fine once libc is fixed?
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd
Konrad Jankowski [EMAIL PROTECTED] writes:
Dag-Erling Smørgrav [EMAIL PROTECTED] writes:
In any case, this is a libc issue, right? As long as sort / grep
uses the API correctly, they will work fine once libc is fixed?
Correct. Given sort uses strcoll()/wcscoll()/strxfrm()/wcsxfrm
, but for multibyte
they do just raw binary.
In any case, this is a libc issue, right? As long as sort / grep uses
the API correctly, they will work fine once libc is fixed?
GNU grep and sort will work just fine.
BSD grep not calls setlocale() but even it will be added, BSD grep
have other places
On Wed, Jun 18, 2008 at 12:40:24PM +0200, Dag-Erling Sm??rgrav wrote:
For grep, I believe it should simply be a matter of calling setlocale(),
using wide strings, and using a multibyte regex engine (for appropriate
values of simply).
See my prev reply telling more details. Using wide strings
On Wed, Jun 18, 2008 at 11:14:16AM +0200, Konrad Jankowski wrote:
I think the best place for this type of information is currently my SoC
wiki.
http://wiki.freebsd.org/KonradJankowski/Collation
I know currently it has very little information, however.
I can also create another page dedicated
On Mon, 16 Jun 2008, Dag-Erling Smørgrav wrote:
Doug Barton [EMAIL PROTECTED] writes:
Andrey Chernov [EMAIL PROTECTED] writes:
Please note that BSD grep is not localized (and can't be per design)
and works only with standard C locale. It may not affect ports
system processing but shurely
and multi-byte locates for grep/sort/etc could also be a big help.
Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
___
freebsd-hackers@freebsd.org mailing list
http
Andrey Chernov escribió:
On Tue, Jun 17, 2008 at 04:28:10AM +0400, Andrey Chernov wrote:
BSD grep is even not bothering to call setlocale(). I can't say is it can
be simple healed by adding that call, some test suite run is needed.
Quick source inspection reveals that BSD grep
be easier to lift it from PostgreSQL, which also uses it.
No, we have it already for many years (libc/regexec).
I hadn't noticed... ISTR it was an issue back when jphoward wrote his
BSD-licensed grep.
However, it's not the same engine - it's Spencer's old engine with
multibyte support added
On Tue, Jun 17, 2008 at 09:21:52AM +0200, Gabor Kovesdan wrote:
Sorry for the possibly silly question, but what we mean localization
here in the case of grep? As far as I see, it works with wide chars,
because the regex library is aware of those. What other aspect needs to
be taken
On Tue, Jun 17, 2008 at 11:46:07AM +0400, Andrey Chernov wrote:
On Tue, Jun 17, 2008 at 09:21:52AM +0200, Gabor Kovesdan wrote:
Sorry for the possibly silly question, but what we mean localization
here in the case of grep? As far as I see, it works with wide chars,
because the regex
Gabor Kovesdan wrote:
In case of sort, I understarnd that it should
explicitly handle wide characters due to the different alphabet of the
different languages and yes, that seems to be a difficult task...
Note that Konrad Jankowski in another SoC project is adding to our C
library support
On Tue, Jun 17, 2008 at 12:08:38PM +0200, Dag-Erling Sm??rgrav wrote:
I hadn't noticed... ISTR it was an issue back when jphoward wrote his
BSD-licensed grep.
BSD grep have enough (but not fatal, as BSD sort) problems even with
single byte locales we support initially in our regex (old pre
Diomidis Spinellis wrote:
Gabor Kovesdan wrote:
In case of sort, I understarnd that it should explicitly handle wide
characters due to the different alphabet of the different languages
and yes, that seems to be a difficult task...
Note that Konrad Jankowski in another SoC project is adding
On Tue, Jun 17, 2008 at 10:54:42AM +0200, Konrad Jankowski wrote:
Diomidis Spinellis wrote:
Gabor Kovesdan wrote:
In case of sort, I understarnd that it should explicitly handle wide
characters due to the different alphabet of the different languages
and yes, that seems to be a
Andrey Chernov escribió:
On Tue, Jun 17, 2008 at 10:54:42AM +0200, Konrad Jankowski wrote:
Diomidis Spinellis wrote:
Gabor Kovesdan wrote:
In case of sort, I understarnd that it should explicitly handle wide
characters due to the different alphabet of the different languages
with
origin=devel/gettext.
egrep -l DEPORIGIN:($origin|$ro_opd)$ $pdb/*/+CONTENTS
Obviously this works in portmaster with the gnu grep, but if ro_opd is
unset with the bsd grep I get:
egrep: empty (sub)expression
I've looked at this and I have a patch with a workaround:
http://kovesdan.org/patches
with
origin=devel/gettext.
egrep -l DEPORIGIN:($origin|$ro_opd)$ $pdb/*/+CONTENTS
Obviously this works in portmaster with the gnu grep, but if ro_opd is
unset with the bsd grep I get:
egrep: empty (sub)expression
I've looked at this and I have a patch with a workaround:
http://kovesdan.org/patches
On 2008-06-17, Gabor Kovesdan wrote:
egrep: empty (sub)expression
I've looked at this and I have a patch with a workaround:
http://kovesdan.org/patches/grep.dougb.diff
Unfortunately this breaks things. For example:
$ grep -E '(test||test)' /dev/null
grep: parentheses not balanced
$ grep
On Sun, Jun 15, 2008 at 09:11:36PM -0700, Garrett Cooper wrote:
Now all we need to do is write / import a BSD compatible less(1) into
FreeBSD =).
less is dual licensed.
Joerg
___
freebsd-hackers@freebsd.org mailing list
Doug Barton [EMAIL PROTECTED] writes:
Andrey Chernov [EMAIL PROTECTED] writes:
Please note that BSD grep is not localized (and can't be per design)
and works only with standard C locale. It may not affect ports
system processing but shurely affects real texts handling.
That is very
Dag-Erling Smørgrav wrote:
Doug Barton [EMAIL PROTECTED] writes:
Andrey Chernov [EMAIL PROTECTED] writes:
Please note that BSD grep is not localized (and can't be per design)
and works only with standard C locale. It may not affect ports
system processing but shurely affects real texts
On Mon, Jun 16, 2008 at 02:36:23PM +0200, Dag-Erling Sm??rgrav wrote:
Please note that BSD grep is not localized (and can't be per design)
and works only with standard C locale. It may not affect ports
system processing but shurely affects real texts handling.
That is very troubling
On Tue, Jun 17, 2008 at 04:22:25AM +0400, Andrey Chernov wrote:
On Mon, Jun 16, 2008 at 02:36:23PM +0200, Dag-Erling Sm??rgrav wrote:
Please note that BSD grep is not localized (and can't be per design)
and works only with standard C locale. It may not affect ports
system processing
On Tue, Jun 17, 2008 at 04:28:10AM +0400, Andrey Chernov wrote:
BSD grep is even not bothering to call setlocale(). I can't say is it can
be simple healed by adding that call, some test suite run is needed.
Quick source inspection reveals that BSD grep operates with single bytes
only (util.c
.
egrep -l DEPORIGIN:($origin|$ro_opd)$ $pdb/*/+CONTENTS
Obviously this works in portmaster with the gnu grep, but if ro_opd is
unset with the bsd grep I get:
egrep: empty (sub)expression
If I set ro_opd to something, it works.
hth,
Doug
--
This .signature sanitized for your protection
=devel/gettext.
egrep -l DEPORIGIN:($origin|$ro_opd)$ $pdb/*/+CONTENTS
Obviously this works in portmaster with the gnu grep, but if ro_opd is
unset with the bsd grep I get:
egrep: empty (sub)expression
To avoid these problems I had proposed to instrument getopt to write
options passed
with
origin=devel/gettext.
egrep -l DEPORIGIN:($origin|$ro_opd)$ $pdb/*/+CONTENTS
Obviously this works in portmaster with the gnu grep, but if ro_opd is
unset with the bsd grep I get:
egrep: empty (sub)expression
If I set ro_opd to something, it works.
Hello Doug,
thanks a lot for you response! I'll
of results you can test with
origin=devel/gettext.
egrep -l DEPORIGIN:($origin|$ro_opd)$ $pdb/*/+CONTENTS
Obviously this works in portmaster with the gnu grep, but if ro_opd
is unset with the bsd grep I get:
egrep: empty (sub)expression
To avoid these problems I had proposed to instrument getopt
with BSD grep.
Please note that BSD grep is not localized (and can't be per design) and
works only with standard C locale. It may not affect ports system
processing but shurely affects real texts handling.
--
http://ache.pp.ru/
___
freebsd-hackers
myself. Then I'll think about this idea and ask portmgr to do
an exp-run with BSD grep.
Please note that BSD grep is not localized (and can't be per design) and
works only with standard C locale. It may not affect ports system
processing but shurely affects real texts handling.
Kudos on the hard
to do
an exp-run with BSD grep.
I think that would be very valuable.
Please note that BSD grep is not localized (and can't be per design) and
works only with standard C locale. It may not affect ports system
processing but shurely affects real texts handling.
That is very troubling
Hello All,
Today I've basically terminated te feature-completion of the
BSD-licensed grep from OpenBSD. It means, that I've accomplished the
following tasks:
- Implement --label
- Implement --null
- Implement --color / --colour
- Implement -D / --devices
- Implement -H / --with-filename
Hello all,
as you might have already known, I'm working on the BSD-licensed
versions of these utilities, porting them from OpenBSD and complete the
functionality. Still, I have a lot to do, but here's a little bit of
status report:
grep:
- Implemented --label
- Implemented --null
Hello all,
as you might have already known, I'm working on the BSD-licensed
versions of these utilities, porting them from OpenBSD and complete the
functionality. Still, I have a lot to do, but here's a little bit of
status report:
grep:
- Implemented --label
- Implemented --null
- Implemented
Hello all,
as you might have already known, I'm working on the BSD-licensed
versions of these utilities, porting them from OpenBSD and complete the
functionality. Still, I have a lot to do, but here's a little bit of
status report:
grep:
- Implemented --label
- Implemented --null
- Implemented
On Wed, 22 Aug 2007, sam wrote:
Index: praudit.c
===
RCS file: /data/fbsd-cvs/ncvs/src/contrib/openbsm/bin/praudit/praudit.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 praudit.c
--- praudit.c16 Apr 2007 15:36:57 -
RCS file:
/data/fbsd-cvs/ncvs/src/contrib/openbsm/bin/praudit/praudit.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 praudit.c
--- praudit.c16 Apr 2007 15:36:57 -1.1.1.3
+++ praudit.c21 Aug 2007 14:26:43 -
@@ -107,6 +107,7 @@
free(buf);
if (oneline)
Robert Watson wrote:
On Tue, 21 Aug 2007, sam wrote:
# praudit /etc/auditpipe | grep bla bla bla # praudit
/etc/auditpipe | tee file.log
this is not work please help me
This thread is also on freebsd-hackers, but just to follow up here
as well for the purposes of the archives:
- It's
On Mon, 20 Aug 2007, sam wrote:
I am installed AUDIT
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html
# praudit /etc/auditpipe | grep xxx
# praudit /etc/auditpipe | tee file.log
# praudit /etc/auditpipe file.log
this is not work
please help me
Vladimir,
Could you
Robert Watson wrote:
On Mon, 20 Aug 2007, sam wrote:
I am installed AUDIT
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html
# praudit /etc/auditpipe | grep xxx
# praudit /etc/auditpipe | tee file.log
# praudit /etc/auditpipe file.log
this is not work
please help me
Eric Crist wrote:
On Aug 21, 2007, at 7:52 AMAug 21, 2007, sam wrote:
Robert Watson wrote:
On Mon, 20 Aug 2007, sam wrote:
I am installed AUDIT
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html
# praudit /etc/auditpipe | grep xxx
# praudit /etc/auditpipe | tee file.log
/auditpipe | grep xxx
# praudit /etc/auditpipe | tee file.log
# praudit /etc/auditpipe file.log
this is not work
please help me
Vladimir,
Could you confirm that when you typed the command, you entered
it as above instead of using /dev/auditpipe, the actual name of
the audit device? I think
On Aug 21, 2007, at 7:52 AMAug 21, 2007, sam wrote:
Robert Watson wrote:
On Mon, 20 Aug 2007, sam wrote:
I am installed AUDIT
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html
# praudit /etc/auditpipe | grep xxx
# praudit /etc/auditpipe | tee file.log
# praudit /etc
On Tue, 21 Aug 2007, Eric Crist wrote:
thx this not working wite up buffer-pipe to 4096 bytes
Can I ask what is in the /etc/auditpipe file?
I believe what is meant is /dev/auditpipe, which provides a live event stream
from the kernel's audit subsystem in FreeBSD 6.2 and later. You can
Try the --line-buffered option to grep. I've had a lot of luck with
it. Something like the following may work for you:
# praudit /etc/auditpipe | grep --line-buffered -e xxx
If you just want to pipe to a file, use something like:
# praudit /etc/auditpipe | grep --line-buffered -e
Hi, all.
I am installed AUDIT
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html
# praudit /etc/auditpipe | grep xxx
# praudit /etc/auditpipe | tee file.log
# praudit /etc/auditpipe file.log
this is not work
please help me
/Vladimir Ermakov
Hi, all.
I am installed AUDIT
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html
# praudit /etc/auditpipe | grep xxx
# praudit /etc/auditpipe | tee file.log
# praudit /etc/auditpipe file.log
this is not work
please help me
/Vladimir Ermakov
Garrett Cooper wrote:
I was recently grepping a directory and outputting to a file located in
the same directory as follows:
grep -ri {key} * {key}.found
The thing is that grep kept on feeding off of the {key}.found file and
eventually ate up all the free space on the device
I was recently grepping a directory and outputting to a file located in
the same directory as follows:
grep -ri {key} * {key}.found
The thing is that grep kept on feeding off of the {key}.found file and
eventually ate up all the free space on the device (~12GB).
Thankfully it wasn't one
Garret,
Sat, Mar 17, 2007 at 02:47:43PM -0700, Garrett Cooper wrote:
I was recently grepping a directory and outputting to a file located in the
same directory as follows:
grep -ri {key} * {key}.found
The thing is that grep kept on feeding off of the {key}.found file and
eventually
Eygene Ryabinkin wrote:
Garret,
Sat, Mar 17, 2007 at 02:47:43PM -0700, Garrett Cooper wrote:
I was recently grepping a directory and outputting to a file located in the
same directory as follows:
grep -ri {key} * {key}.found
The thing is that grep kept on feeding off of the {key}.found
James Bailie wrote:
Garrett Cooper wrote:
grep -ri {key} * {key}.found
The thing is that grep kept on feeding off of the {key}.found file and
eventually ate up all the free space on the device (~12GB).
The shell is redirecting stdout onto the found file before it is
expanding the glob
Hi,
not sure that I'm in the right mailing list here, but I got myselft
the 6.1-RC1 amd64 iso yesterday and installed it.
I've got a minimum system running and just 10 minutes ago, I ran a
'grep' command and it returned an out of memory error.
The command run was:
grep -d recurse sasl
On Sat, Apr 15, 2006 at 12:16:23PM +1000, Dragos Ionita wrote:
Hi,
not sure that I'm in the right mailing list here, but I got myselft
the 6.1-RC1 amd64 iso yesterday and installed it.
I've got a minimum system running and just 10 minutes ago, I ran a
'grep' command and it returned
Hi,
It seems that OpenBSD now has BSD licensed versions of the gzip, grep and diff
families (see
http://marc.theaimsgroup.com/?l=openbsd-miscm=105899089116252w=2). Wouldn't
it be a good idea to import them into FreeBSD?
Best regards,
Arjan
On Sat, Aug 23, 2003 at 01:02:21AM +0200, Arjan van Leeuwen wrote:
Hi,
It seems that OpenBSD now has BSD licensed versions of the gzip, grep and diff
families (see
http://marc.theaimsgroup.com/?l=openbsd-miscm=105899089116252w=2). Wouldn't
it be a good idea to import them into FreeBSD
On Fri, Aug 22, 2003 at 05:03:39PM -0700, Kris Kennaway wrote:
Only if they are relatively feature-complete with respect to the GNU
code and don't have significant regressions (e.g. one of the BSDL
reimplementations of grep floating around out there performs
significantly worse than GNU grep
1 - 100 of 699 matches
Mail list logo
