exec

[Bulb]

Yesterday I became proud author of this bash hack:

exec() {
    unset exec
    exec "$@" "${extra_opts[@]}"
}

The script then goes on to source /docker-entrypoint.sh, which I want to reuse, but I need to add options to the final exec "$@" that should not appear in the other places where it uses "$@" so…

[Gąska]

@Bulb is this function undeclaring itself on first call?

[Bulb]

@Gąska Yes, it is. Because 1) it couldn't call the original command otherwise and 2) since it never returns, there won't be any other call.

[dkf]

@Bulb For anything other than exec, it'd make more sense to use builtin THETHING. Actually, it probably makes more sense to do that anyway, if just because it is one line less code…

[Gąska]

@Bulb any particular reason you can't just modify the script to remove the last exec call, and put it in main script instead?

[Bulb]

@Gąska The script is in the docker container, while the wrapper is injected by kubernetes when starting it. To modify the script I would either have to copy it out—and maintain it—or edit it with sed, which would be a different, but equally ugly, hack.

[Gąska]

@Bulb I see. I've asked because I've seen a good number of people making elaborate hacks to work around bad code they're actually in charge of and it simply never occured to them to get rid of the original issue instead of hacking around it.

[Bulb]

@Gąska In this case the script is in the official MariaDB Docker container and I am bolting some functionality on top of it. And, as added complication, the customer will run the application once with the official container, and once with some other container, where the script might be slightly different, but will almost certainly also end with the exec "$@" statement. So overriding the exec is probably easiest to adapt to that other container too.

[loopback0]

@Bulb said in exec:

The script then goes on to ... docker