4 ms·

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 aut

by joepvd 12y ago

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.

laumars 12y ago
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.
- jeroenjanssens 12y ago
  Hence the interrobang in the title. I hope that someone smarter than me can alleviate those two issues.
  - laumars 12y ago
    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.
- zokier 12y ago
  > This would also rule out ncurses and such like. 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.
  - laumars 12y ago
    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.
    - zokier 12y ago
      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/ 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 :)

by joepvd 12y ago

laumars 12y ago

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.

jeroenjanssens 12y ago
Hence the interrobang in the title. I hope that someone smarter than me can alleviate those two issues.
- laumars 12y ago
  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.
zokier 12y ago
> This would also rule out ncurses and such like. 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.
- laumars 12y ago
  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.
  - zokier 12y ago
    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/ 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 :)