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

111–120 of 280 posts

Re: CLI: Improved

#111

Post by chriswarbo »

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…

> 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 will pop up in the middle of the pipeline, allow you to interact with them, and then any data output from them will go to the next component in the pipeline

There seems to be some precedent for this sort of thing. For example, DVTM can invoke a text editor as a "filter", where the editor UI is drawn on stderr and result saved to stdout.

Re: CLI: Improved

#112

Post by jolmg »

AnIdiotOnTheNet wrote: post #42
nextos wrote: post #28

GNU Parallel is the first thing I usually install on top of a standard Unix userland. It's almost a superset of xargs, with many interesting features. It depends on perl, though. htop is also pretty much a great replacement for top. And ripgrep a great replacement for the find | xargs grep pattern. Aside from that, I'm pretty content with the Unix userland. It's remarkable how well tools have aged, thanks to being co…

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 its input and output (ncurses apps) can also be forced to be used by programs through things like the expect TCL program or Ruby's expect library.

If programs used typed data, they'd still need the option to output text to present results in a format the user can understand. To do this, a negotiation protocol could be established, like skissane said. This, in my opinion, is BAD, because then there's the possibility or probability that they'll be differences in the information conveyed in the different formats.

I believe that the use of plain text as the universal format of communication between programs is one of the greatest design decisions for Unix and CLI.

Re: CLI: Improved

#113

Post by [deleted] »

AnIdiotOnTheNet wrote: post #42
nextos wrote: post #28

GNU Parallel is the first thing I usually install on top of a standard Unix userland. It's almost a superset of xargs, with many interesting features. It depends on perl, though. htop is also pretty much a great replacement for top. And ripgrep a great replacement for the find | xargs grep pattern. Aside from that, I'm pretty content with the Unix userland. It's remarkable how well tools have aged, thanks to being co…

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.

[deleted]

Re: CLI: Improved

#114

Post by knewter »

khalilravanna wrote: post #39
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…

I just went through this with most of the engineers at our company as they're mostly .NET devs. It's an ongoing process but I basically gave a big talk open to questions on how to use git, all the commands, and the benefits of using the CLI. Thankfully they have a willingness to learn and become better developers and so it's been going pretty smoothly outside of a couple hiccups where I had to step in and perform git…

I took it as a given they'd found such a company already

Re: CLI: Improved

#115

Post by vram22 »

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

FreePascal has been around for a long time and supports CLI programming. Maybe not very much support in the basic language and stdlib, but the essentials are there (CLI arg handling and file I/O). Third-party libraries may have more and you can always write your own. Both speed and size of binaries are good. I had compiled some simple CLI programs and they were under 100K, maybe under 50K. It's also supposed to be quite cross-platform, though I have not checked that out.

Also, I don't know Rust (but have read that it is somewhat difficult to learn); for the basics, FreePascal (FP) may be easier than Rust to learn and start using, because although it (FP) has advanced language features, for many basic CLI programs, the simpler procedural features should be enough.

https://freepascal.org/

Re: CLI: Improved

#116

Post by vram22 »

vram22 wrote: post #85
orf wrote: post #29

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…

Have you done any comparison (even informal) of similar tools written in Rust and Go?

I'm asking because although I know Rust is likely to be faster than Go, I'm interested in the amount of difference.

Re: CLI: Improved

#117

Post by mikewhy »

jolmg wrote: post #107
IshKebab wrote: post #83

Earlier quoted context omitted.

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 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.

Re: CLI: Improved

#118

Post by burntsushi »

vram22 wrote: post #116
vram22 wrote: post #85

Earlier quoted context omitted.

Have you done any comparison (even informal) of similar tools written in Rust and Go?

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/

Re: CLI: Improved

#119

Post by jniedrauer »

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 less time reading.

Re: CLI: Improved

#120

Post by burntsushi »

jolmg wrote: post #60
burntsushi wrote: post #33

Earlier quoted context omitted.

If you don't mind me asking, in roughly what cases do you reach for grep instead of ag || ack? Is it a familiarity thing, or specific features or something else?

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 to use ripgrep in pipelines pretty much exactly like you would use grep. It just does the right thing. You can test this easily by comparing the output of `rg ` with `rg | cat`. ag also does this to some extent (by disabling grouping and colors), but does still include line numbers in most cases.

> do you have an option like ag's undocumented -W which allows specifying a max line width for which a matching line is displayed?

Yes. That's the -M/--max-columns option. I have that set by default in my config:

    $ cat ~/.ripgreprc
    --max-columns=500
    --colors=match:bg:0xff,0x7f,0x00
    --colors=match:fg:white
    --colors=line:none
    --colors=line:fg:magenta
    --colors=path:fg:green
    --type-add=got:*_test.go
Note:

    $ echo $RIPGREP_CONFIG_PATH
    /home/andrew/.ripgreprc
Post reply on HN