Looks very interesting. Has anyone already jotted down some experiences from using the bash kernel in a support setting? It would be awesome to be able to autodocument explorations and fact finding, for oneself, and/or for other interested parties.
Sadly it doesn't look that practical for serious work just yet. Taken from the article:
> "Having inline Markdown, equations, and images sure is nice. However, in my opinion, the Bash kernel currently has two issues that hamper usability. First, the output is only printed when the command is finished; there are no real-time updates. This is especially inconvenient if you want to keep an eye on some long-running process using, say, tail -f or htop. Second, there's no interactivity with the process possible. This means that you cannot drop into some other REPL like julia or psql."
This would also rule out ncurses and such like.
These days it's pretty simple to set up SSH access (even view web shells if needs must) so having a proper Bash access is possible without this project.
However I don't mean to be negative about this project as it does bring some new features to the table that SSH / regular terminal emulators don't support.
Without looking at the code, I'd guess these two issues are actually just symptoms of the same problem. It will be down to the way you're shell executing your commands.
Python isn't my strongest language, but there will be other ways to launch an external process while forwarding STDERR / STDOUT streams in real time. Maybe instead of forking a shell, run the command as a process. You can still execute from within a shell using -c flag, eg
$ bash -c 'export a=$(echo "hello world"); echo $a'
hello world
$ echo $a # demonstrates that the envs aren't passed backwards
$
If you do this then you need to be careful about your quotes / escaping. But it would still be less work than reinventing a Bash script parser.
Some might argue that ncurses and it's ilk is an "antipattern" in itself, and not supporting them is a feature. Command line should be line-oriented as the name implies.
There's occasions when this "anti-pattern" pays dividends. While these aren't ncurses specifically, examples of the this paradigm include:
* pagers (eg more and less). Handy if you want to navigate large blocks of text
* browsers (eg lynx and elinks). Handy for quick spot checks on headless servers and want formatting preserved (which rules out curl and wget)
* text editors (eg vi/m, nano and emacs). I shouldn't even need to explain the requirement for these, but a few examples are included in the next bullet point:
* anything that uses $EDITOR (eg visudo and crontab -e). While you can edit these files without vim (et al) and still use these tools to check your edits before committing them, it is considerably more work for something that's otherwise really very easy
* some monitoring tools (top et al). Though I will grant you that there are other (sometimes better) ways to probe this information. But let's not begrudge a sysadmins prerogative to be lazy ;)
* REPLs, (eg RDBMS SQL command lines (mysql, pgsql, etc), Python, etc). You could probably argue against the "need" for many imperative / functional REPLs, but database command lines are extremely useful.
* some interactive package managers (eg aptitude, yaourt) which are useful if you have bespoke queries (eg you don't know the name of a package you wish to install so you need to combine repository searches with install requests). It's also worth noting that even apt-get will occasionally jump into an interactive mode (eg using ncurses for requesting mysql passwords or prompted installs when doing distribution upgrades.
This is by no means a conclusive list, and certainly more detailed than I think your comment perhaps deserves.
I'll try to answer each point, but these ideas are not really fully thought out. They are more just food for thought how things could be done differently (and hopefully better). I feel like nobody has seriously tried to improve this area, so the ecosystem support is obviously lacking. No true scotsman etc applies.
> pagers (ebrowsers (eg lynx and elinks). Handy for quick spot checks on headless servers and want formatting preserved (which rules out curl and wget)g more and less). Handy if you want to navigate large blocks of text
Pagers would be far better suited to be implemented on client side (="terminal"). Although I'm not sure if paging should be just merged into text editors. Seems like there is huge amount of overlap between the two. Vimpager is one such attempt.
> browsers (eg lynx and elinks). Handy for quick spot checks on headless servers and want formatting preserved (which rules out curl and wget)
Linemode (http://line-mode.cern.ch/) style browser should be enough for command line, especially with client side paging.
> text editors (eg vi/m, nano and emacs). I shouldn't even need to explain the requirement for these, but a few examples are included in the next bullet point
> anything that uses $EDITOR (eg visudo and crontab -e). While you can edit these files without vim (et al) and still use these tools to check your edits before committing them, it is considerably more work for something that's otherwise really very easy
There is no reason why $EDITOR couldn't be set as a full-blown graphical text editor. If we are talking about remote systems, I do wish there was some convenient way to pass open file descriptors (or something of similar effect) over ssh. This also would kinda mesh with what I said about pagers.
Kinda related is the emacs-daemon stuff. I haven't experimented with it enough, but I think you should be able to tunnel it over ssh to enable transparent editing of remote files, which is cool and the direction we should be going.
> some monitoring tools (top et al). Though I will grant you that there are other (sometimes better) ways to probe this information. But let's not begrudge a sysadmins prerogative to be lazy ;)
One kinda cool solution for these kind of applications could be small web applications that are designed to be run on-demand and tunneled over ssh (or accessed locally) instead of the more traditional persistent applications sitting behind proper web server etc. It would help if we had some simple scaffolding to support this mode of operation, e.g. a flag to ssh that set up the tunneling etc, launched the application, and then launched browser automatically without needing to fiddle with port numbers and whatnot manually. If we really wanted to push something like this then we could even develop something like HTTP over stdio.
> REPLs, (eg RDBMS SQL command lines (mysql, pgsql, etc), Python, etc). You could probably argue against the "need" for many imperative / functional REPLs, but database command lines are extremely useful.
Funny to mention REPLs in a thread about web-based (kinda) REPL. Beside that REPLs generally are mostly line-based to begin with, with the exception of readline. And for readline, that functionality could again be pushed to client/terminal ("local line editing"). Of course getting all the functionality of readline to work locally would be an interesting challenge.
> some interactive package managers (eg aptitude, yaourt) which are useful if you have bespoke queries (eg you don't know the name of a package you wish to install so you need to combine repository searches with install requests).
Same solution as for the monitoring applies. But I might add that various forms of (remote) GUIs imho could use more work. Where is the GUI equivalent of ncurses, both in simplicity and lightweightness? And just to clarify GUI does not imply some silly mouse driven skeuomorphic WIMP, another thing that seems ignored too often.
> It's also worth noting that even apt-get will occasionally jump into an interactive mode (eg using ncurses for requesting mysql passwords or prompted installs when doing distribution upgrades.
There is more than their (unnecessary) use of ncurses to dislike here.
> This is by no means a conclusive list, and certainly more detailed than I think your comment perhaps deserves.
I hope this comment, even with bit stream-of-consciousness tendencies, is more satisfactory to you. I probably should learn to write (properly) and set up a blog instead of ranting on HN. Or better yet, shut up and code. But this is easier :)
I completely disagree with your argument there. Pagers are about more than just scrollback (eg quick regex navigation). Sure these things could be built into your terminal emulator, but what's the point when pagers already do it so well?
In fact, I find myself moving away from being dependant on any specific terminal emulator and instead using tmux. So I'm very much of a different camp when it comes to arguments about where to add terminal features.
> linemode browser
That's still interactive so it's no better than lynx nor elinks with regards to the point you were making
> $EDITOR
How is launching a GUI program from the command line any better than running an ncurses program? All you're doing is engineering a complicated replacement solution for something that's already very easy. And lets not forget that launching X11 apps from the command line only works if you have specific envvars populated, which can be a pain if you ever need to su - user for any reason.
> SSH tunnelled HTTP monitoring tools
You can already do that if you want, but it's more overhead and complexity (both in terms of protocol and document markup) than running an ncurses monitoring tool - and for no practical benefits either.
> REPLs
"Beside that REPLs generally are mostly line-based to begin with, with the exception of readline."
I think you have that backwards. All REPLs are readline or similar - hence them being a language shell (Python, SQL, Lisp) and rather than just language one liners (eg awk, sed, Perl). I will grant you that terser languages tend to lend themselves better to REPL than the more verbose languges, but REPL doesn't require a syntax optimised for one liners - and nor are any language REPLs designed purely for one liners.
> "Where is the GUI equivalent of ncurses, both in simplicity and lightweightness?"
ncurses is the GUI equivalent. It might be seen as ugly to some because it uses character sprites instead of vectors and bitmaps, but it's still a basic graphic user interface.
> "I hope this comment, even with bit stream-of-consciousness tendencies, is more satisfactory to you."
Sorry, but no it doesn't. I'm all for the "many ways to do the same thing" philosophy, but you've completely ignored the KISS approach and decided to reinvent the wheel with significantly more complicated tools. The only benefit your solutions offer over the examples I'd given was that you can prove that these things can be done outside of the command line - which was never in question to begin with. However you've not addressed my points about the simplicity of these terminal-based applications. Instead you've kind of accidentally agreed with them given how "clunky" your alternatives are in comparison.
