You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Scott Stirling <sc...@rcn.com> on 2002/12/02 07:05:37 UTC
FilterChains - grep and sed
Seems like sed and grep could be implemented as filterreaders (see
<http://jakarta.apache.org/ant/manual/CoreTypes/filterchain.html>). The
LineContainsRegExp filterreader is already a solid foundation for grep. A
little more implementation and a few params to support flags for inverse
matching, number of before/after lines of context, ignore-case, etc. and
you'd have 90% of grep.
A little sed "engine" would be a little harder but could also be done. How
would you do it? You could pass sed one-liners as param values, or set a
param value to the name of a file to read in with a sed script. Hmmm.
Scott Stirling
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: FilterChains - grep and sed
Posted by Scott Stirling <sc...@rcn.com>.
Continuing in this thought of using FilterChains to implement sed, grep, tr,
etc. . . . I've been thinking about it between other tasks, and tonight I
sat and looked at the existing filter chains and the ORO library.
I don't know if it's allowed to have something like jakarta-oro be a
dependency in the core tasks, types, etc. But if that library was allowed
in there, several of the existing built-in FilterReaders could be eliminated
(if desired), in place of a more flexible, general purpose way of performing
pattern-based file stream transformations.
LineContains, LineContainsRegExp, ReplaceTokens, StripLineBreaks,
StripLineComments, TabsToSpaces can be thought of as a small library of
fixed substitutions or transformations. In UNIX these could all be done
with grep, sed or tr (in more than one way), for example:
LineContains = grep string file
LineContainsRegExp = grep 'regex' file
ReplaceTokens = sed 's/pattern/value/g' file
StripLineBreaks = tr -d '\r\n' < file
StripLineComments = sed '/pattern/d' file
TabsToSpaces = tr '\t' ' ' < file
The Jakarta ORO library provides a very graceful API for matching and
replacing patterns. It's flexibility would make the whole FilterChain
concept extremely extensible and flexible with minimal code writing. My
only question at this point is how much trouble it would be to use it in the
context of a FilterReader's read() method, where everything is based on
reading a line and returning ints, one character at a time.
Scott Stirling
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FilterChains - grep and sed
Posted by Magesh Umasankar <um...@apache.org>.
----- Original Message -----
From: "Scott Stirling" <sc...@rcn.com>
> Seems like sed and grep could be implemented as filterreaders (see
> <http://jakarta.apache.org/ant/manual/CoreTypes/filterchain.html>). The
> LineContainsRegExp filterreader is already a solid foundation for grep. A
> little more implementation and a few params to support flags for inverse
> matching, number of before/after lines of context, ignore-case, etc. and
> you'd have 90% of grep.
+1
>
> A little sed "engine" would be a little harder but could also be done.
How
> would you do it? You could pass sed one-liners as param values, or set a
> param value to the name of a file to read in with a sed script. Hmmm.
Interesting thought.
>
> Scott Stirling
>
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Unknown Source in Stack Trace
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
<javac debug="true"....>
Affan Qureshi wrote:
> The stack trace I get while running on tomcat shows (Unknown Source) in the
> place where it should show the line no of the file where the error has
> occured. My javac task simply compiles my source to the WEB-INF/classes dir.
> Do i need to generate source files om that path to get the line nos instead
> of Unknown Source? If yes how can I do that?
>
> Thanks a lot.
>
> Affan
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: Unknown Source in Stack Trace
Posted by Ilja Preuss <pr...@disy.net>.
> The stack trace I get while running on tomcat shows (Unknown
> Source) in the
> place where it should show the line no of the file where the error has
> occured. My javac task simply compiles my source to the
> WEB-INF/classes dir.
> Do i need to generate source files om that path to get the line
> nos instead
> of Unknown Source? If yes how can I do that?
Use debug="on" in the javac target. Including debug information is
deactivated per default.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Unknown Source in Stack Trace
Posted by Affan Qureshi <qu...@etilize.com>.
The stack trace I get while running on tomcat shows (Unknown Source) in the
place where it should show the line no of the file where the error has
occured. My javac task simply compiles my source to the WEB-INF/classes dir.
Do i need to generate source files om that path to get the line nos instead
of Unknown Source? If yes how can I do that?
Thanks a lot.
Affan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: FilterChains - grep and sed
Posted by Scott Stirling <sc...@rcn.com>.
> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
[...]
> why not create FilterReaders around the
> Perl5Tools, AwkTools, etc. in Jakarta ORO?
After seeing your first post mentioning Jakarta ORO I checked it out. Seems
like a good idea. Note: according to the latest ORO docs, AwkTools and
PerlTools are now org.apache.oro.text.awk.* and org.apache.oro.text.perl.*.
org.apache.oro.text.perl.Perl5Util would give us these PERL features:
- [m]/pattern/[i][m][s][x]
- s/pattern/replacement/[g][i][m][o][s][x]
- split()
org.apache.oro.text.awk.AwkStreamInput and
org.apache.oro.text.awk.AwkMatcher would give us awk-like functionality, but
not sure to what extent.
Looks like the Perl5Util would be great for some basic sed emulation.
Scott Stirling
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FilterChains - grep and sed
Posted by Matt Benson <gu...@yahoo.com>.
Good point. I got caught up in the term "filter" and
didn't consider the situations when the effect of the
filter was a transformation. That is the kind of
thing I was looking for, an example of filter behavior
that would be impossible to intelligently invert.
Until now I have been unsure whether the class could
be written. Inverting a removal filter would be
complex but intelligent results probably could be
achieved. I was thinking along the lines of grep and
grep -v when I came up with this. On the other hand,
transformations would probably not yield output
comparable to the input and thus would probably result
in nothing but garbage when inverted. Consider that
matter dropped, then.
Now to have holes shot in my other suggestion: why
not create FilterReaders around the Perl5Tools,
AwkTools, etc. in Jakarta ORO?
-Matt
--- Stefan Moebius <st...@yahoo.com> wrote:
> Does this make sense for anything but removal
> filters? How would you
> expect the inverse of a "replace foo by bar" filter
> to work?
>
> Stefan
>
> --- Matt Benson <gu...@yahoo.com> wrote:
> > An InverseFilterReader would do exactly the
> opposite
> > of a specified FilterReader. For example, the
> > StripJavaComments FilterReader in Ant strips away
> Java
> > comments. An InverseFilterReader wrapping a
> > StripJavaComments FilterReader would strip away
> > everything BUT Java comments. I think
> implementation
> > might be any of tricky, slow, or memory-intensive,
> but
> > the number of existing FilterReaders would be
> > instantly doubled if this class were written.
> >
> > -Matt
> >
> >
> > --- Magesh Umasankar <um...@apache.org> wrote:
> > > ----- Original Message -----
> > > From: "Matt Benson" <gu...@yahoo.com>
> > >
> > >
> > > > Nice thought here--why not adapt the various
> > > angles of
> > > > Jakarta ORO as FilterReaders? Another class I
> > > have
> > > > thought of writing for quite some time, but
> whose
> > > > implementation would be quite tricky, is an
> > > > InverseFilterReader which would perform the
> > > opposite
> > > > of a contained FilterReader.
> > >
> > > I don't quite follow - will you please expand
> > > on what you propose as an InverseFilterReader?
> > >
> > > >
> > > > -Matt
> > >
> > > Cheers,
> > > Magesh
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up
> now.
> > http://mailplus.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> =====
> Stefan Moebius <st...@yahoo.com>
> Wurzener Str. 43 +49 351 8475827
> 01127 Dresden +49 172 8739617
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up
> now.
> http://mailplus.yahoo.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FilterChains - grep and sed
Posted by Stefan Moebius <st...@yahoo.com>.
Does this make sense for anything but removal filters? How would you
expect the inverse of a "replace foo by bar" filter to work?
Stefan
--- Matt Benson <gu...@yahoo.com> wrote:
> An InverseFilterReader would do exactly the opposite
> of a specified FilterReader. For example, the
> StripJavaComments FilterReader in Ant strips away Java
> comments. An InverseFilterReader wrapping a
> StripJavaComments FilterReader would strip away
> everything BUT Java comments. I think implementation
> might be any of tricky, slow, or memory-intensive, but
> the number of existing FilterReaders would be
> instantly doubled if this class were written.
>
> -Matt
>
>
> --- Magesh Umasankar <um...@apache.org> wrote:
> > ----- Original Message -----
> > From: "Matt Benson" <gu...@yahoo.com>
> >
> >
> > > Nice thought here--why not adapt the various
> > angles of
> > > Jakarta ORO as FilterReaders? Another class I
> > have
> > > thought of writing for quite some time, but whose
> > > implementation would be quite tricky, is an
> > > InverseFilterReader which would perform the
> > opposite
> > > of a contained FilterReader.
> >
> > I don't quite follow - will you please expand
> > on what you propose as an InverseFilterReader?
> >
> > >
> > > -Matt
> >
> > Cheers,
> > Magesh
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
Stefan Moebius <st...@yahoo.com>
Wurzener Str. 43 +49 351 8475827
01127 Dresden +49 172 8739617
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FilterChains - grep and sed
Posted by Matt Benson <gu...@yahoo.com>.
An InverseFilterReader would do exactly the opposite
of a specified FilterReader. For example, the
StripJavaComments FilterReader in Ant strips away Java
comments. An InverseFilterReader wrapping a
StripJavaComments FilterReader would strip away
everything BUT Java comments. I think implementation
might be any of tricky, slow, or memory-intensive, but
the number of existing FilterReaders would be
instantly doubled if this class were written.
-Matt
--- Magesh Umasankar <um...@apache.org> wrote:
> ----- Original Message -----
> From: "Matt Benson" <gu...@yahoo.com>
>
>
> > Nice thought here--why not adapt the various
> angles of
> > Jakarta ORO as FilterReaders? Another class I
> have
> > thought of writing for quite some time, but whose
> > implementation would be quite tricky, is an
> > InverseFilterReader which would perform the
> opposite
> > of a contained FilterReader.
>
> I don't quite follow - will you please expand
> on what you propose as an InverseFilterReader?
>
> >
> > -Matt
>
> Cheers,
> Magesh
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FilterChains - grep and sed
Posted by Magesh Umasankar <um...@apache.org>.
----- Original Message -----
From: "Matt Benson" <gu...@yahoo.com>
> Nice thought here--why not adapt the various angles of
> Jakarta ORO as FilterReaders? Another class I have
> thought of writing for quite some time, but whose
> implementation would be quite tricky, is an
> InverseFilterReader which would perform the opposite
> of a contained FilterReader.
I don't quite follow - will you please expand
on what you propose as an InverseFilterReader?
>
> -Matt
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FilterChains - grep and sed
Posted by Matt Benson <gu...@yahoo.com>.
Nice thought here--why not adapt the various angles of
Jakarta ORO as FilterReaders? Another class I have
thought of writing for quite some time, but whose
implementation would be quite tricky, is an
InverseFilterReader which would perform the opposite
of a contained FilterReader. I couldn't think how to
sensibly do it, however. Does anyone else have any
ideas?
-Matt
--- Scott Stirling <sc...@rcn.com> wrote:
> Seems like sed and grep could be implemented as
> filterreaders (see
>
<http://jakarta.apache.org/ant/manual/CoreTypes/filterchain.html>).
> The
> LineContainsRegExp filterreader is already a solid
> foundation for grep. A
> little more implementation and a few params to
> support flags for inverse
> matching, number of before/after lines of context,
> ignore-case, etc. and
> you'd have 90% of grep.
>
> A little sed "engine" would be a little harder but
> could also be done. How
> would you do it? You could pass sed one-liners as
> param values, or set a
> param value to the name of a file to read in with a
> sed script. Hmmm.
>
> Scott Stirling
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>