Hacker News Reader

Hacker News

Comment by spicybright | Hacker News Reader

Parent Full thread

spicybright

I think the point is ls has so many options, it's not safe to parse as is.

I always use `find .` if I need a list of files from a directory for this reason

View on HN

find or indeed, the Rust-based fd[1] which is infinitesimally faster.

[1]https://github.com/sharkdp/fd

If you're listing just the filenames, the things that makes fd fast (the parallelised directory traversal when you do something that requires stat calls or similar) are irrelevant, as the getdents() calls are going to be more affected by your buffer size.

So for the limited subset of tasks where you're ok with using a tool that might not be installed and need options that requires stat calls and the directories may be large enough, it might make a difference.

infinitesimally

https://en.wikipedia.org/wiki/Infinitesimal

"In mathematics, an infinitesimal or infinitesimal number is a quantity that is closer to zero than any standard real number, but that is not zero."

I'll blame this one on auto-correct.

   s/simal//

There, FTFY.

Yeah. I often do "find . | grep 'foo'". Perhaps "find" can do it without the "| grep" bit, but I have not RTFM. :P

You probably want -name or -iname which match glob-like expressions against the filename (the "i" prefix means case insensitive).

If you really need regex you can use -regex or -iregex, but be aware that they match the entire path (so if you do "find ." you will be matching a string that starts with "./"

Ye that is what the maintainer said for the -z option for ls too.

I use `echo *`

`echo *` has many of the downsides of ls (doesn't escape e.g. space in filenames) and additionally breaks on directories where the expansion fills the command line buffer.

EDIT: Also note that "find ..." is also not safe from all the quoting issues without "-print0" or equivalent options to make it separate the names with ASCII NUL rather than linefeed or otherwise taking steps to handle filenames with actual linefeeds in them.

Indeed. Those backticks only works in a shell, but in a shell why not just write

which is how filename expansion is supposed to work.

The back ticks were supposed to be quotes, I meant to say

echo *

However as per replies, this suffers from the same issues as ls.

The problem is not the backticks. They were just used as quote characters. The problem is that shell expansion doesn't escape the characters. E.g. this is a cut down output from my system now after I did a echo >'/tmp/ space ':

    $ echo /tmp/*
    /tmp/bspwm_0_0-socket /tmp/config-err-Q667kI /tmp/foolog /tmp/ space  /tmp/...

Parse that output and you get a broken list of filenames.

Reply on news.ycombinator.com