That manual is possibly the single most useful technical document that I have ever read. It has enabled me to write extremely powerful programs that no one I know can understand.
It would however be nice to have a tool with similar power but simpler, more comprehensible syntax. One of the other commenters linked to an interesting document on sam, which has a better control flow but equally arcane syntax.
I think I could argue that Perl is that tool. I'm not looking forward to people chiming in about the syntax that have little to no experience with it though.
I fell in love with Perl 3 over twenty years ago and loved how it took the best parts of both awk and sed and added extra features while making the overall syntax more consistent. Ironically, the consistency of Perl's syntax in those days (vs having to remember awk, sed, and other somewhat overlapping tools, each with its own awkward syntax) made it an amazingly convenient super-tool for stream processing. Perl 4 came along almost immediately, and I couldn't believe how powerful those little "Perl one-liners" could be.
With Perl 5, Perl essentially repositioned itself as a full-blown, general-purpose programming language, with all the power that entailed, but still stuck with a syntax based on essentially trying to be a more powerful and consistent superset of sed and awk.
These days, I think we could do a lot better with a stream processor with the stream-processing focus and one-liner power of Perl 4 but without the needless (these days) constraint of retaining the syntactic hash of ancient unix utilities.
Perl indeed. I know there are a lot of modern compilers out there, but speaking about parsing files I think perl suits me the most in terms of code readability/speed balance.
Well, sorry but sed _is_ cryptic.
Let me quote an exemple for you (squeezing blank lines):
>leaves a blank line at the beginning and end if there are some already.
#!/usr/bin/sed -f
# on empty lines, join with next
# Note there is a star in the regexp
:x
/^\n*$/ {
N
bx
}
# now, squeeze all '\n', this can be also done by:
# s/^\(\n\)*/\1/
s/\n*/\
/
As soon as you begin to use sed registers, the code becomes arcanic.
> I think that stream-oriented languages are doomed to have an arcanic syntax.
> Streams are a non-trivial construction, after all.
...
> Well, sorry but sed _is_ cryptic. Let me quote an exemple for you (squeezing blank lines):
I agree with you that sed is cryptic, but I don't think that that necessarily means that stream processing languages are doomed to have an archaic syntax. I'd also agree with marvy in saying that the car and house example is very clear as to it's intent:
STDIN | /\w+/{|word|
/house/ {
# when word is house
}
/car/ {
# when word is car
}
{
# default case
}
}
I'd say that's very straightforward and not arcane at all. Just because sed is arcane (it could be argued) doesn't make it a precondition for any stream language
It would however be nice to have a tool with similar power but simpler, more comprehensible syntax. One of the other commenters linked to an interesting document on sam, which has a better control flow but equally arcane syntax.