Hacker News Reader

Comment by wbl | Hacker News Reader

The problem with find is that it tries to put an entire programing language into its arguments.

Is that a problem? A simple tool is good if it can solve complex problems, but a simple tool that can't is just an underdeveloped tool. Sometimes you need a complex tool to solve a complex problem.

I think a good mini language bridges the gap between interactive commands and programming. Sometimes you need to spend an hour writing a program to do something complicated. But because of various "extraneous features" built into UNIX commands, you rarely need to spend an hour manually poking at the filesystem. The mini language gets you almost as productive as a full-fledged programming language, without feeling like you're programming. (How do you know you're programming? If you "git init" and start committing stuff, you're probably programming. If your carefully-crafted thing scrolls into .history obscurity, then you're interacting.)

Find is not simple - it's easy, but internally complex. It's fine to solve a complex problem with a complex tool, but it's troublesome when people mostly use it to solve simple problems. And the trouble is that this kind of approach spreads to every single component in the system, which means that we're using insane amount of code and cpu load to solve really simple problems on daily basis.

Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.

…we're using insane amount of code and cpu load to solve really simple problems on daily basis.

Piping programs together is almost always going to use significantly more resources than one program doing it all. More code doesn’t necessarily imply more resource usage.

Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.

I don’t want to be all around negative about plan 9, but I don’t see it as really solving any interesting problems. Indeed it is far easier to write slim, elegant systems when forgoing feature parity and/or competitive performance.

> More code doesn’t necessarily imply more resource usage.

That's true! Yet, somehow we found ourselves in a situation where most people use computers, to chat, read news etc, all of which would be possible with much less resources. All done with the use of platforms that we literally can't rewrite, as they're too complex. It's certainly not find's fault, but the complexity creep starts somewhere.

Plan 9, as a research OS, is not a useful platform to base your next business on, but it does serve as a baseline we can relate our "real" platforms to.

Little conveniences cost a lot.

Just having a framebuffer with page flipping for seamlessly redrawing the screen costs 64MB of memory at 4K resolution. People did real work and gaming on computers with a small fraction of that.

Early on in the history of computing the framebuffer was discussed as a theoretical construct, like "what could we do with this concept if we had the memory to implement it".

After staring down find(1) on an AIX system I regret not going down the du | grep path. At least that way I wouldn't be stuck trying to mash GNU's parameters into completely incompatible version of find.

If your system supports `man 1p` (loading the posix manual for each supported utility), it is a good idea to reference that instead of the default manpage; it is more likely for your utility to support posix options than GNU extensions in legacy and non-linux systems.

>I think a good mini language bridges the gap between interactive commands and programming.

find(1) is a bad mini language. Its arguments are in a legacy format and its solution for composability is a hack, and an unstable one.

And shell users already have a language they know & should be able to use to compose computing: the shell.

Different programs introducing their own specific programmatic layers defeats the holistic small pieces, loosely coupled premise.

Sure, which lends weight to the idea that the shell should be a more extensive programming language. Then you can pass an arbitrary Predicate<File> to the finder (which would likely just be a convenience function of about 5-20 lines), and receive a list of file objects for you to do what you want with

That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has become so ubiquitous and influential that we've forgotten that programs could pass more than ill-specified strings around, and that resources could implement richer interfaces rather than trying to force the file IO interface on every single one, regardless of how little sense that makes

Worse is Better may have been a useful expedience in the 20th century, but we're long overdue repaying that technical dept, to get back some of the rich OS/environment features that other camps had got working almost half a century ago. The first step would be to stop putting "Unix philosophy" on a throne

"That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has become so ubiquitous and influential that we've forgotten that programs could pass more than ill-specified strings around ... The first step would be to stop putting "Unix philosophy" on a throne "

Well yes, but I think it will be hard or rather impossible to convince the unix crowd of anything good coming from windows.

There are still tons of stringly-typed interfaces in powershell.

I did not say I am a big fan of the powershell or windows in general. But I would still like the few good ideas integrated into linux ..

Unix being stringly-typed is a huge problem.

For example, I found a flatpak of a system monitor and thought it was portable. Turns out, it parses `ps` output directly, but it's not compatible with BusyBox `ps` output

https://github.com/hakandundar34coding/system-monitoring-cen...

the author literally doesn't care since it works with coreutils `ps`

it's a culture problem

Doesn't ps just parse /proc entries these days? Seems like an odd hill for that dev to die on.

I suggested for him to parse /proc in that issue tracker, but he kind of stopped reading my suggestions

I agree with you to some extent, but the solution is fd: change the tool's interface to make simple things easy. Deleting the tool entirely does nobody any favors. As bad as find(1) is for simple stuff, piping du(1) to grep(1) is worse.

That's half of the solution. The other half, I'm convinced, will be a tool that makes complex things possible. After all, if I really need some complex filtering, find's primitive logical operators probably wouldn't even be sufficient. To that end, I love how Nushell's leading example on their home page is

    ls | where size > 10mb | sort-by modified

It seems so elegant! Down with strings! …But it's not my life yet, since last time I wanted to try Nushell they didn't have scripting yet, and I have yet to circle back around to it. There's also Elvish and PowerShell and Oil Shell but they all have their own issues.

zsh solves this with globbing qualifiers:

  ls -t *(Lm+10)

"L" for the "file size" qualifier (why "L"? For "less than size", I think – probably because "s" is already used for setuid), "m" for megabytes, "+" for "larger than". You can also add "om" or "Om" to sort by mtime, but ls will reorder it so you need the -t flag (or the -U flag to not sort things).

The syntax is not easy, even byzantine, but it's a lot less to type and pretty convenient in interactive shells.

> Nushell they didn't have scripting yet

If you mean you couldn't run batch scripts from a file, they can do that now. There's an example repo with some community scripts. My favourite is how they handle CLI parsing: https://github.com/nushell/nu_scripts/blob/main/sourced/nu_1...

And it makes easy things hard.

All the time arguments and size parameters and rules about depth and boolean syntax and the print0 for pipeline integration ... it makes me long for DOS interfaces from the 80s. There has to be a way to do it with less intellectual lifting every time.

Maybe just a simple set of bash reads will help - that's how I do ssh port forwarding - I was tired of getting confused.

Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video". (This would be at the frontend in this (currently) fictional helper script)

> and the print0 for pipeline integration

The existence of things like `-print0` is the downside of Unix's "all files/pipes are byte streams" design decision.

The IBM mainframe implementation of the pipeline idea – CMS Pipelines [0] – makes pipes record-based instead. Since the pipes are not streams of bytes, rather records with out-of-band boundaries, there is no need to reserve a special character (whether LF or NUL) to serve as a record separator.

> Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video"

It is a pity that Unix never had a "file type" field in the filesystem, unlike classic MacOS, Acorn RISC OS, among others. I suppose both those systems had the limitation that the file type was just a number, subsequent experience has demonstrated it needs to be a much longer string (such as a MIME type or Apple UTI). The problem with file extensions is the same extension ends up being used by completely unrelated applications for completely unrelated file formats – e.g. nowadays .doc is normally assumed to be legacy binary Microsoft Word, but many older archives it is a plain text file instead, or sometimes even some other word processing format.

[0] https://en.wikipedia.org/wiki/CMS_Pipelines

I'd recommend you not look at awk/sed then.

Awk is a real programing language (hint: who are A, W, and K) where short scripts are strings passed in via single arg. That's not find.

Sed has a fairly well designed although limited interface you again pass in.

By contrast find tries to have separate pieces strung together each as an argument.

Hear hear. When I use find I only use it for the recursive dir listing with no arguments. I always pipe it into grep because I know grep better.

Hard to grep a list of path names for size or last modification date?

When I saw the start of this thread, I thought abusing "du" for "find" sounded insane - but after mulling it over - I guess du is just a recursive stat(1).

And I can see the logic; have a tool that builds a tree of metadata, filter with a tool that... filters.

However - as far as i can tell, du/grep on plan9 can't fill in for find(1) - but the idea (above) would probably fit with PowerShell or other "typed/rich streams" kind of shell...

https://man.cat-v.org/plan_9/1/grep

https://man.cat-v.org/plan_9/1/du

Reply on news.ycombinator.com