Re: [PATCH v2 01/10] t: add helper to convert object IDs to paths
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jun 19, 2019, 19:55 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1906192119380.44@tvgsbejvaqbjf.bet>
- In-Reply-To
- <20190618170416.GA14636@sigill.intra.peff.net>
Hi Peff,
On Tue, 18 Jun 2019, Jeff King wrote:
Show 31 quoted lines
> On Tue, Jun 18, 2019 at 06:15:46PM +0200, Johannes Schindelin wrote:
>
> > > And looking through this patch series, I see a gazillion of *new*
> > > process substitutions $(test_something...) and $(basename $whatever).
> > > Can't we do something about it?
> >
> > I wish there was. Unix shell scripting has not evolved much in the past,
> > what, 3 decades? So I don't really see a way to "pass variables by
> > reference" to shell functions, short of calling `eval` (which buys
> > preciously little as it _also_ has to spawn a new process [*1*]).
>
> Really? An eval can impact the caller's state, so it _can't_ happen in a
> sub-process in most cases.
>
> E.g., if I run this:
>
> -- >8 --
> #!/bin/sh
>
> # usage: test_oid_to_path <var> <oid>
> # to set the variable <var> in the caller's environment to the path of <oid>
> test_oid_to_path() {
> path="${2%${2#??}}/${2#??}"
> eval "$1=\$path"
> }
>
> test_oid_to_path foo 1234abcd
> echo foo: $foo
> -- >8 --
>
> it all happens in a single process, under both bash and dash.Oops. I think I may have read too much into the name `eval.c` in Dash's source code, I assumed that it was all about the `eval` command. But now that I look at this again, I see:
/* * Execute a command inside back quotes. If it's a builtin command, we * want to save its output in a block obtained from malloc. Otherwise * we fork off a subprocess and get the output of the command via a pipe. * Should be called with interrupts off. */
void
evalbackcmd(union node *n, struct backcmd *result)
{
[...]I saw this at https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/eval.c#n608
So this is actually about `$(...)` (or the old, non-nestable backtick version of it) and not about `eval`.
And of course I was also making another incorrect connection to the Perl command `eval` which allows you to catch code that `die()`s (which *must* run in a subprocess).
So yeah, I guess `eval` would work here to avoid the `$(...)` constructs.
Sorry for the noise, Dscho