Here it is!

For the moment it can only execute piped commands, it doesn't even have variables or string substitution, and the only builtin is cd. The main innovation, though, is a special kind of pipe, called The Pizza.

It looks like this:


What the above code is doing is changing all occurrences of "linux" or "Linux" to "GNU+Linux", then printing everything.

One complex example is the following:


This one changes all occurrences of "Dave" to "Ben" and "Ben" to "Dave" in parallel, then prints the whole file in rainbow colors!

This should become more useful after implementing variables, variable substitution and shell substitution. Stay tuned, and share your impressions!

To run it, make sure you have rustc and cargo installed, then run

So, basically, you implemented the first version of UNIX pipes again?

A fellow sourcehut user, good man :)

As a Perl diehard, I say the more regular expression processing the better!

Well, that was the idea. The shell is about dealing with text output from various programs that are connected through pipes. Why not provide the tools to manipulate the text output too?

It also works as an AWK alternative. If you don't put anything before the pizza operator, it will read from stdin.


Turns into this:

jkl Wrote:So, basically, you implemented the first version of UNIX pipes again?

The stuctural regular expression stuff is implemented too. The examples I gave actually work in the shell.

That's really nice. :-)

Why did you choose to implement it as a shell rather than an interpreter like awk, or sed?

z3bra Wrote:Why did you choose to implement it as a shell rather than an interpreter like awk, or sed?

As far as I know, there is no awk or sed using structural regular expressions, like sam does. My first intention was to build one. Then, I realised that it should be a full blown shell, because a shell's job is mainly to process output from different programs, which is usually text in the unix world. I feel that a shell without powerful text processing, or a text processor without powerful shell functionality, is incomplete. Both sh and awk are scripting languages, with variables, control structures, and both operate around string values. Why separate them?

Thus, I created (or I am in the process of creating) a complete shell. You can use it as a shell, you can use it as a text filter, you can use it for both. Text and processes are first class citizens.

Quote:shell's job is mainly to process output from different programs

I disagree with that. The shell's job is to handle IPC, and that's it. Text processing is done by the processes themselves, the shell only connects outputs to the next process input.
Otherwise, you're creating a full blown text processor, that happens to have a way to start processes.

I love the structural expression approach, but I think you should focus on that rather than making a complete shell. That wouldn't make much difference:


would then be (reusing sed's flags):

z3bra Wrote:The shell's job is to handle IPC, and that's it. Text processing is done by the processes themselves, the shell only connects outputs to the next process input.

In theory, yes. In practice, virtually all shell scripts deal with text processing and filtering by calling grep, sed, awk and the others. These text processing programs are pointless without a shell to call them, and a shell is pointless without text processing programs or routines to handle the output of the other programs it is calling.

I am making an awk-like program. Shell pipes are just a small convenience, they don't add too much complexity.

The challenge that I'm facing is to make it work on a stream of text. Sed and awk operate on lines, structural regular expressions operate on characters or the whole text.

(12-05-2019, 11:32 AM)z3bra Wrote: I disagree with that. The shell's job is to handle IPC, and that's it. Text processing is done by the processes themselves, the shell only connects outputs to the next process input.

What it's "job" is is quite secondary, as compared to what makes it useful as a tool. A shell that only would handle IPC would have no variables, aliases, functions, built-in commands and would hence be an all around pain to work with -- even more than a standard "minimalist shell". If there's no real reason to restrict yourself (such as having a typewriter instead of a screen, a PDP7 instead of *any modern day computer*), it's nonsense to reject developments and advances on the grounds of something that's basically a naturalistic fallacy of computing.

(12-05-2019, 11:32 AM)z3bra Wrote: Otherwise, you're creating a full blown text processor, that happens to have a way to start processes.

And what is the problem with that? I don't mean to be rude, but I honestly don't understand the problem. Especially considering the history that Unix has with text processing.

(18-05-2019, 01:12 PM)zge Wrote:

(12-05-2019, 11:32 AM)z3bra Wrote: I disagree with that. The shell's job is to handle IPC, and that's it. Text processing is done by the processes themselves, the shell only connects outputs to the next process input.

What it's "job" is is quite secondary, as compared to what makes it useful as a tool. A shell that only would handle IPC would have no variables, aliases, functions, built-in commands and would hence be an all around pain to work with -- even more than a standard "minimalist shell". If there's no real reason to restrict yourself (such as having a typewriter instead of a screen, a PDP7 instead of *any modern day computer*), it's nonsense to reject developments and advances on the grounds of something that's basically a naturalistic fallacy of computing.

(12-05-2019, 11:32 AM)z3bra Wrote: Otherwise, you're creating a full blown text processor, that happens to have a way to start processes.

And what is the problem with that? I don't mean to be rude, but I honestly don't understand the problem. Especially considering the history that Unix has with text processing.

Don't get me wrong, I do not reject it at all! I love structural expression, and find such a tool to be a godsend actually, as I don't know any of awk, and sed is a pain to work with multi-line patterns.

What I meant is that handling processes and processing text are two different tasks, and I do believe in the "one tool for each task" moto.
There are plenty of shells out there that are pretty good at managing jobs. We do lack a good structural expression tool though, so I would advise focusing on this part, and have it integrate well with other tools, rather than implementing missing features inside it.

Also, I really want to use it, but I don't wanna swap my shell :)
Now to use it from another shell in a pipeline, you need something like (I suppose):

In this fashion, I think it will have difficulties gaining adoption (and I hope it would get adopted!)

I didn't mean to be rude or rant about the tool. I though about how I'd use it myself and the little irks I would have with it (again, regarding my workflow, and I think Unix workflows in general).

Sorry if I hurt anyone, I didn't mean to

z3bra Wrote:Also, I really want to use it, but I don't wanna swap my shell :)
Now to use it from another shell in a pipeline, you need something like (I suppose):

Code:

echo "I run Linux" | rwsh -c 'cat |> ,x/[lL]inux/ c/GNU+Linux/ |> ,p' | tee linux.txt

That's actually useless use of cat, if the pizza pipe doesn't have anything on its left, it reads from stdin. I also want to make the p at the end implicit, and add formatting capabilities so it doesn't become useless. With these two optimizations, it doesn't feel awkward anymore.

It is also one of my points to make it embeddable in other workflows, to be as versatile as awk.

Anyway, another point of this project is to learn from it and have fun. It's the first time I implement any kind of scripting language, and the first time I'm playing with Rust. I am also writing this to compete in a national software competition for high school students, for pride and accomplishment!

A more polished tool will be the result of this effort. It's all opensource, everyone can look, learn, share, contribute, fork.

Thank you z3bra and zge for contributing to the discussion, more to come!