The shok command shell

  • 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.

  • 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.

  • 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.

  • 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...

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

    [3] http://scsh.net/

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

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

    http://fishshell.com/

  • 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.

  • 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.

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

    (Actually plan9 rc is earlier than that.)

  • Looks like tclsh to me.

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

  • Looks like tclsh to me.