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

121–130 of 280 posts

Re: CLI: Improved

#121

Post by skissane »

ratboy666 wrote: post #98
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…

I am not sure how this would work. rsh/ssh may be involved. I wouldn't even know how to express: ssh carthoris ls /mnt/media/Movies | grep Spider (this is just an example). Note that in this example, we have two processes running on two different machines. Indeed, the OSs and systems on these machines may be, um... different. Indeed, I routinely include "cloud" machines in pipelines. Indeed, with ssh, the -Y (or -X)…

> I am not sure how this would work. rsh/ssh may be involved.

In order for this to work over SSH, the SSH client and server would need to be enhanced to exchange this data, and also an SSH protocol extension would need to be defined to convey it across the network.

One might define IOCTLs that work on pipes and PTYs to send/receive control messages. So sshd would read control messages from the PTY and pass them over the network, and the SSH client would receive them and then pass them on to its own stdout using the same ICOTLs. (Alternatively, one might expand the existing control message support that recvmsg/sendmsg supply on sockets to work on pipes and ptys as well.)

Any program supporting such an out-of-band signalling mechanism would have to gracefully degrade when it is absent. If your SSH client or server, or some program in your pipeline, or your terminal emulator, etc, doesn't support them, just fall back on the same mechanisms used today to determine output/input formats.

(rsh is such a deprecated protocol, there would be no point in trying to extend it to support something like this.)

Re: CLI: Improved

#122

Post by dflock »

bradknowles wrote: post #93
burntsushi wrote: post #55

Earlier quoted context omitted.

ripgrep definitely goes against the Unix philosophy. This is intentional. The Unix philosophy is a means to an end, and not an end unto itself. The key way that ripgrep violates the Unix philosophy is that it couples the filtering of what to search with the act of searching. You hit the nail on the head with styling, because the output of ripgrep is itself the thing that prevents composability. However, from my own o…

Which I can then pipe to "gron" so that I can make something sensible and greppable out of that json output, right? ;)

Well, you could pipe it to "jq" - https://stedolan.github.io/jq/

Re: CLI: Improved

#123

Post by onemanstartup »

euank wrote: post #80
Mizza wrote: post #72

Another tool I use religiously: `autojump` (aliased to `j`) rather than `cd`. It learns where you go and lets you fuzzy-jump there. https://github.com/wting/autojump I also use `loop`, my own Rust-based replacement to bash's native loops: https://github.com/Miserlou/Loop

I've found fasd ( https://github.com/clvv/fasd ) to be the most featureful of the directory jumping tools, and it's much faster than autojump as well. I'd be remiss not to mention pazi however, which is the tool I wrote to replace fasd in my own workflow: https://github.com/euank/pazi It's similar to autojump, but much faster: https://github.com/euank/pazi/blob/master/docs/Benchmarks.md... Oh, and it's written in rus…

https://github.com/gsamokovarov/jump You can benchmark this tool to be fastest

Re: CLI: Improved

#124

Post by epage »

vram22 wrote: post #63
steveklabnik wrote: post #34

Earlier quoted context omitted.

IIRC, loc (in rust) might be even faster than tokei at times? I always forget, and I’m sure I saw an old benchmark... We have a whole working group this year focused on making the experience of writing CLIs awesome, so hopefully we’ll see even more great tools in the future!

>We have a whole working group this year focused on making the experience of writing CLIs awesome Can you explain what you mean by this? Something like the people are going to focus on language and library features that help with writing CLIs? Or something else? Asking because CLIs are one of my interests.

We've tried to dig into various problematic areas of writing CLIs in Rust [0], worked to create or improve libraries [1], and are working on writing a "book" for Rust-based CLIs [2].

You can reach out to us on gitter [3].

[0]: https://github.com/rust-lang-nursery/cli-wg/issues

[1]: https://github.com/rust-clique/ and https://github.com/assert-rs/

[2]: https://rust-lang-nursery.github.io/cli-wg/index.html

[3]: https://gitter.im/rust-lang/WG-CLI

The areas we're trying to finish up for Rust 2018 Edition:

- Get clap (arg parsing) to 3.0 [4]

- Get assert_cmd [5] / assert_fs [6] to 1.0

- Finish work on man-page generation [7]

- Make it easier to package binaries [8] and document the CI for it [9]

[4]: https://github.com/rust-lang-nursery/cli-wg/issues/41

[5]: https://github.com/assert-rs/assert_cmd/

[6]: https://github.com/assert-rs/assert_fs

[7]: https://github.com/rust-lang-nursery/cli-wg/issues/38

[8]: https://github.com/crate-ci/cargo-tarball

[9]: https://github.com/crate-ci/crate-ci.github.io

Re: CLI: Improved

#125

Post by jedieaston »

brirec wrote: post #78
alexeldeib wrote: post #54

Earlier quoted context omitted.

This made me chuckle, because it's incredibly accurate. I started with bash and am still naturally more comfortable there for general purpose work. PowerShell is annoyingly verbose sometimes and has its own WTF moments, but there are waaay fewer surprises when working with complex scripts and variables.

It’s not included anywhere, but PowerShell is open source and you can install it on *nix now! Obviously the things that integrate with Windows aren’t there, but the object-oriented pipelining sure is.

I believe the AD and Azure tools work, and the other ones needed for remotely managing Windows Server, although I could be wrong.

Re: CLI: Improved

#126

Post by braindongle »

There's the convenience of these tools, then there's convenience of having a small number of non-standard tools to carry along with you, however easy that may be.

For example, for any diff'ing or cat-like need, I find it SUPER handy to just pipe stdout to vim like so:

$> thing-with-output-that-needs-navigating | vim -

I'm not an Emacs user, but my impression is that over in that world, the shell integrations are crazy good.

Re: CLI: Improved

#127

Post by tambourine_man »

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.

Re: CLI: Improved

#128

Post by jaco8 »

vram22 wrote: post #115
adwhit wrote: post #94

Earlier quoted context omitted.

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

You would be very, very pleased with Nim.

https://nim-lang.org/

Re: CLI: Improved

#130

Post by JoshMnem »

nextos wrote: post #96
JoshMnem wrote: post #77

Earlier quoted context omitted.

> Tools like e.g. mutt are little silos and don't compose that well. I've migrated to emacs, where the userland is much more composable. What do you use for reading email in Emacs?

Notmuch, which is IMHO superb and totally underrated. I like it a lot due to its clever architecture. It never ever touches your email. It operates on a separate tag database. Then, it's the task of a backend to translate tag changes into maildir actions before and after syncing email. Keeping tag to actions decoupled from the GUI is extremely clever, because it allows implementing basically any email workflow you ca…

Thanks, I'm in the process of migrating from Thunderbird to mutt/neomutt and am wondering if emacs might have advantages. I already use Emacs for Org Mode.

I'm also looking for a scriptable, text-based RSS reader: https://community.codeselfstudy.com/t/text-based-rss-atom-fe...

Post reply on HN