1. 34
  1. 11

    I feel like this is a false comparison. sed, awk, and m4 are partly overlapping tools none of which is suited to producing an ebook. curl, pandoc, and calibre are big suites of stuff that don’t conform to Unix philosophy at all. Ruby and Perl are programming languages for building whole new programs, such as one that produces an ebook.

    Maybe I shouldn’t write an ebook suite using only sed, but I’m not convinced I should replace sed with ruby.

    1. 8

      I agree with you completely. But wait, replacing sed with ruby is easier than you think! Did you know ruby has the flags -p, -n, -a, and -F to make it act like sed / awk?

      $ echo -e 'lots of words\nacross multiple lines' | awk '{print $2}'
      $ echo -e 'lots of words\nacross multiple lines' | ruby -nae 'puts $F[1]'
      $ echo 'look,a,csv,file' | awk -F, '{print $1 " " $3 "!"}'
      look csv!
      $ echo 'look,a,csv,file' | ruby -na -F, -e 'puts "#{$F[0]} #{$F[2]}!"'
      look csv!

      It even supports BEGIN { ... } and END { ... } blocks like awk does.

      While -n acts most like awk, -p gets you the full sed experience:

      $ echo 'some string' | sed 's/s/z/g'
      zome ztring
      $ echo 'some string' | ruby -pe '$_.gsub!("s", "z")'
      zome ztring

      Just like -n, but it causes ruby to print $_ (the magic global for “last line read by gets”) after every iteration!

      Full disclosure: I have never actually used this. I like awk.

      1. 2

        Yes this is a bit of a strange comparison, but while we are at: anyone who wants to do digital publishing beyond compiling templates with pandoc should take a look at Pollen

      2. 5

        I mean, it worked for authors producing UNIX books that went to press. They even used made diagrams and typeset formulae. What made it so hard to generate an ebook?

        1. 4

          To be fair, UNIX has fragmented to a degree where tools do not always work as expected (GNU vs BSD vs Darwin, etc.), however those authors presumably used roff not sed.

        2. 5

          This feels like a useful counterpoint to me. The Unix-y CLI tools and their ability to be chained together can be very useful sometimes. But chaining too many together in too elaborate ways tends to run into weird issues, to the point where it becomes easier to use a programming language or all-in-one application where things are more likely to work together smoothly.

          1. 3

            Definitely. I personally find it disappointing that it’s such a struggle for programmers to accept that there is a spectrum of tools. Each one has a trade-off and I would expect this community to prefer those of Unix-y CLI tools for personal use. At the same time, a not insignificant number of people here may be using those same tools to build software at the other end of the spectrum for other sets of users.

            I personally find it joy to introduce users of a monolith, that’s not quite right for them, to the subset of tools that solves their problem exactly. That’s a very satisfying experience and then they often go off and apply these to other problems and replace the inappropriate monoliths. It’s healthy if it goes both ways and people get what they need to make their lives better.

          2. 1

            And big, complex tools can explode, cut your arm off and crush you. ;)