eaburns / watch Goto Github PK

The exit status and end time often get interleaved with the writing of stdout/stderr.
Instead, we should write stdout and stderr in our own go routine, wait for it to finish, and only then write these trailing messages.

eg. with no exclusions, Watch -v -t echo build

touch .git/newfile => causes build
touch .gitignore => causes build

Now try Watch -v -t -x '.git.*' echo build
Debug output says:

2015/08/27 14:15:36 DEBUG: excluding .git
2015/08/27 14:15:36 DEBUG: excluding .gitignore

but then:

touch .gitignore => causes build

touch .git/newfile is however correctly ignored.

Otherwise you cannot easily run a command from one directory while watching another.

This should be more effective and possibly simpler logic than rebuildDelay.

SIGKILL is to extreme. It can't be caught so the killed process doesn't have a chance to perform proper shutdown.

Otherwise 2-clicking on the an error location brings you to the wrong file (likely a non-existent file).

Hi

When running inside a Git repo it attempts to watch all the files the .git directory, this results in too many open file errors.

Solution would be to allow the user to create a .watch file in which you can write exclude or include regex rules.

Here is my debug outout from OSX.

↳ Watch -t -d go test
2014/01/21 09:30:34 DEBUG: Watching .git/hooks
2014/01/21 09:30:34 DEBUG: Watching .git/info
2014/01/21 09:30:34 DEBUG: Watching .git/logs/refs/heads
2014/01/21 09:30:34 DEBUG: Watching .git/logs/refs/remotes/origin
2014/01/21 09:30:34 DEBUG: Watching .git/logs/refs/remotes
2014/01/21 09:30:34 DEBUG: Watching .git/logs/refs
2014/01/21 09:30:34 DEBUG: Watching .git/logs
2014/01/21 09:30:34 DEBUG: Watching .git/objects/02
2014/01/21 09:30:34 DEBUG: Watching .git/objects/03
...
lots of git files
...
2014/01/21 09:30:34 DEBUG: Watching .git
2014/01/21 09:30:34 DEBUG: Watching .
go test
fork/exec /usr/local/go/bin/go: too many open files
2014-01-21 09:30:34.391614237 +0000 GMT

Chris

Something like -w to invoke the command with what has changed. E.g. (details omitted):

% Watch -t -w echo &
% touch hi
hi
% touch hi blop
hi blop
%

In retrospect, this is obviously fixed by using a channel:
Run selects between the kill channel and a default case with a non-blocking wait. If it gets kill once, SIGTERM; twice, SIGKILL (there you go, Steve) and nil the kill channel to stop this case. When killed, Wait will fire. No more race. No need for global pid, no "lock vomit." But we will need the shared channel.

d:\>go get github.com/eaburns/Watch \# github.com/eaburns/Watch d:\src\github.com\eaburns\Watch\main.go:158: undefined: syscall.Kill d:\src\github.com\eaburns\Watch\main.go:161: undefined: syscall.Kill d:\src\github.com\eaburns\Watch\main.go:168: undefined: syscall.Wait4 d:\src\github.com\eaburns\Watch\main.go:168: undefined: syscall.WNOHANG

Only Create, Write, Remove, Rename, Chmod, etc...

These aren't covered by the Go compatibility promise and are questionably portable. I at least want to get rid of the Wait4 polling, because it's orthogonal to the race described in #14 (which was due to global PID flim-flammery).

The acme win should have a Cancel that would cancel the current execution, for when you spot a bug but are already running an eggrigerously long build.

In run, don't continue if cmd.Start errors. Otherwise we panic in wait.

Hiya, a few days ago I finally got around to checking out Watch and its a fantastic addition to the workflow, so thanks!

Today I noticed my laptop was getting hot though, and sure enough top revealed my four Watch instances consuming 70-80% cpu between them, despite no action on the filesystem.

These instances had been open for several days through several sleep/resume cycles which may or may not be related. A newly spawned Watch instance does not use excessive CPU.

Not sure if this will actually turn out to be a bug in Watch, as kill -ABRT on one of the instances showed only these two goroutines active:

goroutine 0 [idle]:
runtime.futex(0x6d2e38, 0x0, 0x0, 0x0, 0x0, 0x6d27c0, 0x1, 0x41198f, 0x411bae, 0x6d2e38, ...)
    /usr/lib/go/src/runtime/sys_linux_amd64.s:277 +0x21
runtime.futexsleep(0x6d2e38, 0x0, 0xffffffffffffffff)
    /usr/lib/go/src/runtime/os_linux.c:49 +0x47
runtime.notesleep(0x6d2e38)
    /usr/lib/go/src/runtime/lock_futex.go:145 +0xae
stopm()
    /usr/lib/go/src/runtime/proc.c:1178 +0x119
findrunnable(0xc208012000)
    /usr/lib/go/src/runtime/proc.c:1487 +0x562
schedule()
    /usr/lib/go/src/runtime/proc.c:1575 +0x151
exitsyscall0(0xc208000a20)
    /usr/lib/go/src/runtime/proc.c:2021 +0xdd
runtime.mcall(0x435cc4)
    /usr/lib/go/src/runtime/asm_amd64.s:186 +0x5a

goroutine 7 [syscall]:
syscall.Syscall6(0xe8, 0x6, 0xc2080a9cb4, 0x7, 0xffffffffffffffff, 0x0, 0x0, 0x8, 0xc20802a2e8, 0x7f84169fc8f0)
    /usr/lib/go/src/syscall/asm_linux_amd64.s:46 +0x5
syscall.EpollWait(0x6, 0xc2080a9cb4, 0x7, 0x7, 0xffffffffffffffff, 0xc20802a2e8, 0x0, 0x0)
    /usr/lib/go/src/syscall/zsyscall_linux_amd64.go:376 +0x93
github.com/go-fsnotify/fsnotify.(*fdPoller).wait(0xc20801e2c0, 0xc208052700, 0x0, 0x0)
    /d/go/src/github.com/go-fsnotify/fsnotify/inotify_poller.go:85 +0xc7
github.com/go-fsnotify/fsnotify.(*Watcher).readEvents(0xc20800a370)
    /d/go/src/github.com/go-fsnotify/fsnotify/inotify.go:179 +0x16f
created by github.com/go-fsnotify/fsnotify.NewWatcher
    /d/go/src/github.com/go-fsnotify/fsnotify/inotify.go:58 +0x32b

(the other four goroutines had been blocked for 28 minutes)

I realise this report is probably not sufficient to solve/understand the issue. At some point I'll dig into the Watch/fsnotify code to try and gather more information, but if someone beats me to it I'm not going to complain ;)

go version go1.4.2 linux/amd64

Right now the error is simply lost and nothing is watched.

Are you all aware that as long @eaburns has not added a Lizense file with dedicated different content .. that the reuse of this code is prohibited ?

Like the existing forks of https://github.com/weaveworks/Watch for example.
And i think they use it in their software including redistribution (They offer also dockerimage with it contained)

Look here what it means if author has not created a opensource license.
https://opensource.stackexchange.com/questions/1720/what-can-i-assume-if-a-publicly-published-project-has-no-license

Do i understand this correctly ... or is there same part which i misunderstood ?

Any thoughts on a mode where Watch restarts the command whenever a change is detected? This goes deep into the process management hell, so I understand if you'd rather punt this to some other utility.