Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CLI: Improved

remysharp.com

Post reply on HN
Print view View original

181–190 of 280 posts

Re: CLI: Improved

#181

Post by h1d »

another-cuppa wrote: post #13

"bat" is not a better version of cat, it's a completely different tool. cat is short for concatenate. If you want to view a file use less, and if you want syntax highlighting etc. then use view (comes with vim).

I'm starting to use vimpager after realizing I don't feel good seeing 2 different coloring on the terminal and in vim, instead, this way, whatever your vim supports (color, utility, key binding) can be carried over as a pager.

The project is still rough around the edges but mostly good.

https://github.com/rkitover/vimpager

Re: CLI: Improved

#182

Post by h1d »

sharkdp wrote: post #99
geoalchimista wrote: post #20

Earlier quoted context omitted.

> if you want syntax highlighting etc. then use view I'd like to recommend pygmentize also for syntax highlighting. Works like cat and supports a lot of languages. But since pygmentize is written in Python, it may not run as fast as bat. (I haven't tried bat though, because pygmentize is fast enough for my daily use cases.)

I have written a short (and definitely subjective) overview of the different alternatives here: https://github.com/sharkdp/bat/blob/master/doc/alternatives....

Add vimpager?

Re: CLI: Improved

#183

Post by TeMPOraL »

jniedrauer wrote: post #119
barbegal wrote: post #51

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…

I disagree about objects being preferable to text in a shell. Text is very easy to reason about, and you can quickly determine what transformations you need to make based on visual feedback. Working with objects means spending a lot more time in the documentation learning what properties you have to work with. In a programming language, it's obviously no context. But in a shell, I want to spend more time doing and le…

> Text is very easy to reason about, and you can quickly determine what transformations you need to make based on visual feedback. Working with objects means spending a lot more time in the documentation learning what properties you have to work with.

Or not. Take `ps`. You'll need to spend time in documentation anyway, figuring out what process properties can be shown with what flag, and then you'll be bitten later by things like the difference between `ps ux` and `ps aux` including process names in square brackets, etc. Contrast with PS equivalent, `Get-Process`. Type `Get-Process | Get-Member` to list properties of the objects returned by `Get-Process`, and you can quickly see both properties you can inspect (with descriptive names, not "VSZ" or "RSS") and what methods you can call directly (instead of extracting properties and piping to other programs).

This is IMO much cleaner, easier to work with interactively (properties instead of constant parsing and unparsing of text), better for interoperability (you're limited by what actual objects expose, not by what pieces of them a CLI program wishes to print, and if it so happens that objects somehow print more than they expose in properties, you can still call ToString() on them and get that data "the UNIX way"), and correctly separates presentation from content.

The only real drawback I've seen of Powershell is the lack of quality-of-life scripts and executables in the system. Like the md5 example elsewhere in this thread.

Re: CLI: Improved

#185

Post by BozeWolf »

tambourine_man wrote: post #127

Nice list, but I tend to keep my stuff as close to default as possible. The feeling of not being at home on a new box outweighs the benefits of customizations, in most of the cases. I do have a huge .vimrc and some bash niceties, but I found it better for me to exercise some customization discipline overall.

Yes i do exactly the same thing!

Re: CLI: Improved

#186

Post by TeMPOraL »

burntsushi wrote: post #120
jolmg wrote: post #60

Earlier quoted context omitted.

Well there's the portability of grep which is better for scripts. Besides that, most if not all times I do a simple `ag pattern file`, I'm interested only in the results and not in the location. I'm probably preparing the pattern to output something to provide to another command via stdin or substitution and at those times (which is also in the interactive command line), I want to see exactly what I'm going to pass i…

> 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 standard UNIX/Linux way of saying "run this, but pretend I'm not connected to a tty"?

Re: CLI: Improved

#187

Post by pjmlp »

h1d wrote: post #171
pjmlp wrote: post #162

Earlier quoted context omitted.

Of course, because someone wrote a md5 executable for you to call. You can do the same on PowerShell and write a pipeline just the same way.

You're right that a shell alone can't calculate md5 but a separate md5 binary does it for you, but the question still stands when the common answer on the internet seems to be to write that cryptic code as that's probably the easiest way provided on PowerShell. The best alternative I could find is some community maintained PowerShell extension (with just 177 GitHub stars now), which is far better but the lack of inte…

Powershell is based on the REPL ideas of Lisp Machines and Smalltalk.

- structured data

- ability to call any public function across dynamic libraries, COM objects and .NET frameworks

- Powershell modules can also be called as plain .NET code

Which UNIX shell provides this?

Re: CLI: Improved

#188

Post by h1d »

Anyone know of a good markdown viewer that is formatted instead of showing the source with colors?

I'm using pandoc to convert it to groff and read it like a formatted man page, which is ok but not great as it loses some formatting.

  pandoc -s -f markdown -t man markdown.md | groff -T utf8 -man | less -R

Re: CLI: Improved

#189

Post by lloeki »

unscaled wrote: post #137
jolmg wrote: post #107

Earlier quoted context omitted.

I find git to be one of the best CLI programs I've ever used. There are a few things I don't like, like how `git blame` requires me to put my terminal in fullscreen to see the output properly. I wish there was an option to make the output group changes of a commit together. It could put the commit details on a line before and add a single character prefix to all lines to differentiate between file lines and commit li…

The CLI for Git is one of the most confusing CLIs I've ever seen. I can describe all the warts here, but other did that better than me: http://stevelosh.com/blog/2013/04/git-koans/ Besides the inconsistencies, there are many gotchas which keep tripping developers. For instance, git pull always tries to merge in the remote branch, but you almost never want that. You can do: git pull --ff-only, but most developers I kn…

Fire and forget as part of team setup guidelines:

    git config --global pull.ff only

Re: CLI: Improved

#190

Post by lloeki »

mikewhy wrote: post #117
jolmg wrote: post #107

Earlier quoted context omitted.

I find git to be one of the best CLI programs I've ever used. There are a few things I don't like, like how `git blame` requires me to put my terminal in fullscreen to see the output properly. I wish there was an option to make the output group changes of a commit together. It could put the commit details on a line before and add a single character prefix to all lines to differentiate between file lines and commit li…

> What specific things do you not like about git's CLI? The biggest for me is staging lines. In GitHub desktop you click the line numbers, in the command line (iirc) you navigate through chunks as they appear in the file, maybe splitting them into smaller chunks and hopefully can get it down to what you want.

In git add --patch you can do `e` to edit the hunk interactively, and this help comment appears:

    # To remove '-' lines, make them ' ' lines (context).
    # To remove '+' lines, delete them.
    # Lines starting with # will be removed.
I wish tig would have a line-by-line marking feature that would do just that behind the scenes, to make it more accessible.
Post reply on HN