cat's primary purpose is combining files together. For example: cat mysoftware.tar.gz mysoftware.sig > mysoftware.bin Combines an archive with a digital signature into a single file. Then, on the other end, you just need to pop off the signature with a tail -1 Or alternatively: cat a.log b.log c.log > monolith.log
Of course, but its primary purpose (combining files) differs from its primary usage (showing a file’s content).
The primary usage us just a special case of its primary purpose. You're concatenating the file with nothing.
I feel like these tools very much go against the Unix philosophy of "Write programs that do one thing and do it well". They try to do the pretty user interface and the underlying operation in a single tool. I prefer PowerShell in this respect where the output of each command is not text streams (as in the Unix world) but objects which can be operated on in a more object oriented way. You spend less time thinking abou…
"One thing" has never been very well defined - basically every common Linux shell tool could be said to do more than one thing. GNU `grep` supports four different pattern styles (fixed strings, basic regex, extended regex and Perl regex), has lots of options for output formatting (counting, line numbers, whether to display file names, etc.) and has a bunch of rarely-used (but useful!) options for various corner cases, such as line buffering. Even GNU `cat`, the canonical "do one thing" tool, has several formatting options. If `grep` returned match objects rather than a semantically void binary stream it would be really easy to hand over formatting to another tool, but that just isn't how *nix tools work yet.
Is anyone else impressed with the quality (and speed!) of some of the tools written in Rust? I'm an avid user of fd and bat, the former being ridiculously fast. Often I find something on github, I'm impressed by the quality of the documentation, features, UI etc, then lo and behold it's written in Rust. Another one potentially for this list is tokei[1] I was trying to count the code in our repos at work and used the…
IIRC, loc (in rust) might be even faster than tokei at times? I always forget, and I’m sure I saw an old benchmark... We have a whole working group this year focused on making the experience of writing CLIs awesome, so hopefully we’ll see even more great tools in the future!
>We have a whole working group this year focused on making the experience of writing CLIs awesome
Can you explain what you mean by this? Something like the people are going to focus on language and library features that help with writing CLIs? Or something else?
GNU Parallel is the first thing I usually install on top of a standard Unix userland. It's almost a superset of xargs, with many interesting features. It depends on perl, though. htop is also pretty much a great replacement for top. And ripgrep a great replacement for the find | xargs grep pattern. Aside from that, I'm pretty content with the Unix userland. It's remarkable how well tools have aged, thanks to being co…
I had issues using gnu parallel in the past because of --will-cite. I ended up not using it.
IIRC, loc (in rust) might be even faster than tokei at times? I always forget, and I’m sure I saw an old benchmark... We have a whole working group this year focused on making the experience of writing CLIs awesome, so hopefully we’ll see even more great tools in the future!
>We have a whole working group this year focused on making the experience of writing CLIs awesome Can you explain what you mean by this? Something like the people are going to focus on language and library features that help with writing CLIs? Or something else? Asking because CLIs are one of my interests.
I don't feel the plain text portion has aged well at all in regards to composability. It leads to a lot of headache as the complexity of the task grows because of the in-band signaling and lack of universal format. I think it is high time the standard unix tools were replaced with modern equivalents that had a consistent naming scheme and pipelined typed object data instead of plain text.
I think you should check out Powershell.
Is that a joke? The syntax is worse than PHP and it doesn't run on Linux
I was wondering if any of you use alternatives or hacks for the cd command? I've been testing out a couple of different ones, like xd, fcd, wcd and pushd/popd, but I'm not quite sure which I should commit to or if there are better ways :)
I use z [1], it builds up a list of folders you visit based on frequency and lets you quickly jump into them by fuzzy-searching it. Z also has tab completion allowing you to cycle through the matches. See project's home for examples of its work at the link below.
Cat is just a tool to dump files to stdout and maybe concatenate them. If you want paging, syntax highlighting, etc, you probably want a tool to replace `less`, not `cat`.
GNU Parallel is the first thing I usually install on top of a standard Unix userland. It's almost a superset of xargs, with many interesting features. It depends on perl, though. htop is also pretty much a great replacement for top. And ripgrep a great replacement for the find | xargs grep pattern. Aside from that, I'm pretty content with the Unix userland. It's remarkable how well tools have aged, thanks to being co…
I don't feel the plain text portion has aged well at all in regards to composability. It leads to a lot of headache as the complexity of the task grows because of the in-band signaling and lack of universal format. I think it is high time the standard unix tools were replaced with modern equivalents that had a consistent naming scheme and pipelined typed object data instead of plain text.
If Unix pipes gained support for exchanging some kind of out-of-band signalling messages, then CLI apps could tag their output as being in a particular format, or even the two ends of a pipe could negotiate about what format to use. If sending/receiving out-of-band messages was by some new API, then it could be done in a backwards compatible way. (e.g. if other end starts reading/writing/selecting/polling/etc without trying to send/receive a control message first, then the send/receive control message API returns some error code "other end doesn't support control messages")
(But I don't really care enough about the idea to try to implement it... it would need kernel changes plus enhancements to the user space tools to use it... but, hypothetically, if PTYs got this support as well as pipes, your CLI tool could mark its output as 'text/html', and then your terminal could embed a web browser right in the middle of your terminal window to display it.)