5 ms·

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

rightbyte 5y ago
Ye that is what the maintainer said for the -z option for ls too.
beermonster 5y ago
I use `echo *`
- vidarh 5y ago
  `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.
  - xorcist 5y ago
    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.
    - beermonster 5y ago
      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.
    - vidarh 5y ago
      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.
traceroute66 5y ago
find or indeed, the Rust-based fd[1] which is infinitesimally faster. [1]https://github.com/sharkdp/fd https://github.com/sharkdp/fd
- vidarh 5y ago
  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.
- mellavora 5y ago
  infinitesimally https://en.wikipedia.org/wiki/Infinitesimal 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.
- CRConrad 5y ago
  s/simal// There, FTFY.
johnisgood 5y ago
Yeah. I often do "find . | grep 'foo'". Perhaps "find" can do it without the "| grep" bit, but I have not RTFM. :P
- aidenn0 5y ago
  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 "./"

rightbyte 5y ago

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

beermonster 5y ago

I use `echo *`

vidarh 5y ago
`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.
- xorcist 5y ago
  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.
  - beermonster 5y ago
    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.
  - vidarh 5y ago
    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.

traceroute66 5y ago

find or indeed, the Rust-based fd[1] which is infinitesimally faster. [1]https://github.com/sharkdp/fd https://github.com/sharkdp/fd

vidarh 5y ago
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.
mellavora 5y ago
infinitesimally https://en.wikipedia.org/wiki/Infinitesimal 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.
CRConrad 5y ago
s/simal// There, FTFY.

johnisgood 5y ago

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

aidenn0 5y ago
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 "./"