Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A simple, fast and user-friendly alternative to find, written in Rust

github.com

Post reply on HN
Print view View original

191–200 of 225 posts

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#191

Post by foo101 »

laumars wrote: post #161
foo101 wrote: post #136

Earlier quoted context omitted.

What surprises me is that even after 25 years of the Internet, we cannot bring in new tools into our environment (be it a remote box I ssh into or a trimmed down docker image) on the fly. The popular package management tools rely heavily on FHS and like to install stuff into directories that require root permission. Imagine if there was a tool that could download binaries of modern tools from a certain repo and insta…

You can. There's nothing stopping you adding ~/bin to $PATH. Many compilers allow you to specify the destination location either via a ./configure flag (for example) or an environmental variable. Or there is always the option of doing a `make build` and then manually copying the binaries into your ~/bin directory without doing a `make install` You can also add ~/lib (for example) to your LD_LIBRARY_PATH path if you w…

This is precisely what I am forced to do and I do this very often when I have to setup my environment in a remote box I don't have root-login too. But this is by no means a trivial process compared to how easily we load a complex app into a browser tab just by clicking a URL.

I think it is fair to hope that after 25 years of Internet, it should be easy to bring in new tools from the Internet into our local environment without requiring root access in a safe and trivial manner.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#192

Post by zeotroph »

burntsushi wrote: post #188
zeotroph wrote: post #131

Earlier quoted context omitted.

> Not to mention the "opinionated" choice to ignore a dynamic set of files and directories That has bitten me a few times when using `rg`. Sometimes (but not often enough to remember the switch) I want to grep a lot of binary .so files for a string and am left wondering why nothing was found before just replacing rg with grep. Just calling `TOOL PATTERN` without switches is the most intuitive thing, and there I agree…

If you're grepping binary files, then even with grep, you need to pass the `-a/--text` flag. ripgrep has the exact same flag. Protips: `rg -u` stop looking at `.gitignore` files. `rg -uu` searches hidden files/dirs. `rg -uuu` searches binary files.

I actually forgot why exactly I switch from rg to grep for binary files, but after some tests I found the use case grep can but ripgrep can NOT do:

  $ grep FOO *
  Binary file libBar.so matches
  foo.txt:file with FOO in it
rg/rg -u/rg -uu/ ignore libBar.so completely, whereas rg -uuu spits out binary garbage.

Here grep's default behavior is what I expected: I want to know which binary files contain some symbol, details are less important (yes, I could use objdump or smarter tools, but grep is good enough 99% of the cases).

rg -u should list the matching binary file, maybe rg -uu should walk a few (printable!) chars to the left and right of the binary match and -uuu should just assume it is text, i.e. the user is right and the auto-guess wrong.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#193

Post by SOLAR_FIELDS »

thristian wrote: post #176
SOLAR_FIELDS wrote: post #172

Earlier quoted context omitted.

Is POSIXLY_CORRECT supposed to be a play on “politically correct”? If so that’s pretty amusing.

RMS' original convention for requesting GNU tools be compatible with questionable legacy behaviour was POSIX_ME_HARDER, but he toned it down as a gesture of goodwill to the other members of the POSIX committee.

That’s so great and puts the variable name into even better context

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#194

Post by Sean1708 »

zzzcpan wrote: post #183
thristian wrote: post #178

Earlier quoted context omitted.

Nix[1] says hi. [1]: https://nixos.org/nix/

Nix now can download and install binaries into a home directory? I thought it would require quite a bit of work on a building process and binary patching post installation, since you know, a lot of things require absolute paths, like an elf interpreter for example.

As far as I'm aware any user (regardless of whether they have root) can install/update/delete packages when Nix is run in multi-user mode[0].

[0]: https://nixos.org/nix/manual/#ch-nix-security

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#195

Post by Tyr42 »

bm1362 wrote: post #97
jhasse wrote: post #86

Earlier quoted context omitted.

> I would be annoyed if fish was installed on all our prod boxes, for example. Why?

That was just a hyperbolic example, but I can think of a few superficial reasons: 1. Because you end up with a more complex Dockerfile. I've seen curls, clones etc during build - having a remote call for random tools in our build _feels_ like a bad practice. 2. There is also the issue that a fleet of application servers will have different tooling available, which can be frustrating in a pinch. I've done some gnarly…

I mean you wouldn't need to set fish as the default shell. But even if it was, you could `do ssh $i "bash -c '...'";`

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#196

Post by marcosdumay »

burntsushi wrote: post #91
j2kun wrote: post #90

Earlier quoted context omitted.

Who makes the decision on what gets standardized into the distro?

The people in charge of the distro. Governance structures vary. And sometimes it's not just about who gets to decide, but also, the technical work required to do it. People need to put in the work to make Rust applications packageable according to the distro's standards. YMMV.

Debian in particular has an entire alternatives system. Nothing stops somebody from creating the packages `nice_tools` and `select_nice_tools` that will install those tools and make them the default binaries for the commands.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#197

Post by marcosdumay »

foo101 wrote: post #136
bm1362 wrote: post #63

Earlier quoted context omitted.

I appreciate all these new incarnations of old school tools but end up sticking with the basics regardless. When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc. Even local development now, I'm mostly debugging on a docker container running alpine or ubuntu. Knowing the right incantations is useful in that context and keeps me from installing…

What surprises me is that even after 25 years of the Internet, we cannot bring in new tools into our environment (be it a remote box I ssh into or a trimmed down docker image) on the fly. The popular package management tools rely heavily on FHS and like to install stuff into directories that require root permission. Imagine if there was a tool that could download binaries of modern tools from a certain repo and insta…

The problem is that after 25 years of the Internet, we have almost completely stopped using multi-user systems.

It even used to be easier to make stuff run from your homedir. We are moving from it, not towards it. It is really a shame for the few multi-user setups out there.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#198

Post by marcosdumay »

zzzcpan wrote: post #183
thristian wrote: post #178

Earlier quoted context omitted.

Nix[1] says hi. [1]: https://nixos.org/nix/

Nix now can download and install binaries into a home directory? I thought it would require quite a bit of work on a building process and binary patching post installation, since you know, a lot of things require absolute paths, like an elf interpreter for example.

The NixOS way would be to install binaries at the system directories, but for your user only.

I don't know if this is possible with plain Nix (not the OS).

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#199

Post by marcosdumay »

derriz wrote: post #28
josteink wrote: post #4

My main usecase for find is not only finding files, but to do actions on them through -exec. Unless I’m missing something, that’s not supported with this tool.

I'm curious why you (or anyone) uses -exec? It's often painfully slower than piping through xargs and I find the syntax (the semicolon and braces and the required quoting/escaping) uncomfortable. I haven't used -exec in 20 years.

In my opinion, xargs has really niche use cases, and -exec is way more fit for general use.

- There's the issue of command line length, pipe too many files and xargs will just fail.

- There's predictibility. With -exec you get to see the entire command line structure, what is escaped, what is not, what names go where. With xargs, a couple of badly named files and you are out of luck.

- Find's syntax is just more general. Xarg is limited to pushing parameters into a script, while -exec can run whatever scrit you want, with single or multiple parameters, or flags, or whatever.

Performance is almost never an issue.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#200

Post by falcolas »

askz wrote: post #189
falcolas wrote: post #124

I'm sorry to be something of a negative Nancy - and I'm sure I'm a corner case - but this is not really an alternative to find. It's an alternative for your editor's fuzzy find and a better version of shell globs. The absense of -delete, -execdir, -mtime, and the ability to chain multiple patterns together for the non-trivial use-cases, means this is practically useless in most places where `find` is used in day-to-d…

You can still use xargs without overhead : > fd .py | xargs stat

Quick FYI: xargs is not the same as execdir; execdir executes the command in the same directory as the file. And to account for spaces in filenames (yay, OSX), your command starts getting a bit more complicated: fd -0 .py | xargs -0 stat
Post reply on HN