[michaelmior]

That doesn't solve the "available everywhere" problem. It potentially would make the tools easier to install on Debian-based systems, if you have root access. I'm not sure any new set of tools will ever be available with the ubiquity of coreutils in the next handful of years, if ever.

[jarbus]

I agree. If these could be made installable without root, and independent of the current version of glibc, then there is huge potential to replace the older tools. I’d love to use things like fd, but they don’t work on older servers without root and a newer version of glibc

[tomjakubowski]

They're already installable without root. Just put them in ~/.local/bin. Most Rust binaries are portable and only dynamically link libc.

[layer8]

Local installation is still not really a practical solution when you work e.g. on customer machines, on machines of another team, or generally if you work on many different machines. You still need to be aware of the standard tools and know how to use them when needed.

I mean, I get it — I used to locally install vim on machines that only had vi, to make my muscle memory be functional when editing files. But it’s not the same as a core tool just being available by default so you don’t have to ever concern yourself with any alternatives.

[jarbus]

That’s what I initially tried for fd, but unfortunately glibc is required for it, and probably other utilities as well.

[homarp]

fd has musl version

https://github.com/sharkdp/fd/releases/download/v8.4.0/fd-mu...

[roey2009]

What would prevent us from adding those to a docker file?

[jarbus]

Docker not being installed on remote

[moondev]

This is why I like that you can "go run" golang programs without installing them. Anywhere golang is installed it will automatically build cache and run the binary for whatever platform you are on.

For example

   go run sigs.k8s.io/kind@latest create cluster

I wonder if something like this exists for rust

[PaulDavisThe1st]

Absolute no possible exploit path there at all

[taftster]

Unless you are reviewing the source of everything and compiling it all yourself, then you're executing someone else's binary.

[naniwaduni]

Is it really an exploit when you're explicitly running code that you expressly trust (even if you probably shouldn't necessarily)?

[_carbyau_]

Isn't an exploit explicitly a subversion of trust?

If you shouldn't trust it but you do anyway and someone uses that against you - they exploited your trust.

[michaelmior]

That is nice, but it still requires installation of golang which is obviously something that can't be guaranteed.

[steveklabnik]

“cargo install” is the Rust equivalent.

[fragmede]

There’s moreutils for an older rethink of the same set of utilities. I don’t see why an evenmoreutils wouldn’t eventually become popular enough to take hold? Probably not as quickly as you’d like in today’s world of instant gratification, but we’ll get there, eventually.

[michaelmior]

moreutils is still nowhere near as ubiquitous as coreutils. For me it's not about gratification. It would be more satisfying to make use of the most modern tools available. It's about making sure stuff works and I find sticking to coreutils is the easiest way to do that most of the time.

[sitkack]

Install rustup from https://rustup.rs/

    cargo install broot exa miniserve ripgrep tuc xh xsv zellij

Cargo is the package manager you are looking for.

[michaelmior]

I use Cargo regularly and rustup it does make it easy to install. That's not the point. I'm not looking for a package manger. I want to be able to write scripts that make use of tools I can pretty much guarantee are already installed.

[sitkack]

So we aren't talking past each other, how do you delineate between cargo and a package manager? Does anaconda, pip (pypi) or homebrew also qualify?

Your scripts could have a prolog that installs rustup and calls cargo.

There is also https://github.com/ryankurte/cargo-binstall

Even after 20 years of bashing, my bash skills still suck. So many corner cases!

But if you include this, and call install_utils at the head of your scripts. It should install the tools on demand.

    #!/bin/bash

    RUST_PACKAGE_LIST='rg xsv tuc broot du-dust dutree'
    RUST_UTIL_LIST='rg xsv tuc broot dust dutree'


    function is_cargo {
        cargo > /dev/null
    }


    function is_utils {
        eval "which $RUST_UTIL_LIST" > /dev/null
    }


    function install_utils {
        if ! is_utils ; then
            if ! is_cargo; then
                curl https://sh.rustup.rs -sSf | sh -s -- -y
            fi
            eval "cargo install --locked $RUST_PACKAGE_LIST" > /dev/null
        fi
    }

I don't recommend using this, it is just illustrative.

[michaelmior]

My primary point is that if I stick to coreutils, I don't have to worry about any of this. I can reasonably expect anything in coreutils to already be installed and available. Your functions seem like they'll work just fine, but either requires build tools to be installed, or the package to support binstall. For me, thinking about all these things and maintaining something like that isn't worth it when I can just use coreutils.

[sitkack]

I totally understand. My .vimrc has shrunk from over a hundred lines to 4 lines in the last years. But I really think you are doing yourself a disservice. It is easier than ever (homebrew, nix, cargo, pip) to get nice software everywhere.

[throwamon]

Have you tried running them with Nix? I believe you can use most things from it without root, but I'm not sure.

[michaelmior]

I suppose I shouldn't have said only Debian. But having tools easily installable is still quite different from being able to reasonably assume they are already installed.