-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:
>>
-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 don'
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://
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 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-
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
a
Hello Eitan,
ptr is not changed in realloc (although its allocated memory region is
freed). Is it possible that hash_table_del only takes the value of ptr and
removes such an entry from the hash table? While *ptr is not accessed,
that should be fine, shouldn't it?
Regards.
2012/12/20 Eitan A
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, n
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 [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
On Tue, 2010-03-30 at 11:01 -0400, James P. Howard, II wrote:
> 2010/3/30 Dag-Erling Smørgrav :
> > Mark nesterovych writes:
> >> Decided to write BSD licensed grep and provide it to FreeBSD project if
> >> success.
> >
> > There is one already: textproc/bs
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&#x
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 it
On Tue, Mar 30, 2010 at 10:15, Mark nesterovych 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
___
f
2010/3/30 Dag-Erling Smørgrav :
> Mark nesterovych 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.
Als
Mark nesterovych 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 mailing lis
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 utiliti
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
0.02 real 0.00 user 0.00 sys
> > =>>> pcregrep
> > 0.26 real 0.21 user 0.02 sys
> > 0.26 real 0.22 user 0.02 sys
> > 0.44 real 0.35 user 0.01 sys
> > =>>
0.00 user 0.00 sys
>> =>>> pcregrep
>> 0.26 real 0.21 user 0.02 sys
>> 0.26 real 0.22 user 0.02 sys
>> 0.44 real 0.35 user 0.01 sys
>> =>>> grep
>>
er 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
base of
comparison. 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 s
sensitive comparison' is solvable, at the
very least for the simple case.
> > On i386 machines, grep -i is significantly slower:
> > i386, 7.2-STABLE of Sep 8, load averages: 0.00, 0.02, 0.00,
> > Mem: 336M Active, 442M Inact, 217M Wired, 38M Cache, 112M Buf, 198M Free
> &g
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:
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
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:
&
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 pointyh
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
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 h
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 compl
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 (until
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
A
ts to relevant resources?
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.
What regression suites do other implementations have? e.g. the GNU
textutils.
Kris
___
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
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 f
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
bin_file(FI
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 wi
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
Jaakko Heinonen escribió:
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)&
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]
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
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.
Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
__
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 proce
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 dedic
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
works, 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
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
) doesn't work? IIUC, it should convert
wide 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
--
D
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. Am
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 f
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 loc
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/nu
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://koves
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://koves
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
an
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
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 to
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 reg
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 for
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,
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
> b
t I'm not sure how hard it would be to extirpate. It
> > might 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,
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
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
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
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
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 a
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
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
http://lists.freebsd.org/mail
and ask portmgr 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 ver
which come up like this one and make
>> some tests 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 affe
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.
--
http://ache.pp.ru/
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 instrum
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 yo
=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
opti
.
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
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 / --wit
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
- I
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
- I
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
- Implemen
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)
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 -1
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 o
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 --l
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 rea
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.l
/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
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/a
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
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
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
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
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 a
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 i
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 p
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}.fo
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
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&#x
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
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
1 - 100 of 835 matches
Mail list logo
