Hacker News new | ask | show | jobs
by exprx 3755 days ago
The mentioned blog post is horribly ignorant, and lacks almost any valid points.

find, in particular, very much has a fine UI, and I dare you to process, and not just list, the files with cmd.

4 comments

> find, in particular, very much has a fine UI, and I dare you to process, and not just list, the files with cmd.

I'm not really sure why he is comparing find with cmd in the first place. Nobody thinks cmd is good; most anybody actually doing anything in a shell on Windows would be doing it in Powershell.

In that case, I would do something like:

Get-ChildItem pathname -Filter test.txt -Recurse

Any processing I want to do is easy, because I'm getting back objects and not just text. Say that I want to get a hash of each file named test.txt.

Get-ChildItem C:\Users\Amezarak -Filter test.txt -Recurse | Get-FileHash

Nuno Brito, blog post author here.

Let's make a little test. You pick ten Linux users on the next FOSDEM and ask them how to find a file on a subfolder. This will be called the "brito test".

If only 2 people don't know the answer, you are correct and simplifying the command line is not really needed.

If 5 of them don't know how do it, they will be branded as "horribly ignorant" Linux users.

If 8 of those people fail, we keep closing our eyes and repeating that everything is OK.

If 10 out of 10 people that you ask are failing this question. Well, time to ask another 10 until you get a positive ratio of non-horribly-ignorant answers.. ;-)

And btw, the blog is about design of future (upcoming) command line tools and not about changing "ls" or any of the other example given. For example, thinking about the most used function of a tool and making that as simple as possible to reach.

I do like find's UI as well.

As an aside, I remember reading an article about how "the original Unix guys" found the syntax somewhat odd when find came about. But the command was useful enough that they kept it.

(The article was about how inconsistent the Unix commands are regarding syntax, and I think its conclusion was that it is much more important to design syntax to fit the problem than to maintain a superficial consistency with other commands).

    for /r "C:\some path" %F in (*.exe) do process "%F"
forfiles also exists, which works similar to find regarding passing the list of files to another command.
ls -Recurse -Include "*exe" $PATH | % { something $_}
Use -Filter instead of -Include unless you need fancy wildcards. It's much faster because it gets passed to the FileSystem provider and filtering is applied at that level already.