Pigshell – Unix the Web
pigshell.com
pigshell.com
- Please use a desktop browser (Chrome preferred). While mobile browsers kinda-sorta work if you're just clicking through the examples, keyboard input doesn't work on mobiles (yet).
- Pigshell has few users (in fact, using the plural is a slight marketing exaggeration) so please bear with me for any teething issues, broken links, inadequate documentation...
- One of the practical use cases is copying files across Google accounts, and backing it up to your desktop. (Details here: http://pigshell.com/v/0.6.2/doc/gdrive.html) The nice thing about a unix approach is that the exact same cp command can be used to copy GDrive to Dropbox, or any other supported filesystem.
- Some more D3 visualization examples here, using Mike Bostock's gist viewer: http://bl.ocks.org/ganeshv (Do use the "Open in a new window" links, like this one: http://bl.ocks.org/ganeshv/raw/46cc526d41d16995ccdc/).
I played with the same idea a few years ago, but never went that far :)
edit: found mimeMap.js and saw tsv was an option. That didn't work either.
See https://developers.google.com/drive/web/manage-downloads for a list of export format possibilities. For spreadsheets, the only options are xlsx, odt and pdf.
Here's a proof: http://www.cellmaster.com.au/example.html
pig> echo "Testing status update" >> /facebook/me/posts
echo "Testing status update" > /facebook/me/posts/
I tried it and it WorksForMe (TM)That said, two caveats:
- The FB filesystem hasn't been worked on in 1+ year.
- AFAIK v2 of the graph API will become mandatory sometime next year and does not allow apps to get lists of friends. Friend list returns only friends who also use the same app... which is pretty disappointing.
echo "foo" > /facebook/me/posts
would imply overwriting the posts directory, which is not allowed (either on pigshell or on unix)OTOH, asking the user to do a
echo foo >/facebook/me/posts/post-11oct2014
sets up the expectation that the post will be named that way, when it will most likely be a long numeric id. Thus, the trailing slash. Not perfect, but the best compromise I could think of. echo "Testing status update" >> /facebook/me/posts
I think appending content to a file path (with or without the trailing slash) is clearer than the analogy of a truncating write to a directory path (where the trailing slash is required).The current model seems similar to the REST interpretation of CRUD, where > equates to 'create' and >> to 'update', and creating a resource is done at the collection URL. Nothing wrong with this, but it seems slightly unintuitive to me.
My suggested mapping would be:
>/facebook/me/posts - Unsupported (or delete all posts, and make a new one)
>>/facebook/me/posts - Add a new facebook post
>/facebook/me/posts/long_numeric_id - Update post (truncate)
>>/facebook/me/posts/long_numeric_id - Update post (append)
In this case, both > and >> are context dependent, but more flexible. Would this strategy mesh well with the rest of the implementation?Also, nice work! The project reminds me of Plan 9's /net.
cd http://dilbert.com/strips/comic/1995-06-24/
ls
cat 21021.strip.zoom.gif
Never really liked the colorization of Dilbert. It was so much nicer as a line drawing. Best we can do is remove the colors. cat 21021.strip.zoom.gif | to canvas | pixastic -d
And to save your result, cat 21021.strip.zoom.gif | to canvas | pixastic -d >/home/dilbert-unix.png
Or to GDrive or Dropbox or even the local RamFS by changing the target directory.(Scott Adams is fine with personal usage. I checked. And you need psty because it proxies HTTP requests for sites which don't have CORS enabled)
I find PigShell interesting from a historic point of view but think it also points to a flaw in how the web currently works, with far too much glue and eye candy, which is a direct result of the ad business model.
At the risk of sounding like one of the semantic-web xml-standards people, it really does make me wonder if all this horrible, incompatible, site-specific frontend crap is just a fad that will give way to tools (like psty) that ignore all that and just deal with the raw semantic content (and HTTP verbs) at a higher level of abstraction.
Woah, man. We're like...surfing the Matrix, man.
You could search websites, send emails, look at maps and much more (you could build your own commands) without ever actually opening a webpage. It had 200.000 users when they shut it down.
What about saving the state of things. I want, for example, to `mount` my local directory with psty everytime I open pigshell, and I wanna have my PATH set automatically. Will a `/local/.config/.pigrc` do this? (This raises another question: file editing. Where is the file editing tool? Maybe a web-based editor somewhere). Well, maybe a gist will do it.
Currently, Javascript commands have to be built-in at "compilation" time. (I need to add a load command which will evaluate a new JS command inside the pigshell closure)
Scripts can be anywhere in PATH.
There is an rc mechanism for doing exactly what you want. At boot time, we run /etc/profile, followed by /local/rc.sh - this is a file saved in the browser's localStorage. Mine is very simple:
HOME=/home
mount http://localhost:50937/ $HOME
You can create it simply by echo "HOME=/home\nmount http://localhost:50937/ $HOME" >/local/rc.sh
or running "edit /local/rc.sh". Edit provides a simple inline CodeMirror-based editor (actually even the CLI is a CodeMirror editor instance). I use vim on the desktop to do any serious editing. If you run psty, /home is a desktop directory visible inside pigshell, so edit on desktop/run in shell is a low-friction process.If you manage to mess up /local/rc.sh to the point where pigshell is not "booting", then you can boot it in "safe mode" by appending #norc to the URL, i.e. http://pigshell.com/#norc
Unfortunately only "ls /dir/file" works but neither "cat /dir/file" nor "cp /dir/file ." although "file" was marked with "chmod a+r". I get the message "Cross-origin request denied (check if psty is running)". What do I wrong?
As a workaround in 0.6.2, please use a trailing slash in the name of the mount point. ( /dir/ rather than /dir)
Alternately, use http://pigshell.com/v/0.6.3-pre4/ which would have the fix.
EXCEPT timestamp out of range for platform time_t Traceback (most recent call last): File "psty.py", line 404, in send_head self.send_header("Last-Modified", self.date_time_string(entry["mtime"])) File "/usr/lib/python2.7/BaseHTTPServer.py", line 468, in date_time_string year, month, day, hh, mm, ss, wd, y, z = time.gmtime(timestamp) ValueError: timestamp out of range for platform time_t
- self.send_header("Last-Modified", self.date_time_string(entry["mtime"]))
+ self.send_header("Last-Modified", self.date_time_string(entry["mtime"] / 1000))
If it still doesn't work, maybe we can continue the conversation on the google groups forum?Thanks for this, and thanks for sharing your amazing pigshell!
I'm thinking that such an approach can give the user their own way to explore/modify the data ,especially if you combine this with some kind of pipe lines that let you analyze/mutate/visualize the data without having to write some Python code to access the API (even though with a REST API plus e.g. requests it's simple).
I like the psty idea to integrate with the local system. Sounds like it could also be used to start e.g. emacs on a remote page. Say you have a site with an API that lets you read/write files, you mount it and then can fire up emacs on it via pigshell.
As mentioned in the README, you need to run psty server locally and establish websocket connection (mount in pigshell). This will enable you to harness local filesystem from pigshell.
The scope of this project is definitely what makes it nifty.
I made a directory at /mnt/mccomsoft then ran Firefox and didn't see it which is good. :) Then I tried mounting that using your HttpFS with:
mount http://www.mccomsoft.com/index.html /mnt/mccomsoft
It gave me: Cross-origin request denied (check if psty is running)
Which is also good. :) If I load Pigshell from my domain though then it should mount fine.One user commented below it's like the Internet was a shell and you've cracked it open. I agree.
The way how you implemented "man" ("man ls" for instance) shows how a convenient shell can look like. Pigshell could be a foundation for a completely new kind of toolchain for web development. I am thinking of seemless integration of JS editors, D3 graphics for pipe output, etc. ... Wait - it's already working :-)
http://bl.ocks.org/ganeshv/raw/b971989c337e958c0531/
If it just were possible to access the bare bone hardware so that we wouldn't be restricted to the JS world (in a closed environment, of course).
By the way, from http://pigshell.com/v/0.6.2/doc/psty.html "Websocket server: Every unix app on the desktop which uses stdin/stdout can participate in a pigshell pipeline" so maybe your request has already been implemented.
Thanks, meanwhile I have realized that also :-)
I guess it would be possible to adapt the filesystem code to fuse4js. It won't be a drop-in; unix FS ops differ from pigshell's, but it shouldn't be too hard. Personally, I find psty (http://pigshell.com/v/0.6.2/doc/psty.html) a better way to incorporate (a part of) the unix filesystem into the web rather than fuse - which is the other way round.
At any rate, awesome work. I've been thinking for a while, offhandedly, about the idea of piping web URLs around. But I don't know how in fact it would work under the hood. I write a lot of API interfaces in my work, and it's all in the details -- every API is different in small but important ways.
We have been developing pigshell off and on since ~2012, and I was unaware of IPython notebooks until ~6 months ago. When I'd last used IPython, it didn't have any of the notebook stuff. So it was a bit of a jar to see that they had been there, done that, got the T-shirt, published the book, etc. etc. :)
Pigshell can run in the browser with zero installation, and has a low barrier for casual usage. "Notebooks" aka gists can be shared without requiring a backend. The focus of pigshell is more around providing file adapters for web/cloud data stores.
That said - more power to IPython! I love the conversational, exploratory, CLI style of interacting with a computing environment. The more ecosystems of this sort, the better.
- Pigshell is a 100% client-side Javascript app. There is no server side. pigshell.com is a dumb static html/js/css server.
- All data (username/password as well as user data like photos and files) travels directly between the user's browser and the provider (e.g. google.com, facebook.com). pigshell.com is not involved at all.
- Pigshell is free software - you are free to download the source code, examine, modify and run it locally yourself. (https://github.com/pigshell/pigshell)
- Our privacy policy is minimal because we know NOTHING about you - not your name, email address, facebook id, nothing. Only your IP address is recorded in apache logs, which is the case with every website you visit.
What is more, we don't want to know. Pigshell has been deliberately designed so as to afford maximum privacy and freedom to the end user.
When I try to sign in with Google Drive, it tells me that PigShell (developer email: xxxx@gmail.com) would like access to my Google Drive, as well as my photos and videos. Does that give your API key access to my account, or does only code that I run that's hosted on pigshell.com have access? What do the permissions get tied to? And how would it work if I were to host it locally?
Only the code you run that's hosted on pigshell.com has access. The permissions are tied to the app-id which is embedded in the code. The access token is persisted in your browser either as a cookie or explicitly in localStorage.
We don't and won't support OAuth 1 (Twitter, Flickr etc), which lacks a pure client-side flow, just to avoid the issue of users having to trust the pigshell.com server to generate (and not leak or misuse) the access tokens.
Here is a rough guide to local setup:
- Check out the git sources, run "make" (some more details here, but reading the Makefile should help)
- set up apache to serve the virtual host pigshell.com (if you want to use Dropbox, you need to create a self-signed SSL certificate and set up https as well)
- modify /etc/hosts and set 127.0.0.1 to point to pigshell.com
This way, static assets as well as redirect URLs from the OAuth2 server will hit your local server rather than pigshell.com
the "application" Pigshell (a copy of the javascript downloaded from the "site" pigshell.com and running in your browser is an instance of the "application") requests and say is granted access to your GDrive.
so all permissions/rights are associated with the running instance of the "application" pigshell in your browser - cookies apart, end of story.
other than having served the javascript, the "site" pigshell.com has no further role to play here. so you could just as well have sourced/hosted these javascripts locally.
:(
The availability of a file abstraction covering many popular cloud services, web resources etc. enables casual, low cost experimentation across these domains, without having to read up each one of the APIs. If something clicks, then it may make sense to write a better "native" implementation.
This is super cool, though. There's an undocumented template engine built in it seems? (see /bin/mostliked) which is neat.
The domain tree goes from top to bottom this way <---
The resource tree goes from top to bottom this way --->
So, using numbering for order, you could look at a URI like:
0002.0001.0000/0003/0004/0005
Meanwhile, in an alternate reality...
$ ls /net | shuf -n 16
coffee
net
рф
한국
org
dating
pw
中國
institute
இலங்கை
ninja
com
みんな
su
政务Mostly I have fun with it, e.g. trying out visualizations of interesting data (e.g. http://bl.ocks.org/ganeshv/raw/fada13e56d2c5b7b1a78/)
My Serious Use Case is full and incremental backups of the contents of my Google Drive, both personal and company, to my desktop. Running the Drive desktop app does not backup Google Docs, and you can only sign in as a single user at a time.
with deferred pipes, split and joins (that pigshell already provides/supports) it should be possible to implement arbitrary work/data flow definitions one desires.
coupled with psty, one could build/harness special purpose "transformers" on the web
pushing it further, one could conceive of setting up pipes between transformers on the web.
of course getting there will require significant work on a security model as well.
[and then someone will figure out a way to interject ads]
It could probably be easier than you imagine. The security model could be implemented in psty completely by granting/denying requested resources whose permissions are stored in a database on the psty server, and managed by using long security IDs in the URLs. This way the security model could even be fine-grained. In other words, pigshell itself could be embedded into a secure environment, covered by the permissions of psty.
- Web development toolchain.
- (Multiple) Server administration.
- Control embedded systems. No need for special GUIs there. For instance, simply psty on a Raspberry Pi would be sufficient to present collected data in a nice web graphics on your PC. However for embedded systems I would recommend a reimplementation of psty in a compiled language like C or Nimrod.
Very cool.
ls -d /path/to/file_or_dir | printf
This command prints the stack of file objects. The last one printed is at the "top" of the stack and tells you the fields available. You can then print a field ls -d /gdrive/user@gmail.com/somedoc | printf "%(raw.ownerNames)s"
Sorry, a lot more documentation is needed. Working on it. rm -r facebook
ah, that feels good.