Live data from Hacker News

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

github.com

201–210 of 225 posts

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

#201
post #17

It would be nice to have a collection of modern/faster/saner alternatives to common unix tools and such utilities (made in rust or not) that becomes standard -- or at least easily installable in linux distros and OS X. Not for replacing those tools, but for supplementing them. Thinking of stuff like fd and: ripgrep: https://github.com/BurntSushi/ripgrep (grep/ag alt) xsv: https://github.com/BurntSushi/xsv (csv tool)…

I like tool called "just". It's simple command runner inspired by make. https://github.com/casey/just One could argue that tool like this makes no sense since make is installed almost everywhere but I'm already using fish shell so one more non standard tool makes no difference. I appreciate simplicity of "just".

Really cool, I've needed this quite a number of times. Thanks for the tip!

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

#202
post #64

Earlier quoted context omitted.

It would be even nicer to have an opensource project that pushes a set of these tools, that then can get picked up by the distros such that in 5 year you can expect these all to be included at a reasonable version such that you do not have to install them by hand on each machine that you land on. On the other hand, you may want to keep some smart dotfiles around that installs them in ~/bin

That's the kind of idea that lead to Joey Hess's "moreutils". https://joeyh.name/code/moreutils/

Yes. But not entirely. Also the set of tools that he combines is ment to be an addition, not a (potential) replacement.

(Joey is a boss, did not know of this project of his -- thanks for pointing out)

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

#203

Earlier quoted context omitted.

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 a…

That's an interesting use case. You could use the `-l` flag to only list file names that match in combination with `-a` I suppose. That wouldn't let you see the non-binary matched lines though.

In any case, I filed an issue[1]. I think the UX is pretty tricky to get right though.

[1] - https://github.com/BurntSushi/ripgrep/issues/631

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

#204
post #167
post #149

Earlier quoted context omitted.

https://github.com/uutils/coreutils is a long way along.

The docs don't say: is this meant to replace Busybox or the actual GNU coreutils? As in, all GNU features and flags (which are generally much more comprehensive and IMO nicer than plain old POSIX features).

I do think it (optionally) provides a busybox-esque single-binary interface, but I do not know whether this also translates into a busybox-esque command-line interface.

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

#205
post #17

It would be nice to have a collection of modern/faster/saner alternatives to common unix tools and such utilities (made in rust or not) that becomes standard -- or at least easily installable in linux distros and OS X. Not for replacing those tools, but for supplementing them. Thinking of stuff like fd and: ripgrep: https://github.com/BurntSushi/ripgrep (grep/ag alt) xsv: https://github.com/BurntSushi/xsv (csv tool)…

I'm afraid I don't quite see the purpose of una. There are really only two command lines you have to remember. `7z x` for anything.7z and anything.rar. And `tar xf` for anything.tar.anything.

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

#206

Earlier quoted context omitted.

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…

> 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. Of course you can, technically. The parent laments why it's not easier to achieve. Already you're talking about manually building for example. Where's a package manager that will allow for that too, not just the central re…

The GP had exampled one easier and safer way of doing this: sandbox each user in their own Linux instance.

Anything short of that would be sacrificing security for the sake of convenience.

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

#207
post #191

Earlier quoted context omitted.

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 environmen…

Firstly the internet is a lot older than 25 years (perhaps you mean web?) and secondly if the last 25 years has taught us anything it's that allowing users to download and install whatever they want usually leads to problems. I mean I do get your point and even sympathise with it, to a point. But if someone needs SSH access and I don't trust them enough to put them in the sudoers file, then I'm not going to trust them enough to even choose what software to install and run from their own local user area. I've been burnt before from intelligent people doing stupid things because they thought they knew what they were doing. So if you're not a sysadmin and you're logging into a shared host, then you don't get install rights. I don't think that's an unreasonable stance to take.

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

#208
post #145

Earlier quoted context omitted.

That's basically what's happening. AFAIK, ack kinda started it all by observing, "hey, we frequently have very large directories/files that we don't actually want to search, so let's not by default." Depending on what you're searching, that can be a huge optimization! Tools like `git grep` and the silver searcher took it a step further and actually used your specific configuration for which files were relevant or not…

>”hey, we frequently have very large directories/files that we don't actually want to search, so let's not by default” >Was this a thing back when the BSD and GNU greps were being developed? Was it common for people to have huge directory trees (e.g., `node_modules` or `.git`) lying around that were causing significant search slow downs? Not sure, Sure, actually. It was called “build” and it was moved out of source c…

Those who don't understand history are destined to repeat it?

also that approach seems dependent on all projects you might want to grep (in this example) building cleanly into an external directory, which is naturally never going to be 100%: some people don't know why other software supports those options, some people don't care, some people think that's the wrong solution to the problem, etc. Ultimately someone comes along and builds up a big enough body of experience that they can account for and fix some fraction of the brain dead behavior out in the wild, and the rest of us get a useful tool.

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

#209

Earlier quoted context omitted.

httpie: https://github.com/jakubroztocil/httpie (cURL for humans) Httpie is my goto http cli for all systems. Pretty much PostMan (that a lot of ppl use for no reason) but without annoying UI and on a single line. Formats JSON and colors it right in the terminal as well. Has a super nice query, header and post body syntax. Works well with sessions and cookies.

> Pretty much PostMan (that a lot of ppl use for no reason) I can't see anywhere in the httpie docs about capturing variables from and/or running tests on the HTTP responses - it's an extremely powerful feature of Postman when you're debugging non-trivial HTTP flows.

and nor should it. If you think the unix way and use a tool that excels in that you'll find your path to success (e.g. jq).

    $ userId=$(http get https://jsonplaceholder.typicode.com/posts/1 | jq '.userId')
    $ http get "https://jsonplaceholder.typicode.com/users/$userId" | jq '{name,email}'
    {
      "name": "Leanne Graham",
      "email": "Sincere@april.biz"
    }

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

#210

Earlier quoted context omitted.

ack: https://beyondgrep.com/

grep came, then ack-grep, then silver-searcher and a few others, finally ripgrep. For most purposes, ripgrep (the one written in Rust) is the best of all of these tools, typically being the fastest and also the most Unicode-compliant, with the main downside being its non-deterministic ordering of output (because it searches files in parallel). The only reason for using ack these days is if you’re already invested in…

What do you mean by a "invested in a Perl workflow"? Do you mean "comfortable with Perl regexes"?

Other reasons that you may want to use ack:

* You want to define your own filetypes

* You want to define your own output using Perl regexes

* You need the portability of an uncompiled tool in a single source file that you can drop into your ~/bin when you can't install or compile anything on the box.

* You don't want to have to deal with a Rust runtime.

Post reply on HN