Source: srek
Section: utils
Maintainer: Nikolas Fischer Soley <niksoley@gmail.com>
Build-Depends:
 debhelper-compat (= 13),
 python3 <!nocheck>,
 python3-colorama <!nocheck>,
 valgrind [amd64 arm64 armhf i386 ppc64 ppc64el riscv64 s390x] <!nocheck>
Standards-Version: 4.7.4
Homepage: https://github.com/Seeker04/srek
Vcs-Browser: https://salsa.debian.org/niksoley/srek
Vcs-Git: https://salsa.debian.org/niksoley/srek.git

Package: srek
Architecture: any
Depends:
 ${shlibs:Depends},
 ${misc:Depends},
Description: Text processing and manipulation language, similar to sed
 What differentiates it from sed and most Unix tools: it does not presume that
 the input is structured in lines. Instead, with commands like x, the user can
 define the input's structure in an arbitrary way. For example, x/"[^"]*"/p
 will extract and print all quoted text from the input. A quoted part may be
 contained in a line without spanning the entire line; or it may begin and end
 on different lines. A similar regex can be used to extract parenthesized parts,
 or texts between certain XML tags. Note that a lot of file formats (JSON, XML,
 C sources, etc.) are forgiving about whitespaces, so whatever is wished to work
 on can be contained within or span multiple lines. Standard Unix tools like
 grep, sed or awk are all line based and thus not well suited for these
 problems.
 The above example: x/"[^"]*"/p would be really cumbersome to implement with any
 of these tools.
 The structural regex approach is more general, because it can easily simulate
 what line based tools do. All we need is an extraction like: x/[^\n]*\n/
 (there is an alias command for this: L). For example, for grep 'pattern' the
 equivalent is srek 'x/[^\n]*\n/ g/pattern/ p' or in shorter:
 srek 'Lg/pattern/'.
 Extractions may be refined by consecutive x commands, for example:
 srek 'x/"[^"]*"/ x/[a-zA-Z]+/ a/\n/' will first select all quoted text,
 then it will select all words within them and finally, print them each in
 a new line.
 What's it not suited for?
 srek is not ideal for processing continuous, "infinite", input like a lot of
 Unix tools (grep, sed, etc.), because it needs to read the whole input before
 processing it. As a result, processing a 1 GB file will require roughly 1 GB
 memory.
