Marc H. wrote:
Why re-invent the wheel?
Because your wheel will not work on i.e. Windows without the “tail”
binary, but the ruby wheel will work wherever ruby works.
Sure. But if this particular poster is running under Linux, or cygwin,
or MacOS X, then the
tail solution is (a) dead quick to write, and (b)
already highly optimised. As has been pointed out, the algorithm for
doing tail efficiently is not as easy as it might first appear.
If the OP is not writing this code for his personal use, but in a
library which must be as widely portable as possible, then of course a
pure Ruby solution is going to be beneficial. But in that case, he may
wish to consider releasing the tail algorithm as a standalone library.
The whole modularity of Unix tools has also led to shell scripts, which
are just plain UGLY and a mess to maintain, especially the more
complicated they grow (which is only less true for ruby scripts, because
maintaining even complicated ruby scripts is a lot easier IMHO)
I agree: fork/exec, argv, env and stdin/stdout are a fairly lousy API,
Use the better wheel.
The tail wheel in gnu coreutils is a highly polished, aerodynamic and