[spc476]

I did a Forth-like Unix shell in college (mid 90s) as a class project [1]. The differences I see from mine are:

1) I made Unix commands a first-class variable type. You could create a single Unix command and store it into a variable. You could also set up several commands as a pipe, and save that into a variable.

2) redirection and pipes are more Forth in style. Much like adding two values:

    2 3 +

To create a pipe, you create the two commands and then pipe them:

    cmd1 cmd2 |

I'm looking over the code, and I don't think I finished redirection to tell the truth, but I can see it being easy to add it like:

    cmd1 "filename" |

since variables are typed in my Forth-like language.

It was a fun project to write (it even included history!) but as a practical shell? Not so much. The syntax left much to be desired for an interactive shell.

[1] Unix systems programming. The class project was a Unix shell. I had, by that time, already written a Forth-like programming language on my own [2], which meant I could do the advanced shell (programmable) instead of the simple shell (command execution and redirection only).

[2] I was seriously interested in Forth at the time.

[cowile2]

Hello, everyone. I would have responded sooner but I spend most of my workday in a closed network for security reasons (defense contractor), and don't have much internet access over the course of the day.

There is nothing stopping Forsh from being used that way. The convenience words from the README use a global variable to tell them where to build commands and overwrite the memory for every new command because the common case is that you as a user don't really care much about having arbitrary history (In any case, gforth already uses readline, so I get history for free). The words underneath all take that location as an argument on the stack. You could write some words that allocate space for each new command without changing the underlying libraries.

The key to thinking about pipe words in Forsh is that they execute a given command and consume and/or leave a file pointer to a command's stdout on the stack. This is why there are multiple pipe words. They have different stack effects.

`>|` (begin pipeline) only leaves a file pointer. `|` (continue pipeline) consumes and leaves a file pointer. `|>` (end pipeline) only consumes a file pointer.

This allows the pipe words to interoperate with any file I/O words in gforth.

If you want to "save a command to a variable", you just use a regular Forth word. [bracket] words make things work in compile mode.

`: hack [c] echo [p] hack! $ ;`

Executing hack will then build and execute the command. This also works with arbitrary pipeline fragments.

I did my best with syntax, but existing shells have already aggressively minimized typing for short commands. The most I could do was have people type `l ` instead of `--` for long options and `s ` instead of `-` for short options. However, I find quoting much improved over existing shells. You specify the quote character when you type the command, so there is no escaping. You just pick a character that doesn't exist in the string. You are ok as long as your string does not included every printable ASCII character.