Re: bat > cat 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`.
view is also perfectly good, it's vim's pager.
CLI: Improved
231–240 of 280 posts
Re: CLI: Improved
#232Earlier quoted context omitted.
Also don't forget Cargo. It makes it so much easier to work with than installing C/C++ dependencies.
Cargo is awesome too. Cargo reminds me of Mix (from the Elixir ecosystem). The one thing that Mix has on Cargo is that it is super simple and straight forward to extend Mix. Cargo may be the same way but from what I've seen it seems more complicated.
Do you have any docs on what you mean by extensibility here? I’m curious!
Re: CLI: Improved
#233Earlier quoted context omitted.
Cargo is awesome too. Cargo reminds me of Mix (from the Elixir ecosystem). The one thing that Mix has on Cargo is that it is super simple and straight forward to extend Mix. Cargo may be the same way but from what I've seen it seems more complicated.
That’d make sense given the common ancestry in Bundler :) Do you have any docs on what you mean by extensibility here? I’m curious!
[0] https://hexdocs.pm/mix/Mix.Task.html [1] https://github.com/jhartwell/Plsm
Re: CLI: Improved
#234Earlier quoted context omitted.
How hard is it to come up with a object format (more like a data structure format since I wouldn't want logic/code being passed around) and then come up with a standard text serializer for it? Not that hard, in my opinion. You'd standardize it once via an RFC and you'd be done with it. I don't think your problem is as big as you say it is. The real problem is that this pile of code we already have kind of works and i…
It's not about backwards compatibility. It's about the fact that text is what we read as humans and if commands parse the same format there is only one output format to implement.
As oblio said, you can come up with a standard conversion of structured data to text. The other way round you need write a parser for every textual output format, and typically people come up with fragile ad-hoc parsers that don't deal with edge cases properly.
Re: CLI: Improved
#235Earlier quoted context omitted.
How hard is it to come up with a object format (more like a data structure format since I wouldn't want logic/code being passed around) and then come up with a standard text serializer for it? Not that hard, in my opinion. You'd standardize it once via an RFC and you'd be done with it. I don't think your problem is as big as you say it is. The real problem is that this pile of code we already have kind of works and i…
It's not about backwards compatibility. It's about the fact that text is what we read as humans and if commands parse the same format there is only one output format to implement.
Of course, who am I kidding, in real life we have some sort of crappy text interface which is half-baked both for humans and for machines. But we've been using it for almost half a century and it's too widespread to redo, so there we are, plowing through it daily.
Re: CLI: Improved
#236Earlier quoted context omitted.
Just like any other compiled language. GCC's static linking issues with glibc don't apply to other compilers.
No, not like any other compiled language. Just like any other native compiled language, maybe, but Java and C# are also compiled yet require a large runtime in order to run any application. An 8Mb executable written in Rust is going to be 8Mb total. An 8Mb executable written in C# or Java is going to weigh much more than that when you take into account the framework. Now, one could argue that it is almost a given for…
You just have to look properly for those options.
The only thing is that not all of them are free beer.
Re: CLI: Improved
#237I 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…
This is correct. The thing is, powershell is not for humans. It is purposed more towards configuration and system scipting, and thus should be compared to something like ansible. Using it as a shell is counter-productive unless you have very specific mindset. Unix shell, on the other hand, is a trade-off: it offers you options to process and automate and reasonable convenience when working interactively. None of thos…
On Windows, I strongly prefer PowerShell for interactive work, although I cringe a little each time I see how much memory it uses.
Re: CLI: Improved
#238I like these kinds of articles, but it's rare I need that many CLI tools on my MacBook. I interact with hundreds of servers on a day-to-day basis, and I don't want to go around installing random tools on my servers. But I guess it's an idea for some tools to add to my Ansible server provisioning script :-)
I always update my Ansible script when I find something worthwhile. Besides, why not just make a $HOME/bin/ and throw your new stuff in there?
Re: CLI: Improved
#239Earlier quoted context omitted.
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…
>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. Ha ha, I had dreamed up something like this in one of my wilder imaginings, a while ago: A command-line shell at which you can type pipelines, involving some regular CLI commands, but also GUI commands as components, and when the pipeline is run, those GUIs w…
Re: CLI: Improved
#240- ranger (and the ranger-cd script) are pretty useful to explore folders in the terminal. https://github.com/ranger/ranger - percol and ripgrep as alternatives to grep - tig as TUI for git - kakoune as alternative to vim
I like vifm over ranger. Simple dual pane with vi key binding.