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

Cicada – Unix shell written in Rust

github.com

Post reply on HN
Print view View original

131–140 of 168 posts

Re: Cicada – Unix shell written in Rust

#131

Post by Skunkleton »

peteretep wrote: post #70

Apologies for the off-topic nature of this, but: Something that's been capturing my imagination recently is sshing into a machine, pushing an appropriate shell binary to /tmp, and then executing it. If you have an exotic preference for shell (or vim config, or whatever), we've presumably generally got sufficient bandwidth these days to do a virtually instant user-space install and execution, no?

I wouldn't copy binaries between arbitrary systems (specific systems is fine), but copying configs is pretty easy with SSH as-is:

  #!/bin/bash -x
  HOST=$1
  scp -o ControlMaster=auto -o ControlPersist=30 ~/.vimrc $HOST:~/.vimrc
  ssh -o ControlMaster=auto -o ControlPersist=30 $HOST
With the above, you will only create one SSH connection, and you will only authenticate once.

Re: Cicada – Unix shell written in Rust

#132

Post by johnny22 »

brandur wrote: post #3

Amazing work! Between this, Alacritty [1], and coreutils [2], we're getting pretty close to a plausible all-Rust CLI stack. While Cicada is pretty clearly modeled on the "old" generation of shells (sh, Bash, Zsh, etc.), one has to wonder what a more modern shell might look to address some of the problems of its predecessors like pipes that are essentially text-only, poor composability (see `cut` or `xargs`), and terr…

hotwire tried it too. it's been dead for awhile though. https://code.google.com/archive/p/hotwire-shell/wikis

Re: Cicada – Unix shell written in Rust

#133

Post by johnny22 »

yorwba wrote: post #62
jstimpfle wrote: post #47

Earlier quoted context omitted.

There isn't a 1:1 mapping of binaries to documentation or completion scripts. That idea won't work out. "Defining a standard format" hasn't been a successful practice in the Unix world. Many standards consist essentially of the bare minimum that everybody can agree with. Unix command-line interfaces are already structured (as a list of strings), and more structure would be hard to support at the binary level. There a…

If the binary is using one of a few common libraries, e.g. GNU getopt, to read its command-line parameters, it should be possible to extract somewhat useful completions automatically. Then you are essentially relying on the de-facto standard of not rolling your own argument parsing, as opposed to some product of a standards committee.

fish shell does it with manpages https://fishshell.com/docs/current/commands.html#fish_update...

Re: Cicada – Unix shell written in Rust

#134

Post by eridius »

Drdrdrq wrote: post #130
eridius wrote: post #121

Earlier quoted context omitted.

I just have to say, while I respect the work put into tools of the sort that you use, the first thing I do is see if it's GPL or not and if it is it immediately loses points (very nearly all of them), because GPL is awful. If I'm going to use a tool like this, I'm going to want to be able to check out the code, perhaps submit PRs, etc, but if it's GPL then I don't want to so much as look at the code because GPL is vi…

No, "freedom for the user" is exactly what it says. GPL cares about end user, not so much about developer. Original developer just gets to decide which group is more important in his particular case.

Read what I said. The "end user" doesn't care in the slightest about source access. Everything the GPL is concerned about only matters to other developers, not to end users.

Re: Cicada – Unix shell written in Rust

#135

Post by tomjakubowski »

peteretep wrote: post #70

Apologies for the off-topic nature of this, but: Something that's been capturing my imagination recently is sshing into a machine, pushing an appropriate shell binary to /tmp, and then executing it. If you have an exotic preference for shell (or vim config, or whatever), we've presumably generally got sufficient bandwidth these days to do a virtually instant user-space install and execution, no?

The team I work on had similar needs†, so we built a tool, atop the Python library fabric, to sync a project to (multiple) remote machines, build it, and execute it with configurable command line arguments.

http://github.com/Oblong/obi

†: the specific use-case was for development of multi-machine GUI applications that run in configurations like "display walls" or "immersion rooms". for every developer to have their own "display wall" or "immersion room" would cost lots of $$$, so many of the design decisions were based around the needs of a team of N developers that "shares" these systems.

Re: Cicada – Unix shell written in Rust

#136

Post by int_19h »

still_grokking wrote: post #65
int_19h wrote: post #45

Earlier quoted context omitted.

Powershell does two things right: it uses structured output, and it separates producing the data from rendering the data. It also does one thing wrong: it uses objects (i.e. the stuff that carries behavior, not just state). This ties it to a particular object model, and the framework that supports that model. What's really needed is something simple that's data-centric, like JSON, but with a complete toolchain to def…

> What's really needed is something simple that's data-centric, like JSON, but with a complete toolchain to define schemas and perform transformations, like XML (but without the warts and overengineering) . What would it be? Is there a real alternative to XML with those features out there? I don't think so. When you would want to have the features of XML and would design it from scratch I'm quite sure it would have t…

> When you would want to have the features of XML and would design it from scratch I'm quite sure it would have the complexity of XML again.

I don't think so. The problem with the XML stack is that it has been designed with some very "enterprisey" (for the lack of better term) scenarios in mind - stuff like SOAP. Consequently, it was all design by committee in the worst possible sense of the word, and it shows.

To see what I mean, take a look at XML Schema W3C specs. That's probably the worst part of it, so it should be readily apparent what I mean:

https://www.w3.org/TR/xmlschema11-1/ https://www.w3.org/TR/xmlschema11-2/

The other problem with XML is that it's rooted in SGML, and inherited a lot of its syntax and semantics, which were designed for a completely different use case - marking up documents. Consequently, the syntax is overly verbose, and some features are inconsistent for other scenarios - for example, if you use XML to describe structured data, when do you use attributes, and when do you use child elements? Don't forget that attributes are semantically unordered in XDM, while elements are ordered, but also that attributes cannot contain anything but scalar values and arrays thereof.

Oh, and then don't forget all the legacy stuff like DTD, which is mostly redundant in the face of XML Schema and XInclude, except it's still a required part of the spec.

I guess the TL;DR version of it is that XML today is kinda like Java - it was there for too long, including periods when our ideas of best practices were radically different, and all that was enshrined in the design, and then fossilized in the name of backwards compatibility.

One important takeaway from XML - why it was so successful, IMO - is that having a coherent, a tightly bound spec stack is a good thing. For example, with XML, when someone is talking about schemas, you can pretty much assume it's XML Schema by default (yes, there's also RELAX NG, but I think calling it schema is a misnomer, because it doesn't delve much into semantics of what it describes - it's more of a grammar definition language for XML). To transfer XML, you use XSLT. To query it, you use XPath or XQuery (which is a strict superset). And so on. With JSON, there's no such certainty.

The other thing that the XML stack didn't quite see fully through, but showed that it could be a nice thing, is its homoiconicity: e.g. XML Schema and XSLT being XML. Less so with XPath and XQuery, but there they had at least defined a canonical XML representation for it, which gives you most of the same advantages. Unfortunately, with XML it was just as often a curse as it was a blessing, because of how verbose and sometimes awkward its syntax is - anyone who wrote large amounts of XSLT especially knows what I'm talking about. On the other hand, at least XML had comments, unlike JSON!

Hey, maybe that's actually the test case? A data representation language must be concise enough, powerful enough, and flexible enough to make it possible to use it to define its own schema and transformations, without it being a painful experience, while also being simple enough that a single person can write a parser for it in a reasonable amount of time.

Re: Cicada – Unix shell written in Rust

#137

Post by ams6110 »

skissane wrote: post #27
vog wrote: post #24

Earlier quoted context omitted.

Nice idea! Maybe this issue is similar to that of command completion, but could also result in a similar mess. Every command has its "-h" or "--help", showing the syntax, available options and so on. But since even that is not really standardized, separate command-line completion rules are written for every command. And for every shell.

Define a standard format for describing command syntax. I'd suggest basing it on JSON, but you could use XML or Protobuf or Thrift or ASN.1 or Sexprs or whatever. Embed in executables a section containing the command syntax description object. Now when I type in a command, the shell finds the executable on the path, opens it, locates the command description syntax section (if present), and if found uses that to provi…

This sort of exists. The command syntax format is the standard man page "Usage" and "Options" sections, and an implementation is docopt (http://docopt.org/)

Re: Cicada – Unix shell written in Rust

#138

Post by jancsika »

leeoniya wrote: post #98
notheguyouthink wrote: post #94

Earlier quoted context omitted.

I'm not too familiar with licensing, can someone ELI5? Eg, normally I just choose MIT because licensing is not a concern of mine. I'd like credit, but beyond that, do whatever the hell you want with my work. Now, I'm not making core nix tools, but should I be choosing a different license? Man do I hate licensing.

"The Software shall be used for Good, not Evil." clause made JSLint's license incompatible with MIT [1]. "He has, however, granted "IBM, its customers, partners, and minions" permission "to use JSLint for evil", a solution which appeared to satisfy IBM's lawyers." :D Given IBM's history of making Jew-counting machines for the Germans during WWII, that exception is particularly disturbing. Also JSON [2]. [1] https://e…

> "The Software shall be used for Good, not Evil." clause made JSLint's license incompatible with MIT [1].

This is so frustrating. One of Crockford's most persuasive points in his writing and lectures about Javascript is that computer programs are no place for self-expression. When he explains what is wrong with the language, he gives astute suggestions on foolproof ways to workaround the language's weak points by avoiding ambiguity. He's even written JSLint to help the programmer do just that without having to research every idiosyncratic pitfall that would come from just winging it.

Yet here he is-- in a domain for which he has absolutely no expertise-- expressing himself in a licensing clause. Causing measurable hours of waste because Debian or IBM or insert-org-here has no experience with his idiosyncratic license and no easy way to predict what are its effects.

Re: Cicada – Unix shell written in Rust

#139

Post by jtolmar »

skissane wrote: post #25
vidarh wrote: post #23

Earlier quoted context omitted.

I lean towards wanting all my tools to support at least one common structured format (and JSON generally would seem the best supported) these days. It'd be great if there was a "standard" environment variable to toggle JSON input/output on for apps. If you did that, then e.g. a "structured" shell could just default to turning that on, and try detecting JSON on output and offering according additional functionality. T…

I wish there was a way for pipes to carry metadata about the format of the data being passed over the pipe, like a MIME type (plain text, CSV, JSON, XML, etc). Ideally with some way for the two ends of the pipe to negotiate with each other about what types each end supports. I think that sort of out-of-band communication would most likely need some kernel support. Maybe an IOCTL to put a pipe into "packet mode" in wh…

I'd prefer a "crash if receiver doesn't support sender's MIME type" model for debugability.

Which could still be ergonomic if all the common piping programs supported some specific collection of formats and there was a relatively robust format-converting program.

Re: Cicada – Unix shell written in Rust

#140

Post by goodplay »

eridius wrote: post #134
Drdrdrq wrote: post #130

Earlier quoted context omitted.

No, "freedom for the user" is exactly what it says. GPL cares about end user, not so much about developer. Original developer just gets to decide which group is more important in his particular case.

Read what I said. The "end user" doesn't care in the slightest about source access. Everything the GPL is concerned about only matters to other developers, not to end users.

As an end-user, I do. Being prevented from fixing my own (expensive) device is not something I would voluntarily subject myself to. For context, here's a comment I posted a while ago (https://news.ycombinator.com/item?id=13527205):

I used to be a big fan of permissive licenses until I bought a $700+ android phone a couple of years back and discovered that it did not "support" my native language (it could render the glyphs but system-wide support was not enabled).

Having extensive experience with unicode and how text is usually rendered, I knew exactly how to fix the issue; the fix was likely as simple as injecting an SO that hijacks a specific system library function. However, because the phone was locked down, I was unable to fix the problem myself. All important system apps including SMS and the browser displayed gibberish.

It was the most expensive brick I ever bought. This experience taught me the true value of the GPL and why user freedom far outweighs the freedom of developers

Post reply on HN