watchexec: Can't pass argument containing a whitespace to underlying command without quoting the entire command

See difference in following:

$ watchexec /usr/bin/printf '[%s]' foo 'bar baz'
[foo][bar][baz]
^C

vs

$ /usr/bin/printf '[%s]' foo 'bar baz'                                                                                                                          
[foo][bar baz]

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 21 (12 by maintainers)

Commits related to this issue

Most upvoted comments

My argument hasn’t changed: it’s such a core part that I still need more than just a few people saying it’s unintuitive. I would rather not change it to find that everyone else hates it.

As comparison: I have good evidence that everyone does hate the ignores system, also a core part. There’s been a dozen different issues reported over the years, plenty of confusion about it either directly creating problems or exacerbating them. So yeah, that’s gonna go. It’s complicated and will take a lot to basically replace from the ground up, but it eventually will.

I don’t nearly have the same level of discontent with this. All up, maybe four people? Over three years? And you already have an option to switch it. Do you want an option to switch behaviour to “disallow multiple args when using shell, but allow them with -n”? Or look, config files are gonna land soon, so you could switch your local default, would that be enough?

That could maybe solve simple cases, but not e.g. 'echo a; echo b', echo `echo ‘bar baz’`

I think this whole thing could be cleared up if we simply disallowed multiple arguments unless -n is passed.

Anyone who expects watchexec to be able to do something sensible when given multiple strings and told to “make them into a shell command” (in some way that differs from running a program named by the first string and passing the remaining strings as command-line arguments) has very weird expectations, in my opinion.

This is the same situation as Python’s subprocess module has. You can pass either a string, which is run via sh -c, or you can pass a list of the program name and the command-line arguments. There is no option to pass a list of strings and have them somehow concatenated into a shell command, because that use case simply doesn’t make sense.

[I arrived at the above conclusions after looking more clearly at the -n flag, and now believe that my previous comment is pretty much just wrong and silly.]