Hacker News Reader

Comment by tills13 | Hacker News Reader

I'd say this is a situation where you should use a tool that's appropriate for the job.

Listing 70k files without greping or piping into another process is something you are probably not going to ever do. exa seems very good for the average case.

View on HN

I'm not sure I'm following. Listing 70k files was a benchmark. It would take you 10x the time to use 'exa | grep' but grep might just filter out the item you're looking for during execution (not certain if grep is reading the pipe as it is output or waits for execution to complete first). exa still needs 7 seconds to check all files. ls only needed a tenth of that

I'm saying you would use `ls | grep ...` in situations where you're transforming the output but use `exa` when you specifically care about the files or their metadata.

That is, use ls when you you don't care about the direct output of the list file command, use exa when you do.

I agree with your point but most things you might want "ls|grep" for is better done with "find" which can do both in one.

Or indeed ‘fd’, which is a find replacement with nicer search syntax.

Sure. Use what you know and what you're comfortable with.

> (not certain if grep is reading the pipe as it is output or waits for execution to complete first)

Commands to the left of the pipe block upon writing to the pipe, and commands to the right of the pipe block upon reading. As something is written to the pipe, it gets read by the next process in the pipeline.

Data flows through Unix pipelines as it is written, and data flow is not dependent on completed execution.

The point is that exa is a tool for listing files in a more human readable way. In what situation would you ever need to manually read (with your eyes) a list of 70k files? For this use case you should just use ls.

Reply on news.ycombinator.com