Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Object-oriented shell #1

Open
KOLANICH opened this issue Jun 29, 2016 · 4 comments
Open

Object-oriented shell #1

KOLANICH opened this issue Jun 29, 2016 · 4 comments

Comments

@KOLANICH
Copy link

Hello. Your CloudABI need to be complemented by something. We lack object-oriented shell for it.
What I mean under object-oriented shell? Now the shells work with 3 binary streams and allow only their redirection. It is not fine: what if I need to pass a resource from one process to another? What if I need to pass multiple resources, for example multiple streams? In the case of multiple streams fifo can help, but in case of resources of other types it won't.

The proposial is to use programms as functions with variable number of arguments.
1 Each programm binary has a metadata block in it describing its command line format.
2 The shell reads that metadata block and validates vommand line before executing
3 when executing the shell passes arguments to a programm
4 The arguments are not text strings, they are objects of standardized types. For first time I propose to have the following types : string, number, input stream, output stream, input-output stream, network, error and void.
5 A programm has one return type, it can return either its return type or error.
6 A programm can either return its type and stop or return its type and daemonize itself. In the case it daemonizes itself it can be used by another program through the returned object.
7 Arguments types can be implicitly converted, for example strings can be converted into file descriptors which are iostreams.

@EdSchouten
Copy link
Member

EdSchouten commented Jul 2, 2016

I think trying to stomp CloudABI into the UNIX command line paradigm (read: having a list of string command line arguments referring both to switches, paths, network addresses, etc) is not what we should be striving for.

That said, @moreati is currently working on porting Python over to CloudABI. What if that version of Python had a decent 'CloudABI binding' that allowed you to easily start programs? As in, that you could just say:

my_server_executable_fd.run({'bind': my_socket_fd, 'datadir': my_dir})

That would be quite nifty, as you use Python on its own as a CloudABI shell. Thoughts?

On that note, there is also this capability-based scripting language called Shill. Maybe there's some overlap with this as well? http://shill.seas.harvard.edu/

@moreati
Copy link

moreati commented Jul 4, 2016

My immediate thought for the intersection of shell/types/python is xonsh, in part because I just recently learned of it. Adding syntax/functions for file descriptor & socket is probably doable. Then it would need to be cloudabi-ified. I have no plans to work on such a thing though.

@saper
Copy link

saper commented Jul 20, 2016

@KOLANICH Do you mean something like PowerShell?

@KOLANICH
Copy link
Author

@KOLANICH Do you mean something like PowerShell?

Yes, but not quite. Its commandlets are still limited: they use strings where objects should be used.

That would be quite nifty, as you use Python on its own as a CloudABI shell. Thoughts?

This can be fine but I don't think that it can become a widespread replacement for sh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants