uvx ut md5 ...
npx ut md5 ...
I've seen a few tools do things like this recently, it's a pretty interesting pattern. I believe there's tooling in the Python/Rust world that makes compiling the different binary wheels relatively easy using GitHub Actions.
uv also has a couple commands I throw in a systemd unit[1] to keep these tools updated:
uv self update
uv tool upgrade --all
Another suggestion is to enable cargo-binstall, it allows just to install cargo binaries conveniently, and cargo-binstall is just a single-binary to install itself.
But I would probably argue that including HTTP functionality is going too far. Why? Because there are already amazing tools dedicated to this already. On the client side, see `xh` [1]. On the server side, see `miniserve` [2]. Both have approximately 7K stars on GitHub.
It seems wiser to let specialized projects focus on a particular functional area; this is better for users and less work for maintainers.
You can serve a folder of static assets like this:
http-nu :3021 '{|req| .static "www" $req.path}'
Although philosophically I prefer the unix approach of "do one thing and do it well", I really admire this tool. I think it might be the fact that the one thing this does well is curating a set of functions for a particular profile of developer. My story is someone doing web focused full stack development?
It might be worth doing a survey of your users to see what they use ut for and what areas you should focus on next.
The important part is that the user controls the entry points. It's more Unixy to allow someone to decode audio from one pipe to another than to only allow them to play a file to a speaker.
Consider that Debian "does" lots of things because it has a kernel, hardware abstractions, a userland, a package manager, and often a GUI and web browser. But it also "does" none of those because it's just a convenient and useful wrapper to publish all the other tools, which you can still call upon individually
In this title you tell exactly zero information about what your tools actually do, but somehow find it important to mention the language they're written in.
1. Input must be valid UTF-8. 2. stdin is read to EOF instead of being read incrementally
Neither are ideal and can make ut unfit for a fair few use cases.
I am seeing the list of dependencies, and even without looking at the transitive ones, I am sure you didn't review any of those, nor will properly maintain that huge list.
That's a supply chain ticking bomb in my book.
I like Rust, but most projects look like kindergarten collage with no regards to security.
- the Web & Network section expanded: the copyparty features (github.com/9001/copyparty) and curlie (github.com/rs/curlie).
- compress/decompress features with password: it doesn't need to use the best compress algorithm, gzip is good enough.
Has the creator thought about the definition of "done"? Will it grow indefinitely like a katamari ball?
``` python -c "import base64; print(base64.b64encode('$INPUT_STRING'.encode('utf-8')).decode('utf-8'))" ```
Yes it's easy to set up an alias or shell command or whatever, but that's besides the point :p
The point of ut is not to replace or invent new tooling. It is meant to be a set of tools that are simple, self exploratory and work out of the box with sane defaults. So, essentially, something that you don't have to remember syntax for or go through help/man pages everytime you want to use it.
With GNU coreutils:
$ base64 /dev/zero | head -c 1 | wc -c
1
Just realized `LC_COLLATE=C sort` must be specified if you don't want it to ignore leading underscores in sorting due to LC_COLLATE=en_US.utf8 being the default these days.
https://docs.openssl.org/master/man1/openssl/#command-summar...
$ go run github.com/dolmen-go/goeval@master 'fmt.Println(base64.StdEncoding.EncodeToString([]byte(os.Args[1])))' foobar
Zm9vYmFy $ echo -n foobar | openssl base64 -e
Zm9vYmFyThe new versions 7 and 8 are really a must these days, especially v7.
I also have the exact same tools but written in Go. Rust would be a nice upgrade (lower footprint) but to keep them all in the same binary is a bit silly.
Sometimes it can be quite convenient to grab a single binary that does a whole bunch of useful stuff in one package.
I could definitely see using this in a cross-platform build or installation environment.
This could be great for students without sysadmins needing to lodge complaints.
These are small bits of code, and the functionality is interrelated. The entire thing feels like a calculator, or awk, and seems reasonable to put in one binary.
The Unix philosophy doesn't actually say anything about whether different tools should live in the same binary. It's about having orthogonal bits of functionality and using text as the universal interface. BusyBox is just as Unix as having all the tools be different binaries.
- it reduces the total install size, since common code, including the standard library, is only included once, rather than copied for each executable
- it makes installation easier on some platforms, since you just have to install a single executable, instead of a bunch of executables