Discussion:
bug#29604: man cut should mention no way to do ls -l|cut ...
(too old to reply)
積丹尼 Dan Jacobson
2017-12-07 09:37:10 UTC
Permalink
On (info "(coreutils) cut invocation")

‘-d INPUT_DELIM_BYTE’
‘--delimiter=INPUT_DELIM_BYTE’
With ‘-f’, use the first byte of INPUT_DELIM_BYTE as the input
fields separator (default is TAB).

please mention there is no way to indicate more than one character,
thus no way to process
$ ls -l | cut ...
and that one should use awk, etc. for that.

Also mention it on the cut(1) man page.
Eric Blake
2017-12-07 15:46:44 UTC
Permalink
Post by 積丹尼 Dan Jacobson
thus no way to process
$ ls -l | cut ...
and that one should use awk, etc. for that.
Let's step back a bit. We recommend that you NEVER parse ls output, as
it is inherently ambiguous and difficult to parse. MUCH better is to use
stat instead of ls, at which point you can get directly at the
information you want without having to post-process potentially
ambiguous output. If anything, added documents should point people to
stat, not to bad ways of parsing ls.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
積丹尼 Dan Jacobson
2017-12-07 15:53:36 UTC
Permalink
EB> Let's step back a bit. We recommend that you NEVER parse ls output, as

No problem. Any example of what can't be parsed would be fine. Even e.g.,

EB> Eric Blake, Principal Software Engineer
EB> Red Hat, Inc. +1-919-301-3266
EB> Virtualization: qemu.org | libvirt.org

your signature, with differing lengths of whitespace. Whatever.
Assaf Gordon
2018-10-30 02:18:20 UTC
Permalink
severity 29604 wishlist
retitle 29604 wontfix
close 29604
stop

(triaging old bugs)
Post by 積丹尼 Dan Jacobson
EB> Let's step back a bit. We recommend that you NEVER parse ls output, as
No problem. [...]
Closing this bug.

-assaf

Loading...