Philip Ganchev wrote: > > > cut -f 3,5-+3 myfile > > > > How about: > > > > perl -F'\t' -nae 'print join "\t", @F[2,4..$#F-3]' myfile > > Even more verbose and complicated (clumsy).
Your original cut example requires forking four external binaries and one shell builtin, and involves at least two subshells. To me, that is a lot more complicated (in terms of both syscalls and points of failure) than just running a single perl (or awk) command with no subshells. > Plus, it depends on > having Perl, which is not a coreutil as far as I know. You're asking for a feature that currently does not exist in 'cut' to be added. Do you realize how long it will take before you could count on being able to use this feature in a portable script? Even if the feature was added today I bet that you would find many systems in three years from now that are still running an out of date coreutils that would not support that feature. Just look at all the people that post to this list that are still using coreutils 5.2x or even its predecessors, textutils/fileutils/sh-utils. And on systems that use the vendor 'cut' instead of GNU 'cut', the feature will essentially never be available. On the other hand, a unix-like system that is not an embedded device that does not have perl (or awk) installed is pretty rare. So if the question is availability or portability of a particular feature, to me it looks like there is no contest. > going to use Perl, why do we need "cut" at all? It is just sensical > that if a command allows you to cut from the beginning, it will let > you cut from the end. I agree that it sounds like a logical idea, but the problem comes when you try to add features to programs like 'cut' that have existed for probably decades and that are standardized by IEEE/POSIX, and have multiple implementations (i.e. not everybody uses GNU cut.) Any features you add become GNU extensions, and can't be used in anything but private scripts that you don't ever intend to distribute to anyone since there's a very low chance they will work on other people's systems. Brian _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
