An unholy blend of grep, sed, awk, and Python.
Project description
This is my text munging tool. There are many like it, but this one is mine.
linesieve is an unholy blend of grep, sed, awk, and Python, born out of spite.
Features
linesieve allows you to:
split text input into sections
apply filters to specific sections
search and highlight success/failure markers
match/sub/split with the full power of Python’s re
shorten paths, links and module names
chain filters into pipelines
color output!
Installing
Install and update using pip:
$ pip install --upgrade linesieve
A simple example
$ ls -1 /* | linesieve -s '.*:' show bin match ^d head -n2
.....
/bin:
dash
date
......
/sbin:
disklabel
dmesg
...
This prints the first two files starting with d from each directory whose name contains bin (skipped directories are marked with a dot on stderr).
Links
PyPI Releases: https://pypi.org/project/linesieve/
Documentation: https://linesieve.readthedocs.io/
Issue Tracker: https://github.com/lemon24/linesieve/issues
Source Code: https://github.com/lemon24/linesieve
Examples
Java tracebacks
Assume you’re writing some Java tests with JUnit, on a project that looks like this:
.
├── src
│ └── com
│ └── example
│ └── someproject
│ └── somepackage
│ └── ThingDoer.java
└── tst
└── com
└── example
└── someproject
└── somepackage
└── ThingDoerTest.java
This command:
linesieve \
span -v -X \
--start '^ (\s+) at \s ( org\.junit\. | \S+ \. reflect\.\S+\.invoke )' \
--end '^ (?! \s+ at \s )' \
--repl '\1...' \
match -v '^\s+at \S+\.(rethrowAs|translateTo)IOException' \
sub-paths --include '{src,tst}/**/*.java' --modules-skip 1 \
sub -X '^( \s+ at \s+ (?! .+ \.\. | com\.example\. ) .*? ) \( .*' '\1' \
sub -X '^( \s+ at \s+ com\.example\. .*? ) \ ~\[ .*' '\1' \
sub -X '
(?P<pre> \s+ at \s .*)
(?P<cls> \w+ )
(?P<mid> .* \( )
(?P=cls) \.java
(?P<suf> : .* )
' \
'\g<pre>\g<cls>\g<mid>\g<suf>'
… shortens this 76 line traceback:
12:34:56.789 [main] ERROR com.example.someproject.somepackage.ThingDoer - exception while notifying done listener
java.lang.RuntimeException: listener failed
at com.example.someproject.somepackage.ThingDoerTest$DummyListener.onThingDone(ThingDoerTest.java:420) ~[tests/:?]
at com.example.someproject.somepackage.ThingDoer.doThing(ThingDoer.java:69) ~[library/:?]
at com.example.otherproject.Framework.doAllTheThings(Framework.java:1066) ~[example-otherproject-2.0.jar:2.0]
at com.example.someproject.somepackage.ThingDoerTest.listenerException(ThingDoerTest.java:666) ~[tests/:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
...
... 60+ more lines of JUnit stuff we don't really care about ...
...
12:34:56.999 [main] INFO done
… to just:
12:34:56.789 [main] ERROR ..ThingDoer - exception while notifying done listener
java.lang.RuntimeException: listener failed
at ..ThingDoerTest$DummyListener.onThingDone(:420) ~[tests/:?]
at ..ThingDoer.doThing(:69) ~[library/:?]
at com.example.otherproject.Framework.doAllTheThings(:1066)
at ..ThingDoerTest.listenerException(:666) ~[tests/:?]
...
12:34:56.999 [main] INFO done
Let’s break that linesieve command down a bit:
The span gets rid of all the traceback lines coming from JUnit.
The match -v skips some usually useless lines from stack traces.
The sub-paths shortens and highlights the names of classes in the current project; com.example.someproject.somepackage.ThingDoer becomes ..ThingDoer (presumably that’s enough info to open the file).
The first sub gets rid of line numbers and JAR names for everything that is not either in the current project or in another com.example. package.
The second sub gets rid of JAR names for things in other com.example. packages.
The third sub gets rid of the source file name; ..ThingDoer.doThing(ThingDoer.java:69) becomes ..ThingDoer.doThing(:69) (the file name matches the class name).
Apache Ant output
Let’s look at why linesieve was born in the first place – cleaning up Apache Ant output.
We’ll use Ant’s own test output as an example, since it builds itself.
Running a single test with:
ant junit-single-test -Djunit.testcase=org.apache.tools.ant.ProjectTest
… produces 77 lines of output:
Buildfile: /Users/lemon/code/ant/build.xml
check-optional-packages:
prepare:
compile:
compile-jdk9+:
build:
[delete] Deleting directory /Users/lemon/code/ant/build/classes/org/apache/tools/ant/taskdefs/optional/junitlauncher/confined
... more lines
... more targets, until we get to the one that we care about
junit-single-test-only:
[junit] WARNING: multiple versions of ant detected in path for junit
[junit] file:/Users/lemon/code/ant/build/classes/org/apache/tools/ant/Project.class
[junit] and jar:file:/usr/local/Cellar/ant/1.10.12/libexec/lib/ant.jar!/org/apache/tools/ant/Project.class
[junit] Testsuite: org.apache.tools.ant.ProjectTest
[junit] Tests run: 12, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 5.635 sec
... more lines
junit-single-test:
BUILD SUCCESSFUL
Total time: 12 seconds
If this doesn’t look all that bad, try imagining what it looks like for a Serious Enterprise Project™.
Lots of output is indeed very helpful – if you’re waiting minutes for the entire test suite to run, you want all the details in there, so you can debug failures without having to run it again.
However, it’s not very helpful during development, when you only care about the thing you’re working on right now. And it’s doubly not helpful if you want to re-run the tests on each file update with something like entr.
This is where a linesieve wrapper script can help:
#!/bin/sh
linesieve \
--section '^(\S+):$' \
--success 'BUILD SUCCESSFUL' \
--failure 'BUILD FAILED' \
show junit-batch \
show junit-single-test-only \
sub-cwd \
sub-paths --include 'src/main/**/*.java' --modules-skip 2 \
sub-paths --include 'src/tests/junit/**/*.java' --modules-skip 3 \
sub -s compile '^\s+\[javac?] ' '' \
push compile \
match -v '^Compiling \d source file' \
match -v '^Ignoring source, target' \
pop \
push junit \
sub '^\s+\[junit] ?' '' \
span -v \
--start '^WARNING: multiple versions of ant' \
--end '^Testsuite:' \
match -v '^\s+at java\.\S+\.reflect\.' \
match -v '^\s+at org.junit.Assert' \
span -v \
--start '^\s+at org.junit.(runners|rules|internal)' \
--end '^(?!\s+at )' \
pop \
sub -X '^( \s+ at \s+ (?! .+ \.\. ) .*? ) \( .*' '\1' \
sub -X '
(?P<pre> \s+ at \s .*)
(?P<cls> \w+ )
(?P<mid> .* \( )
(?P=cls) \.java
(?P<suf> : .* )
' \
'\g<pre>\g<cls>\g<mid>\g<suf>' \
sub --color -X '^( \w+ (\.\w+)+ (?= :\s ))' '\1' \
sub --color -X '(FAILED)' '\1' \
read-cmd ant "$@"
You can then call this instead of ant: ant-wrapper.sh junit-single-test ....
Successful output looks like this (28 lines):
............
junit-single-test-only
Testsuite: ..ProjectTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 5.635 sec
------------- Standard Output ---------------
bar
------------- ---------------- ---------------
------------- Standard Error -----------------
bar
------------- ---------------- ---------------
Testcase: testResolveFileWithDriveLetter took 0.034 sec
SKIPPED: Not DOS or Netware
Testcase: testResolveFileWithDriveLetter took 0.036 sec
Testcase: testInputHandler took 0.007 sec
Testcase: testAddTaskDefinition took 0.179 sec
Testcase: testTaskDefinitionContainsKey took 0.002 sec
Testcase: testDuplicateTargets took 0.05 sec
Testcase: testResolveRelativeFile took 0.002 sec
Testcase: testOutputDuringMessageLoggedIsSwallowed took 0.002 sec
Testcase: testDataTypes took 0.154 sec
Testcase: testDuplicateTargetsImport took 0.086 sec
Testcase: testNullThrowableMessageLog took 0.002 sec
Testcase: testTaskDefinitionContainsValue took 0.002 sec
Testcase: testResolveFile took 0.001 sec
.
BUILD SUCCESSFUL
… “failure” output looks like this (34 lines):
............
junit-single-test-only
Testsuite: ..ProjectTest
Tests run: 12, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 5.638 sec
------------- Standard Output ---------------
bar
------------- ---------------- ---------------
------------- Standard Error -----------------
bar
------------- ---------------- ---------------
Testcase: testResolveFileWithDriveLetter took 0.033 sec
SKIPPED: Not DOS or Netware
Testcase: testResolveFileWithDriveLetter took 0.035 sec
Testcase: testInputHandler took 0.005 sec
FAILED
expected null, but was:<..DefaultInputHandler@61dc03ce>
junit.framework.AssertionFailedError: expected null, but was:<..DefaultInputHandler@61dc03ce>
at ..ProjectTest.testInputHandler(:254)
Testcase: testAddTaskDefinition took 0.182 sec
Testcase: testTaskDefinitionContainsKey took 0.003 sec
Testcase: testDuplicateTargets took 0.043 sec
Testcase: testResolveRelativeFile took 0.001 sec
Testcase: testOutputDuringMessageLoggedIsSwallowed took 0.003 sec
Testcase: testDataTypes took 0.161 sec
Testcase: testDuplicateTargetsImport took 0.088 sec
Testcase: testNullThrowableMessageLog took 0.001 sec
Testcase: testTaskDefinitionContainsValue took 0.001 sec
Testcase: testResolveFile took 0.001 sec
Test ..ProjectTest FAILED
.
BUILD SUCCESSFUL
… and true failure due to a compile error looks like this (12 lines):
...
compile
.../Project.java:65: error: cannot find symbol
public class Project implements xResourceFactory {
^
symbol: class xResourceFactory
.../Project.java:2483: error: method does not override or implement a method from a supertype
@Override
^
2 errors
BUILD FAILED
Breaking down the linesieve command (skipping the parts from the traceback example):
--section '^(S+):$' tells linesieve sections start with a word followed by a colon.
The shows hide all sections except specific ones.
--success and --failure tell linesieve to exit when encountering one of these patterns. Note that the failing section is shown regardless of show.
sub-cwd makes absolute paths in the working directory relative.
The -s compile option passed to sub applies it only to sections matching compile.
push compile applies all the following filters, until pop, only to sections matching compile.
The last two sub --color ... '1' color dotted words followed by a colon at the beginning of the line (e.g. junit.framework.AssertionFailedError:), and FAILED anywhere in the input.
Finally, read-cmd executes a command and uses its output as input.
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
File details
Details for the file linesieve-1.0.tar.gz
.
File metadata
- Download URL: linesieve-1.0.tar.gz
- Upload date:
- Size: 38.4 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/3.7.1 importlib_metadata/4.10.0 pkginfo/1.8.2 requests/2.27.1 requests-toolbelt/0.9.1 tqdm/4.62.3 CPython/3.10.8
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | 3ccfc82254f3f729898dbf3f59356a79dac763a7abd6b547951061407052c359 |
|
MD5 | 16915810813fd31e65565407d49d1f60 |
|
BLAKE2b-256 | 5afd55143a9d49987b9bc78f50aeb310965ee7f9b2280807dd7551a08328f6b7 |
File details
Details for the file linesieve-1.0-py3-none-any.whl
.
File metadata
- Download URL: linesieve-1.0-py3-none-any.whl
- Upload date:
- Size: 20.8 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/3.7.1 importlib_metadata/4.10.0 pkginfo/1.8.2 requests/2.27.1 requests-toolbelt/0.9.1 tqdm/4.62.3 CPython/3.10.8
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | ebd161affcd4581e742fcba7816716e250de7319234e2e1a001dbd9a040818cc |
|
MD5 | b4858696a0b2262f68ede40444807d4d |
|
BLAKE2b-256 | 90d75dc2fdb938ad00012a077a14b01122a768a8718288674426eef3e98d3e8f |