It’s interesting to note that while no single idea is revolutionary, the design choices in putting together this bunch make for a particularly slick interface where the whole is much better than the usual shell.<p>PS: I look forward to trying this out! Since I don’t know much Common Lisp, are there particularly useful libraries that would make it easy to cover functionality commonly used through the shell? I’d love to see a tutorial with a compilation of examples. EDIT: Found some useful stuff in the CL cookbook (Eg. section on files & directories) <a href="https://lispcookbook.github.io/cl-cookbook/" rel="nofollow">https://lispcookbook.github.io/cl-cookbook/</a>
>Terminals have no reason to continue to be used in my opinion. Note that this does not mean we shouldn’t use “textual” interfaces, quite the opposite: textual data is a bliss to manipulate. But we can very well manipulate text, along with other types of data, in something other than a terminal, that is faster, prettier, more powerful. (Graphical Emacs is one such example.)<p>I have recently switched to Jupyter's qtconsole for my REPL needs - for me, it hits the sweet spot of supporting rich media and interaction without the overhead of running a full web browser stack. I could see it becoming the basis for a next-gen terminal.
While not as extreme as what is demonstrated here, I integrate things in my environment with Lisp in a way that is similar to this. I run StumpWM too so I can grab the content of the current X selection and do actions from it (e.g. the content matches a JIRA ticket regex, open it, the text matches a filename, edit it (fun fact, anything can be a filename), etc.).<p>For processes, I wrote something that is not finished, not polished, but if anyone want to steal from it, go ahead:<p><a href="https://github.com/christophejunke/pipeline" rel="nofollow">https://github.com/christophejunke/pipeline</a><p>This allows to spawn processes or threads to pipeline input/output, like done usually with | in shells<p><pre><code> (with-pipeline ()
(program "ls" (namestring (merge-pathnames "bin/" (user-homedir-pathname))))
(program "sed" "s/a/aaaa/")
(tee/error) ;; "tee" and output a copy to error
(program "wc" "-c")
#'read)
</code></pre>
<a href="https://github.com/christophejunke/pipeline/blob/master/tests.lisp#L9" rel="nofollow">https://github.com/christophejunke/pipeline/blob/master/test...</a><p>The nmcli.lisp example starts an nmcli process and filters its output to build Lisp objects representing connections:<p><a href="https://github.com/christophejunke/pipeline/blob/master/nmcli.lisp#L52" rel="nofollow">https://github.com/christophejunke/pipeline/blob/master/nmcl...</a>
I wonder what people think about Ammonite (<a href="https://ammonite.io/" rel="nofollow">https://ammonite.io/</a>)?<p>It's not Lisp but Scala so may not be the authors language of choice however it can be used as a Shell: <a href="https://ammonite.io/#Ammonite-Shell" rel="nofollow">https://ammonite.io/#Ammonite-Shell</a><p>I am personally using it and compared to a classical shell like Bash it's really nice for more structured data related tasks (exploring some API, checking some data, creating a bunch of PRs at once, ...).<p>It also makes use of Scala's adjustable syntax and functional concepts so you basically get shell piping but in a strongly typed fashion (e.g.
`ls.! |? (_.ext == "txt") | (os.read)` would produce a list of strings representing the contents of all files ending in .txt of the current directory).<p>Also I am curious what people think of PowerShell which as of PowerShell Core is usable on all platforms as well.
> Implement automatic ncurses detection to automatically start a “visual” program in a terminal, even when it’s not known in advance. Is it even possible?<p>There are a couple of techniques:<p>1) Check for use of certain escape sequences in the output.<p>2) Check PTY terminal modes using tcgetattr, especially for raw mode<p>I think combining (1) and (2) you could come up with some heuristics that would work 99% of the time, without hardcoding names of fullscreen apps or anything else like that.<p>(Really this isn't "ncurses detection" per se, you can have a full-screen terminal app without using any curses library.)
I don't get lisp. Actually I think I understand what people like about it. What I mean is that I don't know exactly how to "think in lisp". Is it like writing the AST instead of the text or describing what is needed instead of what needs to be done... I simply don't get it.<p>Not sure if I'm the only one though.
You may be forced to use Scheme as as shell when encountering an error booting GuixSD. Back in 2016, support was apparently not good for the AMD bulldozer systems I was trying to install on. The systemd alternative they used, GNU shepherd, crashed on me, and left me in a Guile REPL.
Back at uni I ran an experimental lisp shell. A few notes of what was painful and what worked.<p>Outer most parens should be optional, if you're running ls you don't want to type (ls).<p>Grouping flags, files and options is difficult: ls -lh file could become (ls (h l) file) (ls (flags h l) (files file)) (ls -l -h file) (ls -lh file) none of the options are particularly good or lispy.<p>You need a full editor on the command line. Shells are designed for teletypes, lisps are designed for glass terminals.<p>All in all not I'm sure that an s-expression based system is the right fit for a low level interface to the computer. That said I did enjoy my experiments a lot more than I did using shells. Were I to try it again I would have it is a higher level language that compiles down to a shell.
"rather novel paradigm" is where you lost me. TempleOS's integration with HolyC is more featureful than anything you've proposed and it was completed a few decades ago. The idea was surely older than that, too. I'm just pointing out a very well known case.<p>A bit late on the uptake, but welcome to the party of realizing that the shell is not be all end all of computing.