I'd suggest making an array of browsers that could be checked OR adding a new parameter for "browser executable". For example, on debian distributions I have a "chromium", not a "google-chrome"

Thanks for this great package, just one comment which is not urgent. When you use the gopdf package wago comes up wuith a << ✏ Matched event: "/home/userpt18z97/proj40dev/hello.pdf": MODIFY
✏ Sending signal SIGTERM to command: go run src/main/main.go >> when writing the pdf to disc. If you just start the go program conventionally with "go run src/main/main.go" it does not happen.

KLR$ cat /usr/bin/g4
cd $HOME/proj40dev/;./wago -cmd='go run src/main/main.go' -daemon='main.go' -timer=35

[edit]
added ./pdf path for pdf files; with << ./wago -q -ignore='(/.pdf)' -cmd='go run src/main/main.g o' -daemon='main.go' -timer=35 >> the hello.pdf file now is ignored in the ./pdf path but wago continues to restart the program

Summary

A known, harmless, race condition exists between these two functions:

  os/exec.(*Cmd).Wait()
  github.com/JonahBraun/wago.(*Cmd).Kill()

Details

We use os/exec.Cmd.Wait to wait for a process to exit and report on that. Before attempting a kill (in response to a FS event), in order to prevent unnecessary log errors, Wago's Cmd.Kill() checks exec.Cmd fields to see if the process is alive. Because Wait() and Kill() must occur in concurrent goroutines, a number of inherent race conditions exist.

These race conditions are harmless. The objective is to ensure a command is killed as quickly as possible in response to an event with the least number of extraneous warnings — and this works most of the time. In the rare worst case scenario, a process exits after the kill conditional

  if cmd == nil || cmd.Process == nil || cmd.ProcessState != nil {

but before the kill itself

  if err := cmd.Process.Kill(); err != nil {

In this case, an extraneous error is printed.

This could probably be resolved by rewriting os/exec to use channels instead fields for conveying process information. However, it should be noted that a race condition will always exist at the OS level. A process could exit in the middle of the Wago code to kill that command.

Please do test Wago with -race, just be aware of this known race condition.

It seems Windows is not currently supported

This results from a rare race condition between OS process management and Wago. It is impossible to avoid.

Wago has not yet been notified of the process exit and proceeds to kill. During this time the command exits by itself. When Wago requests a kill, the OS responds with this error.

We should probably detect and not report this particular type of fail to kill.

Elixir's iex does, but pry does not. Investigation needed…

It would be nice if you could really default to current directory, I am not able to open any file unless I put webbase explicitly, as it's the only thing looked at in the startWebServer method https://github.com/JonahBraun/wago/blob/master/main.go#L246

wago -web=':9933' -webbase=.