51–60 of 168 posts
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.
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'…
ps: I kinda like powershell (the few hours I toyed in it
Earlier quoted context omitted.
> 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.
It looks like libxo does the output in structured format, but what about input? (For chaining commands together with pipes). Did the FreeBsd porting work[1] implement the input side with libxo, independently of libxo, or not at all? (Not to diminish libxo --it looks pretty cool, and I didn't know about it before-- just curious.) [1]: https://wiki.freebsd.org/LibXo
There's also this project: https://github.com/redox-os/ion It's intially build with RedoxOS (in Rust as well) underneath, but now also runs on Linux. Seems to be a bit more mature. I wonder what sets these two projects apart, and/or if the devs of Casada know of Ion's existence.
What they have in common though… is that job control (Ctrl+Z) is not implemented yet :(
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…
The approach I took to my shell was to pass JSON objects about as the primary data type but fall back to text streams when the data doesn't look like JSON. The problem with passing objects around though is it can cause issues with the parallel nature of pipes. ie the programs in a chain of pipes can run concurrently since the data is being passed is just a stream. But with objects you need to read the object in its e…
[1] https://github.com/playframework/play-iteratees [2] http://www.reactive-streams.org/
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'…
sexp ? ps: I kinda like powershell (the few hours I toyed in it
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…
> like pipes that are essentially text-only Pipes work fine with binary data, you just need to be piping to a tool that works with binary data rather than text e.g. cat | openssl base64
openssl base64 On the plus side, you do get a prize for suggesting it [1]
Something involving bulk binary data moving over a pipe which isn't an indirect redirection would be:
gzip somefile | ssh user@host "gunzip >somefile"
Although, again, there's a perfectly good -c flag to SSH that would do the same thing.
Probably the most common example of tool-to-tool binary communication over pipes is:
find -print0 | xargs -0
Earlier quoted context omitted.
The approach I took to my shell was to pass JSON objects about as the primary data type but fall back to text streams when the data doesn't look like JSON. The problem with passing objects around though is it can cause issues with the parallel nature of pipes. ie the programs in a chain of pipes can run concurrently since the data is being passed is just a stream. But with objects you need to read the object in its e…
The problems could be tackled nicely by a clean functional solution like Iteratees[1], maybe with a hight-level API like Reactive Streams[2]. [1] https://github.com/playframework/play-iteratees [2] http://www.reactive-streams.org/
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'…
Earlier quoted context omitted.
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.
Or the author justifiably thinks that a shell shouldn't support functions?