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
this post was submitted on 18 May 2024
39 points (95.3% liked)
linuxmemes
20408 readers
961 users here now
I use Arch btw
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules
- Follow the site-wide rules and code of conduct
- Be civil
- Post Linux-related content
- No recent reposts
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
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.
When a link contains parentheses, you have to escape them... or else.
Please try it again and let me know if this fixed it. Both versions work on my end.
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.
locate enjoyers unite.
Corporate users in shambles because mlocate.db cannot be generated without root.
Idk why but I've always been a locate enjoyer myself. But find has more usecases.
Like what?
Find can find stuff based on permissions or other variables and interact with files, like delete etc
Locate is just a database of filenames
Grep. Couldn’t live without find exec grep.
You rarely need find with grep if you man grep. Grep does it all.
Grep is going to find all .java files in /home/user/workspace? And then conditionally search them? Not so sure about that.
grep -R --include=\*.java "pattern" /home/user/workspace
The year is 2024, I put esoteric use of the find command on my resume, it's 1989...
The world if we could use wildcards on ADB push/pull directly..
Positional params are the work of the devil; what starts as shorthand quickly turns into a horrible mess
FWIW you can fix it locally and eventually use a pull request.
I don't know find well enough to comment on feasibility but I bet it'd be interesting to try, and maybe realize it's not trivial.
What's up with find? I've got so used to fd that I don't understand what this is referring to
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.
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.
Nice, UX is clearly a top priority (;
I'll have to try and see if FD does the same bullshit though
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.
I mean you could alias the glob option as the default but I clearly see your point about standardized default behaviour.