201–210 of 280 posts
Can we use the term text user interface (TUI) and not CLI for stuff talked about here. I don't like the confusion and I think TUI I'd appropriate, just because something is launched by command line doesn't make it a CLI. A CLI is good for pipes, these things are interactive post start.
atop > htop https://www.atoptool.nl/
At the end of the article csvkit is given an honourable mention. I’m a big fan and I’ve used it a lot in the past, but these days I’d say that xsv > csvkit for working with CSV files on the command-line. https://github.com/BurntSushi/xsv
Earlier quoted context omitted.
> It seems you also chose to output line numbers by default in that case, but it's nice that you have -N. Right. When you run ripgrep with its output connected to a tty, then its output is "prettified." That means results are grouped by file, colorized and include line numbers. But if you aren't connected to a tty, then ripgrep reverts to the standard grep format (e.g., no line numbers). This means you should be able…
> When you run ripgrep with its output connected to a tty, then its output is "prettified." That means results are grouped by file, colorized and include line numbers. But if you aren't connected to a tty, then ripgrep reverts to the standard grep format (e.g., no line numbers). That sounds both good (for direct use) and bad (for developing scripts) at the same time. And it's a general pattern. I wonder, is there a s…
I don't think this has been an issue for me yet, but it has tripped some people up, yes. Overall, I think it's worth it.
Earlier quoted context omitted.
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.
Plain text was chosen to interface the various programs of Unix OSes because it's the least common denominator all languages share. It also forces all tools to be composable with each other. You can take output text that was obviously not formatted for easy consumption by another program and still use all the information it outputs for input into another program. Programs that were only thought to have users handling…
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
Earlier quoted context omitted.
Errmm, yes, I'm familiar with the difference in motivations behind the tools. I guess what I'm looking for is specific examples of things that cause you to use grep instead of ag. Ubiquity is a good one. But let's say you have both ag and grep. When do you reach for one and why? (I should have said this in my first comment, but I'm the author of ripgrep, and I'm just generally interested in learning more about the di…
Because ripgrep is the reason I discovered Rust (along with xsv for CSV manipulation) and because Andrew asked: % grep "die()" * [...results with functions named die()...] % rg "die()" Error parsing regex I reach for grep when I need to do non-regex searching. Can't remember how to do an fgrep fixed-pattern style ripgrep. great tools andrew: I use them every day and install them first thing on a new box. know that yo…
For ripgrep, you can enable literal search the same way you do it in grep: with the -F flag.
Thanks for responding!
Earlier quoted context omitted.
> It seems you also chose to output line numbers by default in that case, but it's nice that you have -N. Right. When you run ripgrep with its output connected to a tty, then its output is "prettified." That means results are grouped by file, colorized and include line numbers. But if you aren't connected to a tty, then ripgrep reverts to the standard grep format (e.g., no line numbers). This means you should be able…
> When you run ripgrep with its output connected to a tty, then its output is "prettified." That means results are grouped by file, colorized and include line numbers. But if you aren't connected to a tty, then ripgrep reverts to the standard grep format (e.g., no line numbers). That sounds both good (for direct use) and bad (for developing scripts) at the same time. And it's a general pattern. I wonder, is there a s…
Earlier quoted context omitted.
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…
Who is going to write "configuration and system scipting" if it isn't for humans? Ansible playbook reads very easily to humans.
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…
I manually counted a few files for comparison, I believe tokei doesn't understand python-doc-comments and think it's code.
alias o="fzf --preview 'bat --color=always {}' | xargs -i '{}' xdg-open '{}'"