Currently, cloudshell directly reading files for static files in public and node_modules from project directory for embedding static assets.

I think we should use go:embed to embed static assets directly into the Go binary. This feature of go will make the distribution of the binary easier, since we dont need to access the static files from the project directory, the downside is the binary will be bigger since it will have node_modules in it, but I think it's worth because we dont need to clone the whole project to use cloudshell, just the released binary is enough.

Thank you

Hi zephinzer,

two harmless typos in pkg/xtermjs/handler_websocket.go:

• line 101: webscoket -> websocket
• line 177: uunknown -> unknown

Gerhard

Hi zephinzer,

Cool project!
I face a race condition, have a suggestion to fix this.
Program now and then panics with "panic: sync: negative Waitgroup Counter". This is because there is only once waiter.Add(1) being called, but there are more than one waiter.Done() calls in different goroutines.

In all cases so far, the pingpong gorountine finishes (logs) first, in line 124 is the 1st waiter.Done() being called.
Then line 149 also wants to decrement the counter:

WARN[15:07:08]handler_websocket.go xtermjs.GetHandler.func1.4 failed to read from tty: read /dev/ptmx: input/output error connection_uuid="75bd5ed0-1550-11ec-b29c-005056000bac"↲
WARN[15:07:08]handler_websocket.go xtermjs.GetHandler.func1.4 failed to send termination message from tty to xterm.js: use of closed network connection connection_uuid="75bd5ed0-1550-11ec-b29c-005056000bac"
panic: sync: negative WaitGroup counter

To fix it, I am using 3 channels (abortChan{1,2,3}), a channel for each of the 3 goroutines. Goroutines are the sender, and close (or could send an describing string) and return when they face a "serious" error, rather than decrement a WaitGroup.

The handler is the receiver, blocks using select for one of the goroutines to close (or to send a short message).
There is another channel: stopChan, handler is the sender. Handler closes stopChan when select got a "signal" on one of the abortChans. The (remaining) goroutines do a non-blocking select on this stopChan. And return when they detect the close of stopChan.

The pingpong goroutine always returns this way. The other goroutines in most cases not, as they usually block in connection.ReadMessage or tty.Read. Their shutdown (including close of their abortChan) will be handled by the deferred func.

If you are interested I prepare a pull request.

Gerhard

Great project, like it is in go, so easy portable...

But I find there is a issue , there is no TERM environment set.

 40f72c8c915f:/$ echo $TERM
dumb

So some application will fail, need to set TERM manual.
export TERM=xterm-256color

But this should be done when opening the shell, from the go binairy.

something like this? cmd.Env = append(os.Environ(), "TERM=xterm-256color")

Just tried out your repo on ubuntu.

This is what i get after runing make init