Crates.io | needs |
lib.rs | needs |
version | |
source | src |
created_at | 2024-10-08 17:59:37.732295+00 |
updated_at | 2025-05-14 21:24:50.486665+00 |
description | Check if given bin(s) are available in the PATH |
homepage | |
repository | https://github.com/NQMVD/needs |
max_upload_size | |
id | 1401511 |
Cargo.toml error: | TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
Check if given bin(s) are available in the PATH.
...multi-threaded of course.
using cli args
using needsfile
needs <bin>...
or
# returns 0 if all bins are available, 1 otherwise
needs -q <bin>...
cargo install needs
or
cargo binstall -y needs
[!NOTE] Target Platforms are UNIX based systems and Windows support is not planned. Because
needs
uses thewhich
andxshell
crates, it might run on Windows anyways.
[!IMPORTANT] Keep in mind that needs runs the programs you give it. (if it's told to retrieve versions that is...)
This has been tested and shown good results, but there's always one that doesn't work with any conventions or just a really old program. In such cases the program doesn't return a version that needs can read, but instead goes off to do it's thing and potentionally ends up making modifications to your filesystem (e.g. deleting files for whatever-reason, we don't know yet).
If you happen to run into one, there's basically nothing I can do for you. Still, I would like to try or just hear about it so i can inlude it in a list to prevent future incidents.
The program is inspired by the has
bash program. Therefore I also wanted it to have the version retrieval feature.
For now that process relies on the individual binaries getting called with the --version flag,
which can be extremely slow in some cases (the mintlify
program for example takes almost an entire second to respond).
Thanks to par_iter
from rayon it's possible to run all commands in parallel tho, which helps at least a little bit.
For the future I want to improve the multithreading part by introducing a timeout for the threads. Those that take to long to answer will be terminated after the timeout and the affected binaries will only be marked as found, without a version.
But even with those improvements some might only want to check if the program is installed.
Therefore I not only added a flag --no-versions
but also made it a cargo feature which can be disabled with --no-default-features
when installing.
Also planned is a feature that includes a list of known
To identify long running binaries, you can use the verbose flag to increase the logging level, which when reached DEBUG (-vvv) shows the timings for the individual binaries. If you also find poorly optimized programs, just create an issue so i can keep track of them, but you could also just notify the developer and tell him to stop using javascript for big terminal tools :)
As before mentioned, the speed of the program depends on the called binaries if run with version retrieval.
The speed of the program itself is actually quite fast, see the report.md
for the results of a benchmark.
The benchmark was done with the hyperfine
program, run on a M4 Macbook Pro.