Hacker News Reader

Comment by gtf21 | Hacker News Reader

I don't really understand what's so different from the ZSH completions which I already have in my terminal but with no data leaving my machine?

View on HN

People who can configure their shells are not their target audience. For once, if you walk into any research center or academic environment and look over the shoulders of people who have to code or use a terminal because they have no other option, you would see that the vast majority know little beyond cd and ls. I wouldn't be surprised some would pay for directory completion alone.

Can those who know what zsh mean do a better job with existing tools or custom made scripts? 100%, but that doesn't matter.

Beyond that, you can level up even further by firing up Emacs and never again needing a terminal for things that require completion.

> if you walk into any research center or academic environment

If they use their institution's infrastructure, it's managed by the dedicated system admins. No way they're going to allow this tool to be installed.

While I have exactly 0% belief in the success of Fig, and share a lot of the negative sentiment expressed in this thread, your parent post does make a point.

I spent 10 years in the kind of academic setting described. A LARGE part of the work of the people in this example do their work on ordinary self-managed laptops without a sysadmin in sight (and probably very little common language in which to even begin communicating with a sysadmin, if they even know what a sysadmin is). The amount of time that is wasted by ordinary researchers being very uncomfortable with the terminal is staggering. Although I was/am a researcher in my own right, I do feel that I had an order of magnitude greater positive impact on research by helping out the approximate dozen of other researchers around me do their terminal and programming work more efficiently/better/smoothly/reliably.

I definitely think there's huge room for improvement in this area. But I don't think something like Fig is the answer; safe and effective use of Fig seems to require enough wherewithal to ask someone (or google) how to set up bog standard autocompletion solution in the first place.

There definitely is a point. I've witnessed too many biologists who decided to get into data analysis struggle with UNIX. I think https://missing.csail.mit.edu is more of an answer. Most graduate programs just assume you'd pick it up on your own, but the majority doesn't.

You install it in your own terminal on your own computer, not on the institutions' computers. Also, for research that doesn't handle personal identifiable information (think civil engineering or astronomy), I don't think it'd be an issue to have Fig read the parts of the filesystem to which admins gave you read access anyway. Hopefully autocomplete would work over ssh.

Perhaps, but then a better option would be to contribute back to the ecosystem by creating a nice DSL to compile back to zsh etc. completions and making a nice installer on top of that. I don't see how "autocomplete in your terminal" is really a company given that the people who would pay for tools like this will probably be power users, who would (I assume) prefer the built-in tools.

Traditional shell completions are quite difficult to make. Many CLI tools have completions for subcommands and options, but not for arguments. Only the big CLI tools like `git` and `docker` have arguments completions (e.g. git push [remote] [branch]`.

Fig's declarative schema makes building the completions for subcommands, options and arguments very easy. This means we can support much more powerful autocomplete for many more CLIs.

Fig's standard format also makes it possible to suggest shortcuts for standard workflows (similar to aliases but more visual).

Finally, zsh and fish have good support for traditional autocomplete, but bash does not. Fig works the same across all shells (even when in an SSH session or a docker container).

> Fig's standard format

How is that a standard when you just came up with it? Any other existing autocompletion format is more standard than whatever you just released.

Yep I mistyped. Meant to say standard "suggestion" format. Trying to imply that each suggestion conforms to a specific standard that we have set but that lets you customise things like the text it suggests, what is inserted, icon etc

So wouldn't a better solution be to make a nicer DSL for describing shell completions which is then translated into zsh, fish, etc. completions?

Agree RE bash but at some point doesn't one just use the tool with the featureset one wants?

That's how we think about the completion spec standard. It essentially is a type-safe DSL that describes the structure of CLI tools.

It should be pretty easy to 'compile' a Fig completion spec down to zsh, fish, or bash. This is actually something I've been meaning to write!

What exactly do you mean by even when in SSH or docker?

As in, if you SSH into a remote machine, Fig can offer completions for that remote machine. Same thing if you are running an interactive terminal for a docker container.

This image may help clarify: https://fig.io/images/slideshow/screenshots/ssh.png

This seems like black magic, but it really does raise a lot of questions about the telemetry issue. It's one thing to potentially leak information from your own machine, but leaking data from remote servers you ssh into requires a whole 'nother level of assurity around privacy.

That said, it's pretty attractive because it's much harder to make a case to install fish on remote servers.

I assume this is done by running 'ls' in the background and not showing the execution to the user, except as autocomplete suggestions?

if I type 'sudo cp ' will it run 'sudo ls' to offer suggestions?

this...is not good. my terminal should not be executing code on my behalf on remote servers I've SSHed to.

Reply on news.ycombinator.com