[lloeki]

Regarding the watermark generation process, although the bash script works, I immediately reach for my old friend (GNU) make(1) for that kind of task. Here's the Makefile:

    all: watermark
    
    done:=$(wildcard *-BD.pdf)
    src:=$(filter-out $(done),$(wildcard *.pdf))
    marked:=$(patsubst %.pdf,%-BD.pdf,$(src))
    
    watermark: $(marked)
    
    %-BD.pdf: %.pdf
    	./watermark_script.sh $< $@

The done+filter-out mumbo jumbo is there just because without it, -BD.pdf would be matched by .pdf, and therefore would generate -BD-BD.pdf... and so on (this is a loophole that the original bash script has, if parallel runs are timed correctly). Putting the output files in another directory is left ans an exercise for the reader.

The inotify script becomes:

    inotifywait -e create /home/user/pdfs && make -C /home/user/pdfs

There is another loophole here, in that the -BD.pdf are created in that directory, so the script gets run again. It doesn't matter for our makefile, which will do nothing on the second run, but there is the 'parallel runs if timed correctly' issue of the original bash script.

Generally, GNU make has a bunch of very interesting facilities, making it much, much more powerful than its ancestors (BTW, people interested may want to take a look at an implementation of non-recursive make[0], which — while being awesome — also shows up some useful make tricks).

Now, regarding the filesystem events and userland tools (which are awesome), I wish there was a unified front-end for this kind of things (inotify on Linux, fsevents on OSX...)

PS: I wish the comment form supported something like markdown, so that I could escape those wildcards, and more.

[0] http://stackoverflow.com/questions/559216/what-is-your-exper...

[rb2k_]

I'm sorry if I missed this, but why would you use make instead of bash?

[lloeki]

    make figures out which files need updating
    make allows to write pattern rules (.c.o:, or %.o: %.c)
    you don't need to move files out of the 'inbox'
      to ignore them
    regenerating a file is a touch(1) away
    make is descriptive, not imperative (invaluable
      readability when you're coming back on it years later)
    should you ever need a second transformative step or
      a new dependency, it's trivial to insert, and make
      will figure stuff out
    make can trash intermediate results automatically
    make is crazy fast
    make variables are not environment variables
    make has multiple variable assignations, resulting in
      some early/late evaluation system (early with :=,
      late with =, $() is always late unless part of a :=)
    make outputs commands as they're executed (not with a global)
    make outputs nothing when commands are prefixed with @ (not with a global)
    make interrupts itself on a chain failure
    each make recipe line is executed in a distinct shell

You can set bash to do some of those things, or you can write bash code that do some of those, but most of the time you end up just coercing bash into behaving like make.

Of course I would not write everything in make. But knowing what make can do makes it the obvious choice for some tasks, and helps you coming up with a robust task/generator system in a snap, whereas coming up with a task/generator system in bash quickly is already not that easy, and making it robust even less.

[stonefroot]

"make is crazy fast"

Make calls the shell in order to run programs, correct?

(IOW, does make call execve directly, as the shell does?)

[lloeki]

Indeed, execve in exec_command (job.c). That does not make it slow, since it's the very last part of the game, and one you could not really do without.