6 ms·
I'd say: Don't use the shell if what you want to do is to execute another program. You don't need to handle any quoting with exec*(). You still need to handle
by panzi 1y ago
I'd say: Don't use the shell if what you want to do is to execute another program.
You don't need to handle any quoting with exec*(). You still need to handle options, yes. But under Windows you always have to to handle the quoting yourself and it is more difficult than for the POSIX shell and it is program dependent. Without knowing what program is executed you can't know what quoting syntax you have to use and as such a standard library cannot write a generic interface to pass arguments to another process in a safe way under Windows.
I just felt it sounded like POSIX is particularly bad in that context, while in fact it is better than Windows here. Still, the system() function is a mistake. Use posix_spawn(). (Note: Do not use _spawn*() under Windows. That just concatenates the arguments with a space between and no quoting whatsoever.)
- oguz-ismail 1y ago>Still, the system() function is a mistake. Use posix_spawn(). They are entirely different interfaces though. If you'd implemented system() using posix_spawn() it'd be just as bad as system()
- panzi 1y agoWhy would you implement system() at all?
- oguz-ismail 1y agoBecause I don't want to implement a shell???
- panzi 1y agoIf you want to run a shell script, run a shell script. I.e. a text file with the executable bit set and a shebang. If you want to generate a shell script on the fly to then run it, take a step back and think about what you're doing.
- oguz-ismail 1y agoOr I can just use system() because it's there and not going anywhere
- theamk 1y agoparse commands from config file? command-line arguments for hooks? https://news.ycombinator.com/item?id=44239036 https://news.ycombinator.com/item?id=44239036
- panzi 1y agoI understand that it is convenient for running small snippets like that, but I don't really think it's worth the risk. And putting it into a config file is different, IMO. You don't get tempted to do some bad string interpolation there, because you can't, unless the config file format has support for that, but then I criticize that. If you need to pass things to such a snipped do it via environment variables or standard IO, not string interpolation. If you say you don't make such mistakes: Yeah, but people do. People that write the code that runs on your system.
- theamk 1y agoBut if you want a command-line option for hook, what are the alternatives? Force user to always create a wrapper script? that's just extra annoyance and if user is bad at quoting, they'll have the same problems with a script Disable hooks at all? that's bad functionality regression Ask for multiple arguments? this makes command-line parsing much more awkward.. I have not seen any good solutions for that. (The only exception is writing a command wrapper that takes exactly 1 user command, like "timeout" or "xargs".. but those already using argument vector instead of parsing)
- frumplestlatz 1y agoYou define a config file format that supports only the minimal syntax required to specify a multi-argument command (e.g. spaces separate arguments, arguments with spaces in them may be quoted or use backslashes to escape them). Then, you parse that out into a proper argument array and pass it to exec*/posix_spawn.
- account42 1y agoSo instead of a well known (i.e. POSIX) quoting semantics and existing tool support, you want to introduce your own ad-hoc format? No thanks.