in reply to Unix shell ls vs readdir

Aside from being all Perl, is there any other reason to use the "readdir" option over the "ls" option?

EDIT: Just realized that there is a slim chance in the "ls" option of getting a bad element on the list. Because I'm only parsing ls output, a funny file name could mess up that parsing. Whereas with the "readdir" option, I'm certain of what I'm getting. That's actually a very good reason to stick with the all Perl "readdir" option.

Right. Apart from the fact that "ls" might behave with minor but annoying differences on different systems, it's generally trickier / less reliable to parse its text output than to pull file names via direct-access to directory entries using readdir (and link target names via direct-access to symlinks using readlink).

I have seen file names on unix systems with non-ascii characters and ascii control characters (including line-feed, carriage-return, etc), all of which can be very disorienting when viewed via "ls".

Replies are listed 'Best First'.
Re^2: Unix shell ls vs readdir
by Anonymous Monk on Feb 06, 2012 at 12:06 UTC

    so what do you think ? in terms of reading the 2Lac of files which one is better in performance ? ls or readdir ?

[reply]
      I don't know what "the 2Lac of files" is supposed to mean, and "performance" is either too dependent on unknown factors, or else simply irrelevant. Enough practical reasons have been cited to favor the readdir/readlink approach (ease and reliability of file name handling, vs. somewhat more difficult and trouble-prone string parsing), and in some circumstances, running a subshell to run "ls" could be slower than using readdir/readlink.

      If a timing difference between the two methods really matters (which is rarely true), then doing a benchmark "in context" (i.e. under the same conditions as production use) would be prudent.

[reply]
[reply]

In Section Seekers of Perl Wisdom