coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New utility suggestion: chdir(1)


From: Colin Watson
Subject: Re: New utility suggestion: chdir(1)
Date: Sun, 27 Aug 2017 08:14:42 +0100
User-agent: NeoMutt/20170113 (1.7.2)

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                                       [address@hidden]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]