Not an expert nor a historian, but my understanding is that 'find' goes back a long way (*nix has been around a while).
Earlier commands such as find were created back before a lot of command/option syntax forms we know today were agreed to and standardized.
Since 'find' has been around so long, we've just suffered its non-standard syntax rather than risk the chaos that would be unleashed by trying to fix it.
If it makes you feel better, you can console yourself that you're using one of the more arcane incantations of the elder *nix wizards.
It works now. It definitely didn't before when using Sync for Lemmy. That kind of mistake wouldn't have worked on the reddit website either. I had seen it a million times. Not sure if the Lemmy web site would handle it right.
Both versions work on my end.
I'm surprised to hear that.
Markdown libraries normally see the closing parenthesis in the URL as the end of the link markdown syntax of [text](link). You had [text](link(stuff)) which is parsed as [text](link(stuff) A smarter markdown parser could handle it, so whatever app you were using might do that.
I don’t mind the order of path, arguments and options, but what the hell is the deal with long arguments with a single dash? i.e. -name instead of —-name
find's expressions are order-sensitive and look like options, which is probably why the real options go zeroth, then the starting path goes first. Also, there is a -path-match expression that means something different than that starting path.
That said, there's nothing stopping the writing of a wrapper script that allows any placement or intermingling of any of those groupings.
The simplest would just grab the last argument and use it in the first position, which I'm guessing is what the meme creator really wants. Watch out for the edge case of whitespace in the path name. (And the edge case of the edge case where the end part of that path is valid but not the intended target.)
When you want to find something in a different path than your current one you have to supply it as the first argument. When you try to do find -name foo.bar /path it will complain that the path should be the first argument. So it knows what you're trying to do and instead of doing it it just complaints.
I dont think it does. The thing that annoys me about fd is that it uses regex as a default for patterns while I'm used to having glob as default everywhere else.
Back in the day, find required that you added "-print" to actually print out the results in the terminal. That was bad UX, and now -print is the default. But.. following some syntax like supplying path as first argument for find is necessary to not create ambiguity in some cases, and enforcing it makes it more readable imho.
That's already the friendly variant. Traditional find has a mandatory path as first argument, so to find in the current directory you need to do find .
It also doesn't know if it really is a path - it just prints that as a likely error. You might just have messed up quoting an argument.
