Butterfly: Your everyday terminal in your web browser | Hacker News Reader

Butterfly: Your everyday terminal in your web browser

paradoxxxzero.github.io

256 pointsp4bl085 comments

Just a note to the author if they are reading: you might want to remove that OSC code for inline HTML.

There are reasons dynamic codes like those don't exist. Good reasons. (In my own naivete, I once thought an OSC code to access scrollback would be a good idea. You can imagine how insecure that was). It's not a good idea to run any programs in this terminal until that OSC code is either removed or the HTML is somehow sanitized.

What's OSC? Open Sound Control? Open Source Code? I'm not familiar with that acronym.

It's a type of terminal escape code, designed to interact with the terminal emulator's environment.

https://en.wikipedia.org/wiki/ANSI_escape_code#Non-CSI_codes

"Operating System Command"

I think the concern is around this bit:

https://github.com/paradoxxxzero/butterfly/blob/4dc55630a3ab...

Is the problem that there's a potential for a terminal app to inject non-sanitized HTML into a terminal that is using butterfly?

Would be awesome if you could make a pull or open an issue.

https://github.com/paradoxxxzero/butterfly

Maybe the author ( as I ) is not sure about this or knows how to fix it.

Cheers

That OSC code might be the key to make this project really interesting and powerful. But you are right, to make this safe, some sanitization or other sandbox would be needed. This could be hard/impossible if there is JavaScript involved in the inline HTML.

To use this on a remote server without making it listen to the wild, keep it listening on localhost only and on your computer you could for instance launch this:

    ssh -Nf -L 9999:localhost:57575 remote-server

and then you can go to http://localhost:9999/ with ssh taking care the encrypted connection between you and the remote-server.

not being funny, but isn't the purpose of a web-based terminal to help give you access to a terminal-like environment when you don't have access to a standard terminal / ssh?

A use case (warning I've not thought his out very deeply)

Abe has shell access via 'ssh' to Server. He wishes Bob and Carol to have access to the server but for whatever reason they don't have SSH.

Abe shells in, does the trick for Bob and Carol. Bob and Carol can use the web-based ssh and are happy campers.

Or.

Abe controls the server via Puppet [Chef, Ansible]. Something you can do with Puppet is disallow SSH access - one does this to remove the temptation to 'cheat' and hand-config the system. Abe has the ability with Puppet to exec this command to let Bob or Carol (or Abe) into the system 'in case of emergency'.

At least one major security issue has already been discovered & fixed: http://www.reddit.com/r/linux/comments/1z6gif/butterfly_your...

It's a shame that this doesn't work in Windows, where a real terminal is desperately needed.

Having been forced to use powershell for a while (after being a bash lover), powershell isn't awful. No idea why it isn't default.

Powershell is a great shell, but the terminal it's running in (cmd) is still pretty mediocre...

Powershell has nothing to do with Command Prompt. it runs on the Windows console subsystem.

Whatever the case, it has all the limitations. Poor resize support, strange selection/paste support, and limited featureset.

They must be forks of each other if they're actually not distinct: compare the option screens.

What do you mean by "default"? They're both accessible from the Start Menu, and renaming PowerShell to cmd.exe would certainly cause some chaos.

I've been using cmder for a while, and it is awesome! Loads of cool features. It's worth checking out :)

http://bliker.github.io/cmder/

I also heard good things about console:

http://sourceforge.net/projects/console/

Why doesn't it work on windows? Couldn't you run it on your local linux server and access it from windows clients?

I think he means as a replacement for Powershell/Cmd.exe.

this is a terminal, not a shell

and powershell.exe and cmd.exe are both both terminals and shells

tty.js[1] works on windows (the backend is linked to the winpty library). I'd normally feel like I'm tooting my own horn by inserting this here, but it looks like the clientside part of Butterfly is a fork of my term.js[2]. I'm not sure if python's implementation of pty's handles some kind of workaround specifically for windows.

[1] https://github.com/chjj/tty.js [2] https://github.com/chjj/term.js

I wanted to try but got errors.

MSBUILD : error MSB3428: Could not load the Visual C++ component "VCBuild.exe". To fix this, 1) install the .NET Framework 2.0 SDK, 2) install Microsoft Visua l Studio 2005 or 3) add the location of the component to the system path if it is installed elsewhere. [E:\dev\node\term.js\node_modules\socke t.io\node_modules\socket.io-client\node_modules\ws\build\binding.sln] MSBUILD : error MSB3428: Could not load the Visual C++ component "VCBuild.exe". To fix this, 1) install the .NET Framework 2.0 SDK, 2) install Microsoft Visua l Studio 2005 or 3) add the location of the component to the system path if it is installed elsewhere. [E:\dev\node\term.js\node_modules\socke t.io\node_modules\socket.io-client\node_modules\ws\build\binding.sln]

Toot away! I'm working on an MMO which will have a coding component, so code like this is exactly what I was looking for!

I'm using ConEmu as a wrapper for standard cmd and cygwin, works well for my needs.

What features are you missing?

I don't quite understand the use of it. iPython Notebooks I get. They really give you something you don't get in a terminal widow, but I take my yakuake everyday before a web based terminal. It integrates better in the desktop environment, has global hotkeys, can be scripted via D-bus, doesn't need a server to run and has no potential security issues a web server based terminal has etc.

This is super-cool. Not sure it's recommendable to use it in place of ssh, but maybe with ssl+http-auth it could be workable? It definitely adds some convenience for when I'm away from one of my boxes and I don't want to deal with putty.

As per all HN comments, one downside is that it kind of messes up with my vim colors, but that may be that my vim colors are messed up to begin with.

If you are concerned about the security and don't want to deal with putty (I can commiserate), there's always the secure shell chrome/chromium extension. If you haven't seen it already you might want to give it a look.

Can you point the advantages of this being "super-cool", i am afraid I'am bit puzzled :s

Well right off the bat: You don't have to install anything. You also don't need to worry about updating a thousand clients if a security problem crops up--you just update the server and you're done.

Also, in terms of "why" there's all sorts of neat things you can do with a web browser that aren't so easy with regular terminals. For example, displaying inline images (if you code it right). Gate One can display images, PDFs, and play back sound files right there in your terminal if you do something as simple as 'cat somefile.png' or 'cat somefile.ogg'.

Source to Gate One (also has some screenshots of the aforementioned features): https://github.com/liftoff/GateOne

The other nice thing is that you can use it through basically any proxy server (provided it doesn't "speed bump" you--breaking WebSocket connections).

For these things (embedding audio etc.) I think iPython is better.

I think I'll stick with the Chrome ssh plugin.

hterm -- the terminal implementation that the Chrome ssh plugin and crosh is based on is pretty hackable, too.

I think I'll just stick with pressing alt-tab to Terminal.app.

Another vote for Chrome Secure Shell. Open source, well made and hterm supports copying to your clipboard when tmux or mosh doesn't eat the sequence. I have limited font choice on the Chromebook so I embed a powerline font in mine. Very cool. Hacking up some insecure DIY server backend is a bit silly when you can have libssh or mosh compiled into nacl.

why would anyone use chrome ssh plugin instead of mate-terminal?

I don't get it.

Too bad AjaxTerm was abandoned: https://github.com/ingydotnet/ajaxterm If it wasn't, it likely would be this today.

You want to know what AjaxTerm would be like today? Look at Gate One: https://github.com/liftoff/GateOne

When I wrote my first web-based terminal (Escape From The Web) it was based on AjaxTerm. It kinda sucked for more than one terminal at a time so I went back to the drawing board and wrote Gate One. It turned out great (if I do say so myself!) and soon it will support running X11 applications as well (see: http://youtu.be/6zJ8TNcWTyo)

The security of this worries me. I would have to understand their code very well before I would be comfortable running a program that gives root access to anyone over a web browser.

> You can set the bind host with butterfly.server.py --host="0.0.0.0" which will allow other users to connect to your terminal. A password will be asked but IT IS NOT SECURE! So it's recommended as of know [sic] to run this only on local network for testing purposes.

The easy solution is to set up an iptables route for disabling all non-loopback connections and traffic for port 57575.

That doesn't help if the vulnerability involves taking over your machine via JS on an untrusted page, causing your own browser to conduct the exploit against your terminal.

I really like the quick history selection feature, and now I want it in iterm2. Browser based terminal isn't something I'd be likely to use, but congrats on writing it.

Locks up the browser if you try to `exit`

docker run -p 0.0.0.0:57575:57575 creack/butterfly

This would be nice to get working in ChromeOS, would it be possible to start this at runtime? Which files should be edited? I've got a dual-boot Chromebook machine so I can mount the ChromeOS partitions with Linux.

To make it start on boot in Ubuntu:

Put this into /etc/init/butterfly.conf: http://pastie.org/8825201

This is really cool! Would be great to get this on places like http://www.runnable.com

Check out http://terminal.com/ You can instantly clone real machines there.

Great job! I've been using tty.js for a while but it is a little unstable and I love Python so this is a perfect fit.

Does anything like the quick history select or the google-instant style auto-complete/suggestion exist for zsh?

https://github.com/zsh-users/zsh-history-substring-search

Beautiful, but if it isn't secure for managing servers and remote machines, what is the point of it?

'sudo pip install', really?

With some installations of python, you have to use sudo with pip in order for it to install anything system wide. (ex: OS X's preinstalled python).

Everyone should absolutely be running from a virtualenv. Never touch the system python.

  brew intall python
  /usr/local/bin/pip install --upgrade setuptools
  /usr/local/bin/pip install --upgrade pip
  /usr/local/bin/pip install --upgrade virtualenv
  /usr/local/bin/virtualenv --python=/usr/local/bin/python py.env

And done.

  . ~/py.env/bin/activate
  pip install butterfly

Are virtualenvs (or Ruby bundles, or anything else equivalent) still relevant when using Docker containers? It seems to me that the proper thing to do, when you're making a container that runs a python app, is to install the app's dependencies to the container's global environment.

I keep all of my systems the same between dev,test,prod so I still deploy into a virtualenv inside of containers. No reason to ever run something as root.

I think homebrew handles this for you, which is great.

Homebrew installs a specific pip, you still need to upgrade if you want to get the latest. Although it should be fairly up to date. Type `brew edit python` to peruse the recipe.

Using virtualenvwrapper is somewhat easier.

    pip install virtualenvwrapper
    source /usr/local/bin/virtualenvwrapper.sh
    mkvirtualenv -p /usr/local/bin/python venv
    pip install butterfly

> Everyone should absolutely be running from a virtualenv. Never touch the system python.

Why exactly? I find it convenient to have some packages installed system wide so that they can be used by quickly loading up a python shell without having to activate a virtualenv first or if they need to be used outside any specific project eg. requests, nose, jedi, pyflakes, sphinx etc.

For most systems, if you have a "system python" you'll want the system package manager to manage that python (and python packages). Because breaking python can mean breaking the package manager.

Personally I enjoy having a few bits installed under ~/opt/py-venv and simply add ~/opt/py-ven/bin to my path. It's usually no need to activate a venv to use it -- just call that venv/bin/{python|pip|hg|ipython|<whatever>}.

In other words, whenever I "pip install something" that something is installed in my "default" virtualenv. And if/when things get out of hand/I need to upgrade to a new python -- I can just recreate the virtualenv and install whatever is needed.

I have a default.env that is activated in my .profile so I can always just do a `pip install <package>` w/o having to touch the system python. The system python is for the system, not me.

But how many people actually need system wide installs on OS X? That's only relevant if more than one uid needs access to the stuff.

(One might argue that in case of one uid per mac, doing a system wide install isn't a problem -- but I'd counter with adding a new user and testing if whatever break-age is introduced with various local package installs is easier/quicker than having to reinstall os x...).

It's a system-wide tool, there's nothing wrong with installing it with sudo pip install if you want it on your PATH.

Yes, there is: system packages should by installed with the system's package manager. Otherwise, you have two systems managing the same set of files, causing tears and suffering.

Packages not installed with the system's package manager should be installed elsewhere, e.g., a local install in a user's home directory, or (in the worst case) /usr/local or /opt.

You're assuming everybody follows the package manager religion. E.g., it would be fine doing this in OS X, and pip install will follow the best UNIXy practice.

pip installs in /usr/local, actually. It's not quite as bad as it looks.

Thanks for the correction.

I wrote about why this was a bad idea at: http://notes.pault.ag/debian-python/

If you want a clear failure mode - if this installs requests globally, think about the chaos if you're on Debian stable, with 0.12.1, before the API break - after a pip install, you may end up with all the software on your system broken.

When this happens, please don't file bugs with Debian. Thanks.

> When this happens, please don't file bugs with Debian. Thanks.

We are all adults here. I believe the implications of using pip instead of apt on Debian are pretty clear for anyone using it. This is not an universal problem though.

No. It's not. If you saw the people filing the bugs, you wouldn't say this.

Unless you intend to (eventually) break your OS, system-wide packages should be installed with system-wide package managers. That is, dpkg/apt, rpm/yum, pacman, emerge or similar.

Failure to comply with this rule bites hard when you install some other package that uses Python and pulls dependency from OS repository that you had already installed from PyPI. That obviously fails due to files being already present (and probably from another egg's version) and you're probably already using this egg somewhere so you probably can't readily replace it. Manual clean-up of such mess isn't pretty nor fun.

So, if you want a non-project-bound package (like ipython), do so with `pip install --user`. Otherwise, virtualenv is the tool.

(Obviously, there are non-trivial exceptional cases where sudo pip is fine. I believe they're quite rare.)

This is insanely cool, for mobile?

I fail to see anything cool here. What's the point of using browser for UI layer if you need a backend app anyway?

Or, if you intend to use that remotely - Atwood's law aside - what's the point of replacing already well-working client apps, usually, with old trusty OpenSSH client under the hood, with some browser-based kludges? (For example, you'll have to reinvent auth.)

The browser is the OS.

Really Awesome! No more switching back and forth

How switching between browser tabs is different from switching between applications?

Reminds me of some ezine from the 90s.

I really love that ASCII butterfly... more console tools should have ASCII art.

Your comments led me to discover Figlet (http://www.figlet.org) and ASCII art generator (http://patorjk.com/software/taag).

Weekend customization times! :-)

Reply on news.ycombinator.com