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

31–40 of 168 posts

Re: Cicada – Unix shell written in Rust

#31

Post by valarauca1 »

withjive wrote: post #4
rocky1138 wrote: post #2

Looks fully featured! Cool stuff. I think people are going to ask "Why?" and "What's the difference between this and bash?" Might want to cover that in your README.

The fact that there is a "Won't do list" stating that functions won't be supported... I don't think this is anything more than a toy to play with rust.

Generally speaking anytime you start to breakout bash/zsh/sh/csh functions you've already entered a zone where just writing a python/perl script would be the easier and a more maintainable solution in the long term.

Re: Cicada – Unix shell written in Rust

#32

Post by ori_b »

vidarh wrote: post #23
vog wrote: post #12

Earlier quoted context omitted.

The so-called "plain text formats" are also just representations of complex objects. Often these formats are ad-hoc and hard to parse correctly. Multiple text files in a file system hierarchy (e.g. /etc) are also just nested structures. So in principle, treating those as complex object structures is the right way to go. Also, I believe this is the idea behind D-Bus and similar modern Unix developments. However, what'…

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…

> It'd be great if there was a "standard" environment variable to toggle JSON input/output on for apps.

Look at FreeBsd's libxo. It's supported by most of the base system.

Re: Cicada – Unix shell written in Rust

#33

Post by valarauca1 »

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…

This is called a "Unix Domain Socket" they're 20+ years old.

Re: Cicada – Unix shell written in Rust

#34

Post by panic »

ori_b wrote: post #30
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…

> 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`) A new system and set of utilities. None of the Unix environment works in that world, and shoehorning it in would feel incredibly clunky.

If you use bytes that are invalid in UTF-8 (e.g. 0xF5-0xFF) as delimiters / structure characters, you can use text-only tools to do structured operations on UTF-8 strings without ever having to escape anything -- the structural "characters" you would need to escape can never appear in the encoded bytes.

Re: Cicada – Unix shell written in Rust

#35

Post by ori_b »

panic wrote: post #34
ori_b wrote: post #30

Earlier quoted context omitted.

> 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`) A new system and set of utilities. None of the Unix environment works in that world, and shoehorning it in would feel incredibly clunky.

If you use bytes that are invalid in UTF-8 (e.g. 0xF5-0xFF) as delimiters / structure characters, you can use text-only tools to do structured operations on UTF-8 strings without ever having to escape anything -- the structural "characters" you would need to escape can never appear in the encoded bytes.

The Unix shell operates on binary streams, not on text.

Re: Cicada – Unix shell written in Rust

#36

Post by coldtea »

whatnotests wrote: post #13
Whil- wrote: post #8

Earlier quoted context omitted.

It seems a bit premature to say that PowerShell was passed over. The journey outside Windows has just started. Indeed, PowerShell is onto something. Such delight it is to work with. Especially when you start to build your own tools for it.

It's been 16 years.

16 years that it has only been available for Windows, the parent says.

Re: Cicada – Unix shell written in Rust

#37

Post by zdkl »

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…

As counterpoint if only for the sake of my wetware memory, I'd rather have only a few pipes being as agnostic and generally capable as possible than complex plumbing.

I don't mean to argue there is no value in specialised adapters, but I believe the default should be as general as can be. Let me worry about parsing/formats at the application level and get me simple underlying pipes. If I need something specific I should be prepared to dig into docs and find out what I need anyway, so default text vs install or explicitely configure your system to use something else seems like a sane feature/complexity segregation in the general case.

EDIT: good quote from another thread to illustrate my point: > Removing the responsibility for reliable communication from the packet transport mechanism allows us to tailor reliability to the application and to place error recovery where it will do the most good. This policy becomes more important as Ethernets are interconnected in a hierarchy of networks through which packets must travel farther and suffer greater risks.

replace Ethernet with pipes and the point still has merit IMO. Lifted off of https://news.ycombinator.com/item?id=14675115

Re: Cicada – Unix shell written in Rust

#38

Post by zdkl »

vog wrote: post #12
zdkl wrote: post #7

Earlier quoted context omitted.

My structured objects aren't your structured objects. In that use case why not use a dedicated program (like say ae python/js/clojure interpreter) to handle more complex pipes and keep the shell level primitves... Well, primitive. Text is compatible with all systems, past and present, and can be used to model more complex objects. Let's not add features to the core on a "why not" please.

The so-called "plain text formats" are also just representations of complex objects. Often these formats are ad-hoc and hard to parse correctly. Multiple text files in a file system hierarchy (e.g. /etc) are also just nested structures. So in principle, treating those as complex object structures is the right way to go. Also, I believe this is the idea behind D-Bus and similar modern Unix developments. However, what'…

> in principle, treating those as complex object structures is the right way to go

I do not see this as a given. It's a matter of abstraction vs performance tradeoff and that is highly subjective. Unless you pioneer a new standard form for complex object notation this'll just end up back to a format flamewar.

(And if we go that way, I'd argue for s-exprs or -dare I say it- xml)

Re: Cicada – Unix shell written in Rust

#39

Post by codesnik »

vidarh wrote: post #23
vog wrote: post #12

Earlier quoted context omitted.

The so-called "plain text formats" are also just representations of complex objects. Often these formats are ad-hoc and hard to parse correctly. Multiple text files in a file system hierarchy (e.g. /etc) are also just nested structures. So in principle, treating those as complex object structures is the right way to go. Also, I believe this is the idea behind D-Bus and similar modern Unix developments. However, what'…

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…

jq is awesome. "json lines" data format (where each record is json without literal newlines, and newline separates records) nicely upgrades unix pipes to structured output, so you can mix old unix tools, like head, tail etc with jq. maybe what's needed is some set of simple json wrappers around core utils to increase adoption.

Re: Cicada – Unix shell written in Rust

#40

Post by ibotty »

ori_b wrote: post #32
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…

> It'd be great if there was a "standard" environment variable to toggle JSON input/output on for apps. Look at FreeBsd's libxo. It's supported by most of the base system.

Amazing! I did not know that.
Post reply on HN