On Sat, 22 Jul 2006 09:03:20 -0400
Michael Stone <[EMAIL PROTECTED]> wrote:
> Your first problem is trying to use ls as programmatic input. It's
> really a utility intended for human readability. Try using stat,
> either with -t or --printf, or find --printf.
Thanks, but I was aware of other methods of parsing 'ls', as noted in
my report:
NB: 'ls -l' is just a familiar example -- of course there are
other ways to get file sizes that work with the current version of
'cut'; e.g. using 'ls' with other options, or utils like 'wc'. The
point is that there's always input data where there are no such
options.
While we can devise many roundabout ways to parse such output, it
would be better to do the coding once and encapsulate that function in
some utility, either a new one or an existing one well suited to it...
% whatis cut
cut (1) - remove sections from each line of files
Note the plural noun "sections" is general and doesn't specify a fixed
number of delimiters or bytes. 'man cut' uses the noun "field", which
is also general. Both nouns without qualifying adjectives are too
general, if fixed-length fields or sections were a necessary design
feature.
Adding an option to use shell-like white space fields fits in with the
"Software Tools" philosophy. Indeed, a 'tab' character, (the default
'cut' delimiter), is itself a kind of variable width field, at least
from a human readable view, in the sense that it substitutes for a
varying number of spaces, usually from 1 to 8. Conceptually, parsing
white space fields would be more like taking away an unnecessary
obstruction, (that of fixed lengths), rather than adding a new feature.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
