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

101–110 of 280 posts

Re: CLI: Improved

#101

Post by adambyrtek »

burntsushi wrote: post #57
pletnes wrote: post #53

Earlier quoted context omitted.

ag is made to search code specifically. grep is a more general purpose text search tool and better suited (imho) for handling data (in contrast to code). Also, it’s always installed. I’ve never been on a machine with ag unless if I’ve installed it myself.

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…

Personally, I often use grep to filter results of a pipeline:

  some | commands | grep ERROR
In fact I do this so often that I have it aliased to g:

  alias g=grep
Maybe I could achieve the same with ack/ag/ripgrep, but I somehow mentally associate these tools with searching over a filesystem.

Re: CLI: Improved

#103

Post by jolmg »

adambyrtek wrote: post #101
burntsushi wrote: post #57

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…

Personally, I often use grep to filter results of a pipeline: some | commands | grep ERROR In fact I do this so often that I have it aliased to g: alias g=grep Maybe I could achieve the same with ack/ag/ripgrep, but I somehow mentally associate these tools with searching over a filesystem.

They're really meant for the same thing. You can also search the filesystem with grep by using -R and providing a path explicitly like `grep -R pattern .`.

EDIT: The real differences (at least the most important ones for me) between grep and these tools are 1) they format filesystem searches better for human viewing, 2) they provide more useful defaults, 3) in the case of ag, you can specify a max line width to avoid the terminal being filled by a matching line that has a ridiculous length, which typically happens with generated files, 4) they're supposed to be faster although I personally don't have searches big enough to notice the difference, but I imagine it's a big deal to others.

Re: CLI: Improved

#106

Post by jetti »

adwhit wrote: post #94
dijit wrote: post #35

Earlier quoted context omitted.

I wonder if there's a name for this phenomenon. New and not-popularly adopted languages tend to have more senior people learning and developing software using them; this leads to people (read: recruiters) looking for the people with experience.. People equate the quality of software with something innate with the language, or that the developers are exceptional. Then after being popularly adopted it slumps in perceiv…

A more generous interpretation might be that Rust has sparked a CLI renaissance, since it lets developers write CLIs that have that satisfying zip that previously was only possible in C. None of PHP, Ruby or Java is responsive enough for a good CLI tool (also, static compilation is a must for wide deployment).

Not to mention you get a language that is enjoyable but also compiles to native code. My first Rust project was a Haml parser and I created a CLI for it too that is similar to the Ruby version. It is nice being able to ship the 8Mb executable and not have to worry about users having the right runtime.

Re: CLI: Improved

#107

Post by jolmg »

IshKebab wrote: post #83
FactolSarin wrote: post #26

Earlier quoted context omitted.

I have co-workers who work on a big intranet web application that runs on IIS, and they never touch it. They recently finally switched to git for source control, and they want to do everything via GUI. I've tried to show them how some things are just easier/better from the command line, but if something isn't doable via GUI, they won't do it. One of them keeps committing line endings differently than everyone else, a…

Git has such a terrible command line that most things are easier in (good) GUIs than on the command line. The only exceptions I can think of are interactive rebase which has a weirdly good command line interface and is really confusing in every GUI I've tried; and continuing/aborting rebase and cherry picks when there is a conflict. And that's only because most GUIs don't bother to actually implement that properly an…

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 lines, just like how ag/ack/rg improve grep's output format for human viewing.

There's also a long-standing bug in `git log --graph` that causes the lines of the graph to sometimes move back to the previous line at the end of a commit description.

I love the -p/--patch option that's available in many subcommands. It's really quick to work with.

What specific things do you not like about git's CLI?

Re: CLI: Improved

#108

Post by gpmcadam »

bronlund wrote: post #48

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 :)

Few from my aliases file that may help:

   7   │ alias ..="cd .."
   8   │ alias ...="cd ../.."
   9   │ alias gcd="cd (git rev-parse --show-toplevel)"
The first two should be self explanatory.

The third one will take you to the "git root" of a directory structure, i.e. the top-level folder where the .git directory is (I find this grounds me for when I'm doing git commands.)

Re: CLI: Improved

#109

Post by v_lisivka »

vram22 wrote: post #91
skissane wrote: post #70

Earlier 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…

http://www.xml.com/pub/2000/06/07/xmlterm/

Re: CLI: Improved

#110

Post by gpmcadam »

Thanks for sharing. I'm always looking for ways to improve my CLI experience and there's some gems in here that I've not come across before.
Post reply on HN