On Sat, Aug 26, 2017 at 06:23:33PM -0700, Kaz Kylheku (Coreutils) wrote: > On 26.08.2017 11:10, Colin Watson wrote: > > sudo chroot /path/to/chroot sh -c 'cd /foo && ls -l' > > The -c option is not the only way to pass a script to the shell. > > You can also pipe it in. > > > This means dealing with shell quoting, which is tedious and error-prone. > > sh <<'end' > echo 'hello, world' > end
I don't really want to derail too much into this kind of thing, but let's just say that this approach still requires dealing with shell quoting, just in a slightly different way. Any time your approach involves composing input to the shell from caller-supplied data, you have to make sure that the shell is going to decompose that in the way that you want, regardless of how you then arrange for the shell to actually read that input. Your example above contains a manually-quoted argument to echo, which is all very well when you're dealing with a single command constructed by hand; if you were writing a general wrapper function that takes arbitrary command+argument lists then you'd see what I meant. If you're using "sh -c", then you need a *second* layer of quoting to ensure that the argument stays in one piece, and if the calling language is shell then that's going to be shell quoting. Piping a script into the shell avoids this layer of quoting, yes, but (1) that's not very interesting when the calling language is something with a good list syntax for invoking subprocesses, (2) it doesn't remove the need for the first layer of quoting, and (3) it makes it cumbersome to supply data to the subsidiary program's standard input (yes, I know it can be done if you try hard enough). In any case, I'm really not looking for help with shell quoting here, but rather suggesting a way to avoid the issue together. A good general rule of thumb in my experience is that robust code that invokes subsidiary programs should try to do so without introducing intermediate shells if it possibly can. -- Colin Watson [cjwat...@debian.org]
