Earlier quoted context omitted.
...As long as you don’t have spaces in file names. I’d like to see something like cvs used more, where it can handle the edge cases without breaking, but still doesn’t need a translation step
is there any filesystem that does not enable spaces in filenames? I find the idea ridiculous. Would you design a programming language that allowed spaces in its variable names? Because that is the same level of atrocity.
CLI: Improved
251–260 of 280 posts
Re: CLI: Improved
#252I'd really love to know why 99% of the well made, polished and fastest of these tools are made using Rust if anyone patient enough cares to explain. Is Rust a particularly good fit for CLI tools like these ? Why so ?
Re: CLI: Improved
#253Earlier quoted context omitted.
"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…
The thing I would like to see with grep is to have it optionally give me a 0 return code if it doesn't find anything. I know why the authors chose to use a non-zero return code as the default, but when I'm using grep deep in a pipeline and doing my own checking of the results to see if nothing was found, I don't need grep bombing out the whole pipeline with a non-zero return code. The alternative of being forced to u…
Re: CLI: Improved
#254Noti looks nice, but typically I just do `whatever-long-command && tput bel`. On Macs, the Terminal dock icon bounces and gets a badge whenever the console bell rings and the terminal is in the background. https://apple.stackexchange.com/questions/47801/is-there-any...
Re: CLI: Improved
#255Earlier quoted context omitted.
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!
Sure! Take a look at Mix.Task [0]. You basically name your module Mix.Tasks.X where X is whatever you want the command to be and then include "use Mix.Task" and implement the run function and you have now extended Mix. You call the task my running "mix X" and it will run the code in the run function. I created a small task that generates ORM models for Ecto (Elixir's de facto ORM library) using Mix tasks [1]. So the…
Re: CLI: Improved
#256Earlier quoted context omitted.
view is also perfectly good, it's vim's pager.
Isn't "view" just an alias to invoke vim on read-only mode (i.e. you can still edit the text, do anything else you can do on vim and then save the contents to another file instead of the original file)?
Re: CLI: Improved
#257Earlier quoted context omitted.
Sure! Take a look at Mix.Task [0]. You basically name your module Mix.Tasks.X where X is whatever you want the command to be and then include "use Mix.Task" and implement the run function and you have now extended Mix. You call the task my running "mix X" and it will run the code in the run function. I created a small task that generates ORM models for Ecto (Elixir's de facto ORM library) using Mix tasks [1]. So the…
Ah ha! Thanks. So yeah, if you have an executable in your PATH named cargo-foo, then “cargo foo” will execute it. But we’re planning on having that style of functionality in the future as well, the cod name is “tasks”, but it still doesn’t have an RFC.
Re: CLI: Improved
#258Earlier quoted context omitted.
>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…
Sure it makes sense. Just put `gvim /dev/stdin` in the pipeline you desire and write to stdout when you're done. You can add to your configuration to remap `ZZ` (which usually saves the file and exits) to `:wq! /dev/stdout` when stdout is not a terminal. I'm going to do that when I get back to my computer.
Re: CLI: Improved
#259Earlier quoted context omitted.
>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…
I think you could use rofi for that, just insert it to the pipes and filter accordingly.
Re: CLI: Improved
#260Earlier quoted context omitted.
I'm asking because although I know Rust is likely to be faster than Go, I'm interested in the amount of difference.
You might be interested in Ben Boyter's journey to write a source code line counter: https://boyter.org/posts/sloc-cloc-code/ https://boyter.org/posts/why-count-lines-of-code/