Their github may be more informative.
https://github.com/plasma-umass/browsix
Seems they are using web workers to implement a POSIX environment.
And their shell demo do not even support cd(!).
https://github.com/plasma-umass/browsix
Seems they are using web workers to implement a POSIX environment.
And their shell demo do not even support cd(!).
``` $ ls /usr/bin cat cp curl echo exec grep head ld ls mkdir nice node rm rmdir sh sha1sum sort stat tail tee touch wc xargs ```
$ TEST=1
$ echo $TEST
$TEST
$ cat README | while read L; do echo "README: $L"; done
$ read L
/usr/bin/read: command not found
$ while true; do break; done
/usr/bin/while: command not found
$ echo "quotes"
"quotes"
https://github.com/plasma-umass/browsix/blob/master/src/bin/...
It doesn't do much, and certainly does not qualify as being unmodified existing code (which is what this whole system is supposed to be able to run as one of its benefits.)
The shell currently used in the demo is dash, compiled with emscripten: https://github.com/plasma-umass/browsix/blob/master/src/dash...
Which ends up in the build through our gulpfile: https://github.com/plasma-umass/browsix/blob/master/gulpfile...
The weirdness (and reason that cd + setting variables doesn't work) is because whenever you type a command in, it executes:
$ dash -c '$COMMAND'
Rather than having a long-running shell process listing to standard in. We plan to fix this and implement a full TTY subsystem in the next month or so.
That means their claim that "Unmodified C, C++, Go, and Node.js programs run as processes on Web Workers"
...is not true, as otherwise they could've just "compiled" e.g. bash or some other shell to run on their system, along with GNU coreutils or similar.
dash -c "$COMMAND"
Processes can change their current directory (We support the chdir(2) system call), but the way the shell demo is currently implemented no state is retained between command invocations. We plan to address this shortcoming soon as part of a bigger TTY refactoring.