I'm trying to use modd with curl's "read a file" option. curl will read a file from disk when its argument starts with @. This conflicts with modd's conf, though, which thinks @ is for its own configuration. I wasn't able to find an escape option to prevent modd from interpreting the @. Is there a way to do this?

Hi. It doesn't look like we can use @variables in file watch patterns.

I have this make recipe that I would like to convert into a modd block:

$(build_js): $(wildcard $(source)/$(js)/*.js) $(wildcard $(source)/$(js)/**/*.js)
    browserify -t debowerify -t hintify $(source_js) -o $(build_js)

where $(build_js) is a variable made up of several other variables earlier in my Makefile. This is useful because I can have a generic Makefile that is easy to configure on a per-project basis. If I must change a directory/file name, I only have to change it once.

In modd.conf, the recipe above looks like:

source/js/**/*.js {
    browserify -t debowerify -t hintify @source_js -o @build_js
}

which works perfectly well but is not as "smart" as the make recipe because I (or a coworker/contractant) would need to search/replace source/js instead of changing it one place.

Granted, that's not really a showstopper but still.

Thanks for devd and modd.

Hello,

I have a working setup on Docker for Mac + Modd in a docker-compose file to restart 2 services: api and ssr. modd is working fine.

Now, I am testing the same code inside a VirtualBox VM with docker, modd only "see" changes for one service (randomly, or there is a race condition somewhere) so it is either api or ssr which get the notification.

To make it works, I switch to inotifywait, and both containers "see" the notification. So, there is a bug with modd (I have tested version 0.5 and 0.7 of modd) but I cannot understand why.

Subject: [PATCH] feat(dx): experiment vagrant box

---
 Makefile                       |  4 +-
 infra/docker-compose.local.yml | 73 +++++++---------------------------
 infra/local/node/Dockerfile    |  5 +++
 infra/local/node/watch.sh      | 22 ++++++++++
 modd_api.conf                  |  4 --
 modd_ssr.conf                  |  4 --
 6 files changed, 43 insertions(+), 69 deletions(-)
 create mode 100644 infra/local/node/Dockerfile
 create mode 100755 infra/local/node/watch.sh
 delete mode 100644 modd_api.conf
 delete mode 100644 modd_ssr.conf

diff --git a/Makefile b/Makefile
index d2c40a6..3ef509b 100644
diff --git a/infra/docker-compose.local.yml b/infra/docker-compose.local.yml
index 98ffef5..8ecf650 100644
--- a/infra/docker-compose.local.yml
+++ b/infra/docker-compose.local.yml
@@ -19,86 +19,41 @@ services:
             - watch
 
     api:
-        image: ekino/docker-buildbox:node10.4-2018.06.14
+        build: local/node
         ports:
             - "0.0.0.0:8181:8181"
         volumes:
-            - ../:/code:cached
+            - ../:/code
         working_dir: /code
-        command: modd -f modd_api.conf
+        command: watch.sh /code/src/api "node src/api/server.js"
 
     ssr:
-        image: ekino/docker-buildbox:node10.4-2018.06.14
+        build: local/node
         ports:
             - "0.0.0.0:8080:8080"
+        volumes:
+            - ../:/code
+        working_dir: /code
+        command: watch.sh /code/src/ssr "node src/ssr/server.js"
         environment:
             - API_URL=http://api:8181
             - NODE_ENV=development
-        volumes:
-            - ../:/code:cached
-        working_dir: /code
-        command: modd -f modd_ssr.conf
+
         links:
             - api
 
diff --git a/infra/local/node/Dockerfile b/infra/local/node/Dockerfile
new file mode 100644
index 0000000..0a9e803
--- /dev/null
+++ b/infra/local/node/Dockerfile
@@ -0,0 +1,5 @@
+FROM ekino/docker-buildbox:node10.4-2018.06.14
+
+RUN apt-get update && apt-get install -yy inotify-tools
+
+ADD watch.sh /usr/bin/watch.sh
\ No newline at end of file
diff --git a/infra/local/node/watch.sh b/infra/local/node/watch.sh
new file mode 100755
index 0000000..5446232
--- /dev/null
+++ b/infra/local/node/watch.sh
@@ -0,0 +1,22 @@
+#!/bin/sh 
+
+sigint_handler()
+{
+  kill $PID
+  exit
+}
+
+WATCH_PATH=$1
+START_PROCESS=$2
+
+echo "Watch path: ${WATCH_PATH}"
+echo "Start process: ${START_PROCESS}"
+
+trap sigint_handler SIGINT
+
+while true; do
+  $START_PROCESS &
+  PID=$!
+  inotifywait -e modify -e move -e create -e delete -e attrib -r $WATCH_PATH
+  kill $PID
+done
\ No newline at end of file
diff --git a/modd_api.conf b/modd_api.conf
deleted file mode 100644
index caa0a5e..0000000
--- a/modd_api.conf
+++ /dev/null
@@ -1,4 +0,0 @@
-src/api/**/*.js {
-    # Server runs on port localhost:8080
-    daemon: node ./src/api/server.js
-}
\ No newline at end of file
diff --git a/modd_ssr.conf b/modd_ssr.conf
deleted file mode 100644
index 55470e4..0000000
--- a/modd_ssr.conf
+++ /dev/null
@@ -1,4 +0,0 @@
-src/ssr/* {
-    # Server runs on port localhost:8080
-    daemon: node ./src/ssr/server.js
-}
\ No newline at end of file
-- 
2.18.1

panic: runtime error: cgo argument has Go pointer to Go pointer

goroutine 1 [running]:
github.com/rjeczalik/notify.(_stream).Start(0xc82008a5c0, 0x0, 0x0)
/Users/sheki/go/src/github.com/rjeczalik/notify/watcher_fsevents_cgo.go:131 +0x270
github.com/rjeczalik/notify.(_fsevents).watch(0xc82000a3f0, 0xc820088d50, 0x23, 0x100001b00, 0x0, 0x0)
/Users/sheki/go/src/github.com/rjeczalik/notify/watcher_fsevents.go:206 +0x313
github.com/rjeczalik/notify.(_fsevents).RecursiveWatch(0xc82000a3f0, 0xc820088d50, 0x23, 0x1b0000001b00, 0x0, 0x0)
/Users/sheki/go/src/github.com/rjeczalik/notify/watcher_fsevents.go:258 +0x51
go.(_struct { github.com/rjeczalik/notify.watcher; github.com/rjeczalik/notify.recursiveWatcher }).RecursiveWatch(0xc82000e280, 0xc820088d50, 0x23, 0xc800001b00, 0x0, 0x0)
:50 +0x7c
github.com/rjeczalik/notify.(*recursiveTree).Watch(0xc820012140, 0xc820088d50, 0x23, 0xc82008e660, 0xc820082a78, 0x1, 0x1, 0x0, 0x0)
/Users/sheki/go/src/github.com/rjeczalik/notify/tree_recursive.go:286 +0xad6
github.com/rjeczalik/notify.Watch(0xc820082a70, 0x5, 0xc82008e660, 0xc820082a78, 0x1, 0x1, 0x0, 0x0)
/Users/sheki/go/src/github.com/rjeczalik/notify/notify.go:64 +0x7d
github.com/cortesi/modd/watch.Watch(0xc8200846c0, 0x2, 0x2, 0x5f5e100, 0xc82008e420, 0xc8200846c0, 0x0, 0x0)
/Users/sheki/go/src/github.com/cortesi/modd/watch/watch.go:301 +0x145
github.com/cortesi/modd.runOnChan(0xc82008e420, 0x4379e90, 0x4b40258, 0xc82008a4c0, 0xc8200844a0, 0x42ffaa0, 0xb, 0xc820053db8, 0x0, 0x0, ...)
/Users/sheki/go/src/github.com/cortesi/modd/modd.go:89 +0x4d6
github.com/cortesi/modd.Run(0x4b40258, 0xc82008a4c0, 0xc8200844a0, 0x42ffaa0, 0xb, 0xc820053db8, 0x0, 0x0, 0x40, 0x0, ...)
/Users/sheki/go/src/github.com/cortesi/modd/modd.go:141 +0xbe
main.main()
/Users/sheki/go/src/github.com/cortesi/modd/cmd/modd/main.go:102 +0x9a2
☁ api [master] ⚡ kill -9 51509
☁ api [master] ⚡ GODEBUG=cgocheck=0 modd

I can get this working with

GODEBUG=cgocheck=0 modd

Some programs create child processes. This utility restarts them too?

Dear people, modd is amazing!

I'm using:

• Windows 10 and
• powershell with
• daemon: go run . in mood.conf,
• with a simply standard golang app with chi router.

Any hint for show colors in terminal?

I can see all lines of the same color (white).

I already read:

• #26
• elm-community/elm-webpack-loader#94

but for Windows nothing.

How to do? Any hope?

go version go1.5 darwin/amd64

./main.go:50: kingpin.CommandLine.HelpFlag undefined (type *kingpin.Application has no field or method HelpFlag)

I use this package from Archlinux User Repository and it just got updated to 0.5 and broke some watching tasks I have that use absolute file patterns, for example:

/tmp/mutt/mutt-* {
	prep +onchange: echo @mods
}

This used to work but doesn't anymore.

I've tried a more basic sample:

/home/francisco/foo/* {
	prep +onchange: echo @mods
}

It also doesn't work, but this does:

foo/* {
	prep +onchange: echo @mods
}

by executing modd from /home/francisco. So only relative patterns are working now.

Test setup was with directories and files already existing, modd running, and I just echo foo >> foo/bar-bar.txt several times.

@cortesi hi. Per my understanding, the current version doesn't support parsing and passing to an environment variable inside the configuration file. I use the patched version, where the variables are available in the modd configuration (with $ prefix) and look pretty similar to the regular variables.
I very close to PR, but have some doubts is the feature really needed. Please drop a comment if so, otherwise just close the ticket. Thank you

I'm likely configuring modd wrong, but I can't seem to get my prep: command to run other than during initial startup.

Here's my modd.conf:

*.foo {
    prep: echo -e "\n\nCHANGED: @mods\n\n"
}

Started modd in one terminal. Ran these shell commands in another:

$ touch file.foo
$ echo content >> file.foo
$ cat file.foo
content

...and this was the output I saw on the modd terminal during those commands:

$ ./modd --debug
15:39:24: prep: echo -e "\n\nCHANGED: \n\n"


CHANGED:


>> done (1.453ms)
15:39:34: notify.Create: "/private/tmp/test/file.foo"
15:39:34: Delta:
Added: [/private/tmp/test/file.foo]
Deleted: []
Changed: []
15:39:40: notify.Write: "/private/tmp/test/file.foo"
15:39:40: Delta:
Added: []
Deleted: []
Changed: [/private/tmp/test/file.foo]

The first CHANGED output is from the startup. Interesting that modd correctly identified the file changes, but didn't run the associated prep: command. Is the modd.conf incorrect?

Lately I am using modd for more and more projects; anything that does not have a pom.xml file, ends up having a modd.conf one.

One feature that I am missing though, is the ability to run modd clean –when I need to cleanup some mess– or modd install –when I am ready to build the final artefacts for a release.

If modd would allow each block to be explicitly named, and invoked both as parameter of the main command (eg. modd install) and from within another block, it should be possible to achieve both these features.

Running a specific "task" as parameter of the main command should avoid enabling file changes monitoring, and exit as soon as the execution completes; invoking a task from within any other task should not change the exit policy of the main tool, though.

Does this make any sense, or is just me being old enough to try to revive some of the patterns I got used to when using make? :)

I'm trying to use modd for web development on windows:

my modd.conf is:

basic config

@shell = exec

*/.go {
prep: go build -o tmp/server.exe -v
daemon +sigkill: ./tmp/server.exe
}

I'm getting this error:
open tmp/server.exe: The process cannot access the file because it is being used by another process.

I've looked with procmon, and it seems that go is unable to rename the file because it's still running.
on windows it's not possible to overwrite an executable currently running.

When modd first starts up, if the prep commands fail, modd exits. This is frustrating, because it means I have to get everything into a good state (tests passing, etc.) before I can actually use modd. Once modd has done a successful round of prep commands, it no longer exits when prep commands fail. I could work around it with #7, I guess, but I'd rather not have to. Why is it the way it is? Are you open to it changing? If so, I can try to pull together a PR.

file modd/test/escaping/a"b make windows git checkout failed

I'm trying to run Modd in Vagrant, and apparently changes made outside the VM do not play nicely with tools for watching filesystem changes (related Stack Overflow). One solution is polling the filesystem for changes.

Would polling fit into the architecture? (Are there any other known Vagrant workarounds for detecting host -> vagrant VM file changes?)

As mentioned in #46, single file watching is broken in 0.5. This happens to be the latest release with uploaded binaries. Any chance of getting binary downloads on release again? This is great for docker environments and others that don't want to deal with an entire go dev environment just to get at the binaries.

I am using modd to rebuild and run a binary when .go files have changed. All works well when I run modd on my host OS, but when I run modd in a Docker container, the daemon as defined in my modd.conf does not restart. It hangs on >> sending signal hangup. Changing the signal to sigterm or sigquit, etc. does not work.

My modd.conf looks like this:

**/*.go {
  prep: make install
  daemon: web-service
}

Do you have any idea what is going on here?

My terminal doesn't support colors or other special characters that flag the terminal to do things. I get stuff like this:

My $TERM is set to dumb, which is the standard value to disable this stuff. Is it possible to support these terminals?

I have a moddfile

**/*.js {
    daemon: BRIGHT_ENV=local node ./tools/devServer.js -p 9999 --src src --dest build
}

This results in modd continuously sending the specified signal to the process. This happens without any file save events

$ GODEBUG=cgocheck=0 modd
15:10:36: daemon: BRIGHT_ENV=local node ./tools/devServer.js -p 9999 --src src --dest build

starting...

rm -rf /Users/sheki/github/brightsolar/api/build
Compiling to /Users/sheki/github/brightsolar/api/build

sending signal hangup
exited: signal: hangup
starting...
sending signal hangup
exited: signal: hangup
starting...
sending signal hangup
exited: signal: hangup
starting...
sending signal hangup
exited: signal: hangup
starting...
sending signal hangup
exited: signal: hangup```

I found the following problem when working within a folder that is symlinked. modd don't triggers any update event when used in a symlinked folder.

The issue can be reproduced with modd 0.2 (x64) on Linux:

mkdir /tmp/dir/subdir/
ln -s /tmp/dir/ /tmp/symlink

cd /tmp/symlink

cat << EOF > modd.conf
subdir/file {
    prep: echo 'Change triggered'
}
EOF

# Start modd in the symlink folder
modd

# Second terminal
touch /tmp/symlink/subdir/file

echo 'First line' >> /tmp/symlink/subdir/file
# No update is triggered

If you suggest using modd with devd, cortesi/devd#18, could you please push a release like you did for devd?

Hi @cortesi, thanks for the cool project! This is a feature/documentation request for running privileged daemons using modd.

I'm having some issues notifying the daemon I'm working on, because it's run as root using sudo. Posting a complete description here with the hope that it helps some users along. Workaround is at the end of the post.

Consider the following example:

**/*.go {
  prep: make
  daemon +sigterm: sudo godoc -http=:80
}

Running the daemon without sudo (and on an unprivileged port) yields the following output:

10:39:35: daemon: godoc -http=:6060
>> sending signal terminated
exited: signal: terminated
>> starting...

Wrapping it with sudo:

10:40:20: daemon: sudo godoc -http=:80
>> sending signal terminated
^C>> stopping

The daemon isn't stopped when stopping modd either.

This is normal behaviour, because the sudo binary has the setuid bit set. Sending signals to privileged processes (eg. pkill sudo) as a normal user is not allowed:

➜  ~  pkill sudo
pkill: killing pid 16666 failed: Operation not permitted

However, unlike pkill, modd doesn't notify the user that sending the signal failed. I presume this is because it signals the pgroup as a whole, not processes individually. This caused me some frustration before I started digging into why this happened.

This workaround worked:

**/*.go {
  prep: make
  prep: sudo pkill godoc || true
  daemon +sigterm: sudo godoc -http=:80
}

Would it be possible to support privileged notification through extending the syntax? eg.:

**/*.go {
  daemon: sudo godoc -http=:80
  signal: sudo kill -TERM @daemon-pid
}

The PIDs to notify could be presented as an internal variable. A signal specification would have to be written right after a daemon statement, so multiple daemons with multiple different custom signal handlers could be supported.

WDYT?

I am using webpack --watch as a daemon command in my modd.conf file. It appears that sending SIGHUP to webpack kills the process, which is not the behavior I want.

Webpack is capable of figuring out that files changed and do a recompile by itself. So what I really want is for the daemon process to not receive any signal. Right now, I can hack it up by sending SIGWINCH.

Here is my modd.conf FWIW:

src/** {
  daemon +sigwinch: webpack -d --watch
}

build/** {
  daemon: devd -m ./build
}

src/**/*.js webpack.config.babel.js !src/static/js/*.js {
  prep: node_modules/.bin/eslint --fix @mods
}

src/hello/lock.json {
    indir: ./src/hello
    prep: dep ensure
}

this works fine when running "modd" but fails when running "modd --prep"

NB: thank you for modd, I really enjoy it

@brenol commented on Mon Mar 28 2016

Hello!

I have a JSON that is shown in the terminal with MarshalIndent and it's not looking good with modd, because of escaping. It's shown because its application configuration, for instance:

{\n\t\t\"Host\": \"http://localhost:8086\",\n\t\t\"Username\": \"user\",\n\t\t\"Password\": \"user\",\n\t\t\"BatchSize\": 1000\n\t}\n}"

I looked at the cli --help and I did not find any solution: Is there any way to disable escaping nowadays?

Thanks!

I believe in prep command @dirmods was previously replaced with paths relative to the working directory of modd. e.g.: "./packageA", "./packageB" ??

It seems that currently it outputs some paths relative, but without the ./. Other paths are given as absolute paths. This totally breaks common use cases such as:

**/*.go {
    prep: go test @dirmods
}

go test needs a relative path prefixed with ./, or otherwise the provided argument is seen as import path. Absolute paths won't work either. It's either a ./ relative to working directory, or and import path that are supported. It would be nice if modd could return to it's original behaviour.

MacOS: 10.14

I am trying to get Growl to work. I have installed Growl from the App Store, and installed the command line utility growlnotify, and verified it works.

When running modd -n — I never seem to be able to trigger a notification.

My modd file is as follows:

cmd/**/*.go pkg/**/*.go {
    prep: go build -o test ./cmd/web/...
    daemon +sigterm: ./test
}

This works as intended, but lacks notifications — any ideas?

In this directory and it's sub directories there are a few files with a '*' in the filename.

https://github.com/cortesi/modd/tree/master/vendor/github.com/bmatcuk/doublestar/test

Because of this I had to use sparse-checkout on windows to be able to clone this repo.

For those interested this is the work around:

Run this command: git config core.sparseCheckout true

Add this file: .git/info/sparse-checkout with this in it:

/*
!vendor/github.com/bmatcuk/doublestar/test/```

Then you'll be able to checkout the rest of the repo normally

This tool is super nice, and is benefiting me greatly with some web development stuff. However, each time I modify the config and restart it, all prep commands are run. They're then subsequently run when the files matching are modified.

I'm using the application to trigger application changes (so, clearing cache, recompiling CSS) when there are file changes. It's not necessary that all of these things be completed when modd is first run -- Only when it changes.

Is it possible to introduce a flag that disables the "inital run" option, and just runs on modification?

Thanks again!

It looks like a recent change to modd broke it's ability to watch for changes on a single file on linux.

e.g. with the following mod.conf:

somefolder/Makefile somefolder/*.go {
    # do stuff
}

This used to work fine, but now breaks with Error watching: readdirent: not a directory. When I remove the first selector (somefolder/Makefile), modd runs fine.

A nasty workarround is to add an asterist, e.g.: someolder/*Makefile, which sill then also match Makefile itself. However, it's not very nice and might result in unexpected behaviour, for example when somefolder/dontMindMe.Makefile is added.

modd successfully catches changes with the following config as stated on the readme,

mydir/symlinkdir/** {
    prep: echo changed
}

but this is not working,

mydir/symlinkdir/some/another/folder/binaryfile {
    prep: echo changed
}

any suggestion?

If ./foo doesn't exist and modd is executed with:

foo/* {
	prep +onchange: echo @mods
}

Then after mkdir foo && echo foo > foo/foo.txt (plus any amount of echo foo >> foo/foo.txt), the current instance of modd won't trigger anything, it's necessary to close and execute it again with an existing directory structure.

The documentation says:

All file names in variables are relative to the current directory

Is it possible to run commands or change directory to the one containing the modd configuration? I found the indir option, but that appears to take a path relative to the current directory as well?

I thought there might be a built in variable for this, but I haven't found it in the docs or the codebase.

had a strange bug that my daemon, when ran through modd had an format string error.
The following program demonstrates the issue:

package main

import "fmt"

func main() {
    fmt.Printf("%s\n", "%ab%cd%ef%gh")
}

the output:

20:38:46: prep: go build -o tmp/server.exe
>> done (78.0005ms)
20:38:48: daemon: ./tmp/server.exe
>> starting...
%!!(MISSING)a(MISSING)b%!!(MISSING)c(MISSING)d%!!(MISSING)e(MISSING)f%!!(MISSING)g(MISSING)h
exited: exit status 0

I traced the error to proc.go:

the out function expects a format string as first parameter, so my output was a bad format string.
the fix is simple - out("%s", string(line))

edit:
I've researched the bug futher, apparently there's another problem in termlog/termlog.go
I've opened an issue there too.

I get the following panic when I use modd with a "prep" rule to watch a file on an SMB volume. OSX 10.10.5, modd 0.3, go 1.6.

panic: unhandled error: notify.FSEventsInodeMetaMod|notify.FSEventsMustScanSubDirs|notify.FSEventsIsDir

goroutine 18 [running]:
panic(0x422e4e0, 0xc82008eec0)
    /usr/local/go/src/runtime/panic.go:464 +0x3e6
github.com/cortesi/modd/vendor/github.com/rjeczalik/notify.(*watch).Dispatch(0xc820096580, 0xc820090ee0, 0x1, 0x1)
    /Users/fcy/go/src/github.com/cortesi/modd/vendor/github.com/rjeczalik/notify/watcher_fsevents.go:136 +0x54f
github.com/cortesi/modd/vendor/github.com/rjeczalik/notify.(*watch).Dispatch-fm(0xc820090ee0, 0x1, 0x1)
    /Users/fcy/go/src/github.com/cortesi/modd/vendor/github.com/rjeczalik/notify/watcher_fsevents.go:205 +0x3e
github.com/cortesi/modd/vendor/github.com/rjeczalik/notify.gostream(0x4c00090, 0x1, 0x1, 0x4a001d0, 0x47ff000, 0x47fe000)
    /Users/fcy/go/src/github.com/cortesi/modd/vendor/github.com/rjeczalik/notify/watcher_fsevents_cgo.go:104 +0x11c
github.com/cortesi/modd/vendor/github.com/rjeczalik/notify._cgoexpwrap_b138320e5461_gostream(0x4c00090, 0x1, 0x1, 0x4a001d0, 0x47ff000, 0x47fe000)
    ??:0 +0x53
github.com/cortesi/modd/vendor/github.com/rjeczalik/notify._Cfunc_CFRunLoopRun()
    ??:0 +0x36
github.com/cortesi/modd/vendor/github.com/rjeczalik/notify.init.1.func1()
    /Users/fcy/go/src/github.com/cortesi/modd/vendor/github.com/rjeczalik/notify/watcher_fsevents_cgo.go:68 +0x112
created by github.com/cortesi/modd/vendor/github.com/rjeczalik/notify.init.1
    /Users/fcy/go/src/github.com/cortesi/modd/vendor/github.com/rjeczalik/notify/watcher_fsevents_cgo.go:70 +0x48

It would be great to allow our developers to install this with:

brew install modd

Then, they do not need a Go development environment configured to easily install it.

Hi, im using modd as a init process in a docker container and just noticed that there are a bunch of defunct processes hanging around (in my case dropbox processes). I've been looking around in the logs but can't really determine if they are exited or crashes processes started by modd or by dropbox itself.
My guess is that there are processes started by other processes so modd would have to wait to reap them i guess?
Let me know if this is total misuse of modd 😄 and I if you want help i could try to fix it.
Thanks for modd and devd btw!

$ go get -v github.com/cortesi/modd/cmd/modd/...
github.com/cortesi/modd/vendor/github.com/rjeczalik/notify
# github.com/cortesi/modd/vendor/github.com/rjeczalik/notify
../../cortesi/modd/vendor/github.com/rjeczalik/notify/watcher_fsevents_cgo.go:51:216: cannot use nil as type _Ctype_CFAllocatorRef in argument to func literal
../../cortesi/modd/vendor/github.com/rjeczalik/notify/watcher_fsevents_cgo.go:169:47: cannot use nil as type _Ctype_CFAllocatorRef in argument to _Cfunc_CFStringCreateWithCStringNoCopy
../../cortesi/modd/vendor/github.com/rjeczalik/notify/watcher_fsevents_cgo.go:170:225: cannot use nil as type _Ctype_CFAllocatorRef in argument to func literal

Go version

$ go version
go version go1.11 darwin/amd64

I started with pattern like ./src/*.js, like suggest in the Readme of devd, but they don't trigger rerunning the block on file changes.

src/*.js works fine.
./src/*.js only runs on startup, but not on file changes.

modd version 0.3
Linux: Linux arch2 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux

I want to handle notifications in a way that's very specific to my environment.

Suggested implementation:

Add command line flag to specify external program to run on command error. The offending command is passed as args to the external program. Stderr from the offending command is passed via stdin to the external program. The external program displays notification to the user.

It woudl appear that if I use absolute path i get error about missing variable.

Eg conf:

/workspace/** {
    prep: echo "mods:" @mods
    prep: echo "dirmods:" @dirmods
}

I spent the better part of a day trying to understand how to use watchman and didn't get anywhere. I spent all of about 30 minutes reading and parsing your README, and I have a working setup that I think I can use for anything. Just wanted to throw out a round of thanks for providing a tool that is remarkably easier to set up than other tools I have tried.

Hi,

I'm up and running with the binary release but only because both go get and building a local copy fail with this error:

$ go build
# .../modd
./daemon.go:29: undefined: termlog.Stream

I already have github.com/cortesi/termlog so I'm not sure where to look next.

Any tips?
Thanks!

Hey there! I just found modd and it's (almost) exactly what I'm looking for. Love what I see. Just wish it actually worked on windows. :)

I did some digging. See: mvdan/sh#325

In particular, mvdan.cc/sh may fail to find environment variable for PATH, which causes the modd shell to fail to find the go executable (or anything else). Even if you hard-code the path to the go executable in the .conf file (or fiddle with the capitalization of your PATH environment variable to get it to work), modd shell still fails to find an appropriate Temp directory. (Perhaps this is because it cannot read the TMP environment variable? I was unable to determine where exactly that process breaks down.)

End result: modd shell basically unusable for anything on Windows until these upstream fixes are merged.

Challenge part 2: those fixes are not part of an official upstream release yet. modd will need to update to mvdan.cc/sh v2.6.2 or as soon as it is available. (Or consider updating to a git hash that has that fix.)

For the time being I find I am forced to use @shell=powershell for anything to work on windows. That's a pain point for things that are supposed to be cross platform. Idea: this would be somewhat less painful if I could (on windows) write something like PS> modd -shell=powershell and still share a cross-platform modd.conf file.

Right now modd overwrites the colors of subprocesses. It would be nice if those colors were preserved.

Hi,
I have the problem, that it takes quite a while to run my prep commands. If I change a file three times and save it each time, the prep commands always get triggered, even if all file changes were already run on the second time.
Is it possible to add a check to see if a new run is unnecessary? So that when the prep command is running and I save two files during that time, the prep command only gets triggered once afterwards.

Unlike FSEvents (OSX) and ReadDirectoryChangesW (Windows), inotify is not recursive. The rjeczalik/notify package half-hides this from us by walking the tree on startup and adding a watch for every directory. However, it doesn't automatically add watches fo directories created after startup, so we don't get notified of events within that directory. To fix this we should monitor changes as they arrive and add watches for newly created directories. Given the design and the layers between us and the OS, it's not clear to me that we can do this entirely without races.

There is some relevant reading here:

https://www.quora.com/Inotify-monitoring-of-directories-is-not-recursive-Is-there-any-specific-reason-for-this-design-in-Linux-kernel

https://mail.gnome.org/archives/dashboard-hackers/2004-October/msg00022.html

The work for this should happen in the cortesi/moddwatch repo, but I'm adding the issue here for visibility.

We may have a similar issue on BSD variants.

See https://tip.golang.org/doc/go1.6#cgo for background.

Using Go 1.6rc2 with github.com/cortesi/modd immediately generates a panic from within this library. To reproduce:

• Use Go 1.6rc2.
• go get -u github.com/cortesi/modd/cmd/modd
• Write a file called modd.conf that contains * {}.
• Execute modd.

Result:

panic: runtime error: cgo argument has Go pointer to Go pointer

goroutine 1 [running]:
github.com/rjeczalik/notify.(*stream).Start(0xc820012700, 0x0, 0x0)
    $GOPATH/src/github.com/rjeczalik/notify/watcher_fsevents_cgo.go:131 +0x270
github.com/rjeczalik/notify.(*fsevents).watch(0xc8200742c0, 0xc82000e7e0, 0x17, 0x100001b00, 0x0, 0x0)
    $GOPATH/src/github.com/rjeczalik/notify/watcher_fsevents.go:206 +0x313
github.com/rjeczalik/notify.(*fsevents).RecursiveWatch(0xc8200742c0, 0xc82000e7e0, 0x17, 0x1b0000001b00, 0x0, 0x0)
    $GOPATH/src/github.com/rjeczalik/notify/watcher_fsevents.go:258 +0x51
go.(*struct { github.com/rjeczalik/notify.watcher; github.com/rjeczalik/notify.recursiveWatcher }).RecursiveWatch(0xc820086140, 0xc82000e7e0, 0x17, 0xc800001b00, 0x0, 0x0)
    <autogenerated>:50 +0x7c
github.com/rjeczalik/notify.(*recursiveTree).Watch(0xc8200880a0, 0xc82000e7e0, 0x17, 0xc8200a86c0, 0xc82000aaa8, 0x1, 0x1, 0x0, 0x0)
    $GOPATH/src/github.com/rjeczalik/notify/tree_recursive.go:286 +0xad6
github.com/rjeczalik/notify.Watch(0xc82000aaa0, 0x5, 0xc8200a86c0, 0xc82000aaa8, 0x1, 0x1, 0x0, 0x0)
    $GOPATH/src/github.com/rjeczalik/notify/notify.go:64 +0x7d
github.com/cortesi/modd/watch.Watch(0xc82000e780, 0x2, 0x2, 0x5f5e100, 0xc8200a84e0, 0xc82000e780, 0x0, 0x0)
    $GOPATH/src/github.com/cortesi/modd/watch/watch.go:301 +0x145
github.com/cortesi/modd.runOnChan(0xc8200a84e0, 0x4383390, 0x4b002f0, 0xc820012600, 0xc82000e680, 0x4307bb0, 0xb, 0xc82004fdb8, 0x0, 0x0, ...)
    $GOPATH/src/github.com/cortesi/modd/modd.go:89 +0x4d6
github.com/cortesi/modd.Run(0x4b002f0, 0xc820012600, 0xc82000e680, 0x4307bb0, 0xb, 0xc82004fdb8, 0x0, 0x0, 0x4013277, 0x0, ...)
    $GOPATH/src/github.com/cortesi/modd/modd.go:141 +0xbe
main.main()
    $GOPATH/src/github.com/cortesi/modd/cmd/modd/main.go:102 +0x9a2

Modd ignore changes in nested folders
Tryed:

**/*.go
/src/**/*.go
/src/foldername/*.go

Modd prints @mods at first run, but ignore changes.

With this modd.conf:

**/*.go {
    daemon +sigint: PGDATABASE=soapbox_dev PGSSLMODE=disable soapboxd
}

modd works perfectly.

With this one:

**/*.go {
    daemon +sigint: PGDATABASE=soapbox_dev PGSSLMODE=disable go run cmd/soapboxd/main.go
}

modd tried to kill the process but fails on mac os x. It hangs at:

15:57:58: daemon: PGDATABASE=soapbox_dev PGSSLMODE=disable go run cmd/soapboxd/main.go
>> starting...
2017/08/07 15:58:00 soapboxd listening on 0.0.0.0:9090
>> sending signal interrupt

I'm guessing that this has something to do with the parent process being go, rather than the daemon itself? Or something like that?

Soapboxd is a very basic grpc server, and I'm on go 1.8