Hacker News Reader

Comment by rmetzler | Hacker News Reader

I wish there was a short and simple command for “list all files of a directory and no subdirectories“. ls doesn’t seem to have a switch for that kind of functionality.

It’s discussed on stack-overflow. [0]

Someone even wrote a nodejs tool for this functionality [1], but I would rather have something written in a compiled language.

[0]: https://stackoverflow.com/questions/10574794/how-to-list-onl...

[1]: https://github.com/mklement0/fls

View on HN

But the top answer has it:

> find . -maxdepth 1 -type f

A little clunky, but there's certainly no need to mess about in JavaScript land. If you use it often, create a shell macro.

find doesn't return the same output as ls when run on another directory. Maybe there is a switch to do this? I'm not sure.

    $ mkdir -p tmp && touch tmp/a tmp/b tmp/c
    
    $ find ./tmp -maxdepth 1 -type f
    ./tmp/a
    ./tmp/c
    ./tmp/b
    
    $ ls -1 ./tmp 
    a
    b
    c

The -ls flag to find prints the same as ls

not quite.

from the man page:

> The format is identical to that produced by ``ls -dgils''.

I think this is what you are looking for

    $ find ./tmp -maxdepth 1 -type f -printf '%f\n'

I'm on MacOS... :-/

   $ find ./tmp -maxdepth 1 -type f -printf '%f\n'
   find: -printf: unknown primary or operator

If you use brew or macports you can install the coreutils package and then you're good to go with gnu find.

I also use MacOS and I have setup the gnu userland on my local so it matches the linux environment on our servers and containers.

You’re right that defaulting to the GNU coreutils is probably more convenient. However, NOT doing this is a good way to ensure that any scripts you write remain portable and don’t use GNU extensions. That’s the reason I stick with the default BSD coreutils on macOS.

> You’re right that defaulting to the GNU coreutils is probably more convenient.

It's not about convenience. It is about having a development environment that matches the target runtime environment.

You can run into nasty surprises when the default behavior of a tool in your dev environment is different than in your production environment.

I've been writing shell scripts professionally for over 20 years and I have always taken this approach and it has served me well.

You could also try restricting yourself to POSIX shell.

find <directory path> -type f -d 1

Works for me on OSX.

Not got a shell handy, but "-exec ls"?

    +   $ find /tmp/x ! -path /tmp/x -prune -type f -exec sh -c 'for p; do printf '\''%s\n'\'' "${p##*/}"; done' - {} +
    c
    b
    a

Seems to do the trick and is POSIX only (so works on busybox and mac). You can probably just tack `| sort` at the end if you want it sorted.

This answer reminds me of the classic HN comment - why use Dropbox when "you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software."

People value software that's easy to use. That command you typed is a Frankenstein's monster.

https://news.ycombinator.com/item?id=9224

This had become a discussion of the best way to write the "shell macro" version that could replace the node.js program

  fls () {
   find . -maxdepth 1 -type f
  }

  fls () {
   find . ! -path . -prune \
    -type f \ 
    -exec sh -c 'for p; do printf '\''%s\n'\'' "${p##*/}"; done' - {} +
  }

The user would just type `fls` in the directory they were exploring.

You can run it in a subshell pretty easily, like this:

    $ (cd tmp && find . -maxdepth 1 -type f)

You can also use basename with the find command

    $ find ./tmp -maxdepth 1 -type f -exec basename {} \;
    b
    a
    c

I don't know the downsides of using basename though.

from all the solutions, this seems to be the most simple with readily available tools. Unfortunately it's still not as short as I would like it to be and I hope I remember the syntax with -exec $CMD {} \; the next time I need it.

Thanks to all the helpers, who took their time to propose solutions.

But what I was trying to say is: I would be ok with adding a new command to the tools I use on my machine, VMs and containers. fzf, fd, rg are tools which make my life easier. I would prefer to have the features of fls in ls itself or a tool similar to fls in coreutils, moreutils or another package .

List all files and no directories :

  ls -1p | grep -v '/$'

You may wrap it in an alias or .bashrc function. I use the reverse (list only directories):

     function lsd {
         ls -1p $* | grep '/$'
     }

The are two main responses to this comment as I write this. One of them lists only regular files. One of them lists anything that isn't a directory. And that's why there isn't a short and simple command.

ah, yes, the simple test only had files, no symlinks, hidden files, etc, anything else you might want to distinguish upon in a shell script.

But I don't think it's too hard to solve this problem. A command which filters should also be able to invert the filter. One example for this is grep -v.

> Someone even wrote a nodejs tool for this functionality

Coming from a more low level background but doing front end development from time to time, I am always amazed by the sheer amount of seemingly useless javascript reimplementations of what would be bash one liners.

For your question, how about "find <dir> -type f - maxdepth 1" ?

You can put that in an alias or script in your path

Try submitting a pr to exa. Probably the fastest way to get it solved properly.

Thanks for mentioning exa. I saw it before, but never tried it. Maybe this is an opportunity to learn Rust.

Couldn't you just alias the find command mentioned in the SO thread?

Just curious, how is `find . -maxdepth 1 -type f` not simple?

The output is different between find and ls when you run it on another directory.

ls *(.) if you use zsh.

Technically the request was for ls *(^/) in Zsh-ese.

Reply on news.ycombinator.com