
The  shok  command shell - nfoz
http://shok.io
======
xyzzy123
Actually, TempleOS has a really neat command-line / shell.

The command line feeds directly into the C compiler. The C compiler can JIT,
and the "HolyC"[1] language has modifications which make it much nicer for
command-line use.

The author added default args to C, and parentheses are optional on functions
with no arguments (or all default) so:

    
    
        Dir; is shorthand for Dir("*.*", FALSE);
    

Even cooler, it's possible to go in and edit the Dir command on the fly; since
it's JITed, your changes will be there the next time you run it.

[1] OK, the name is quirky but most of the changes from C have sound reasons.

~~~
adestefan
The VxWorks shell is similar, but not as advanced. It's basically a stripped
down C interpreter and you call functions directly instead of commands.

------
stormbrew
I don't honestly find the pain point to shell scripting languages, in terms of
programming them, to be that they don't look enough like 'real' programming
languages. I think that on a basic level the way that posix shells work is
quite natural for the tasks they're expected to perform. There's even a
certain elegance to things like [ being (potentially) a program that behaves
as any other would.

It is quite primitive as languages go, though, and has some ugly quirks, but I
think it's a mistake to look at it and say it needs to be changed to be more
like things not designed to treat running programs as primitives. I'd rather
see something from someone who said "bash is great but could be so much
better!" than someone who said "bash is TEERRRRRUUUBLE and we must replace
it!"

That said what I want so much more than a new shell is one that isn't stuck
letting me only reason about the machine I'm logged in on. There's been a few
things that call themselves distributed shells, but they're really more
orchestration tools.

~~~
xiaq
Shells are what people use every day, so it's tempting to make more out of it.
grep, sed and awk are clumsy tools, but they are more "within the reach" than
python or ruby.

Also, you miss one particularly elegant aspect of shell programming: the
pipeline. It's a powerful facility of concatenative programming, but most
people haven't realize it. Try to write "find . -name '*.py' | xargs cat | wc
-l" in other languages. You end up either with some parentheses or
intermediate variables or a loop, and in any case, much longer code.

~~~
icebraining
> Try to write "find . -name ' _.py ' | xargs cat | wc -l" in other
> languages._
    
    
      import pipe
      find(name='*.py') | xargs(cat) | wc().lines
    

The implementation of the functions is left as an exercise for the reader, but
the syntax is valid.

[https://github.com/JulienPalard/Pipe](https://github.com/JulienPalard/Pipe)

~~~
stormbrew
> The implementation of the functions is left as an exercise for the reader

This is kind of the point.

------
Osiris
I've always been a bit surprised by the lack of innovation in *nix shells.
Despite huge advancements in technology, bash is pretty much the same as it
was ~25 years ago. Personally, I use fish shell everywhere I can, including on
my Mac and Linux servers. Bash scripting works, but this idea looks to make
scripting a much simpler and more straight-forward task.

~~~
midas007
Have you tried zsh?

~~~
xiaq
zsh is not innovative. It's overgrown.

~~~
midas007
Define innovative. One major goal of any shell is to get nasty shit done as
fast as possible. Conventions accreted over time and breaking those too much
diminishes the viability of an alternative project.

rush Ruby Shell [1] might qualify, but it has the problem of any "innovative"
shell: different special syntax and doing something so different that the
transition curve is too steep for most people.

Zsh is kind of weird because it feels academic with the option of having every
feature imaginable AND not having hashes or signatures with releases. The good
thing about zsh is that most of it isn't loaded by default. It has modules. It
has lots of neat options lacking in other shells such as case-correction and
interactive completion. That's all kinds of innovative.

Bash is the mysql of shells. It's pervasive so there's loads of pressure not
to innovate.

I would like to see shells' community get more like node by having minimal,
focused packages of added functionality that each do one thing well, because
having to declare the same primitive functions to do something DRY and useful
is a pain.

[1]
[https://adam.heroku.com/past/2008/2/19/rush_the_ruby_shell/](https://adam.heroku.com/past/2008/2/19/rush_the_ruby_shell/)

------
reirob
I am happy to see some effort going into the shell domain. I hope that the
authors of shok will look into some other non-POSIX shells that are almost
forgotten now, but in my eyes would really deserve to live on: ES [1] and [2]
and SCSH [3] and [4].

[1] [http://stuff.mit.edu/afs/sipb/user/yandros/doc/es-usenix-
win...](http://stuff.mit.edu/afs/sipb/user/yandros/doc/es-usenix-
winter93.html)

[2] [https://github.com/wryun/es-shell](https://github.com/wryun/es-shell)

[3] [http://scsh.net/](http://scsh.net/)

[4]
[https://github.com/scheme/scsh/network](https://github.com/scheme/scsh/network)

~~~
xiaq
And psh: [http://gnp.github.io/psh/](http://gnp.github.io/psh/)

------
qwerta
There is also fish (friendly interactive shell). It has been around for a
while, so it is in most linux distributions:

[http://fishshell.com/](http://fishshell.com/)

------
kingmanaz
Though a Unix stalwart, I am finding the developments in PowerShell exciting.
In particular, the concept of PSDrives, or filesystems which reside "inside"
of a program and which the shell can connect to for standard hierarchical
navigation and object/method execution. This makes little sense for a system
which strictly adheres to the Unix philosophy, ie., all programs perform one
task and are so simple that the concept of a PSDrive would expose nothing that
would provide benefit. However, personal *nix, like Windows, now frequently
run large GUI applications which would benefit by having their complexity
exposed through a PSDrive.

Perhaps the open source community is currently working on something like
PowerShell's PSDrives, but adoption by the teams producing large apps would be
critical to its success.

Anyway, the AREXX ports from the AmigaOS era are back again. The world has
come full circle.

~~~
xiaq
> Perhaps the open source community is currently working on something like
> PowerShell's PSDrives, but adoption by the teams producing large apps would
> be critical to its success.

plan 9 ([http://plan9.bell-labs.com/plan9/](http://plan9.bell-
labs.com/plan9/)). Virtually all of plan9's system services are exposed as
filesystem servers ([http://plan9.bell-
labs.com/sys/man/4/INDEX.html](http://plan9.bell-
labs.com/sys/man/4/INDEX.html)). Some of these may astonish you - a windowing
system, a FTP client, an SSH server, an authentication agent... Overall, the
system is much simpler than PSDrive - PSDrive providers are full-fledged .NET
objects, plan9 FS are just directory structure plus text files. Yet they
achieve roughly the same thing. (Actually plan 9 does more, but I believe in
principle PSDrive can be used to do these as well.)

Similar things (exposing system service as fs) is actually possible in Linux
or BSD, with FUSE. You can actually wrap utilities and expose them as file
servers, and there has been some limited success. But as long as upstream
utilities are not adopting the FS as the _primary_ API (which is unlikely), I
don't think it's really going to take off.

------
busterarm
What are the advantages of using this vs using the REPL of a mature language
like Ruby that already lets you execute shell commands?

I find myself using %x() while in irb all the time.

~~~
nfoz
I think a shell is where running programs is the default, and writing code is
secondary. In shok, the code is a DSL for filesystem and job management. I
think that's quite a different type of thing than general-purpose scripting
languages like Ruby.

My typing barrier for %x(ls) is too high.

~~~
busterarm
but Ruby is perfectly suited to writing a DSL. There's a large and growing
number of system administration tools that use Ruby to do exactly that.

You could totally make Ruby turn ": ls" into "%w(ls)", or whatever other
symbol.

This just seems a lot more work for the same thing.

~~~
nfoz
Sure, but go the extra step: Drop the mandatory :, make just "ls" run ls. Then
you need a syntax to get at the programming language, not the other way
around. That's all that's happening here.

shok could have put ruby or python or some other language behind its {}
syntax. That would be less NIH-syndrome, but maybe there's merit to trying
something more ambitious. Or maybe not.

~~~
mattengi
How about support shebang style block?

{#!python

    
    
        do dome python...
    
    }

------
xiaq
Finally, a Unix shell whose name doesn't end in "sh".

(Actually plan9 rc is earlier than that.)

~~~
UNIXgod
KORN

~~~
xiaq
It's usually known as ksh, isn't it?

------
zwischenzug
Looks like tclsh to me.

~~~
kingmanaz
My thought as well. Though mocked at work for using Tcl/Tk, I have been
employing the language for personal projects successfully over decades.

------
platz
would be nicer if it borrowed syntax from a subset of an existing high-level
language

~~~
hnriot
host> python

that's all you need. ls is a little more tricky but nothing that a very simple
init.py couldn't fix, then you'd have the full and awesome power of python to
do shell things. We don't need a new *sh that half assed implements a language
otherwise we'll just end up with another syntactically primitive language like
bash, zsh, etc.

~~~
frou_dh
Maybe it turns out brilliant and we realise we do need it.

