Update entrypoint for argument quoting

[glensc]

Update entrypoint for argument quoting so that word splitting does not lose spaces in arguments.

Also, release memory from shell process. Besides releasing resources (memory), this is very important in docker containers so that signals get routed properly to PID=1.

Q	A
Documentation	yes/no
Bugfix	yes
BC Break	yes/no
New Feature	yes/no
RFC	yes/no
QA	yes

Description

[Ocramius]

so that word splitting does not lose spaces in arguments.

My bash-fu is weak, but would -v --something-else work then? Wouldn't that break when quoting?

EDIT: the exec bit for signaling is unclear: isn't bin/console.php treated as a child process that signals back recursively?

[glensc]

without exec ps would look like:

bash-5.1# ps axwuf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1   2564  2068 pts/0    S    10:26   0:00 bash
root        28  0.0  0.0   1672   776 pts/0    R+   10:26   0:00  \_ bin/console

with exec the bash process is eliminated:

bash-5.1# ps axwuf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.1  0.0   1660   964 pts/0    Ss   10:25   0:00 bin/console

• https://www.google.com/search?q=bash+exec+signal+routing+docker

[glensc]

• $@ would expand "i am a wizard" as "i" "am" "a" "wizard"
• while "$@" would not do the word splitting and keep space in argument value: "i am a wizard"

lmgtfy:

• https://stackoverflow.com/questions/3898665/what-is-in-bash

[Ocramius]

Right, and if I pass in "-v --something-else" I would expect "-v" and "--something-else".

As for with/without exec: it is very clear to me that we have PID 1, then PID <N> (as a child), but what I'm saying is that this should be OK if not even wished.

[glensc]

You don't want or need the child process here. Child process is useful if there's code after the child process, but here it is not, child is the final runtime of the script (container). Simplified explanation: when using exec, instead of spawning a new child and monitoring its status in the main process, the main process is just replaced by the child. And in fact, bash doesn't even do proper monitoring that init process ought to do, therefore projects like https://github.com/krallin/tini are created.

Do you want me to extract two changes to separate PRs or why this is still on hold?

[Ocramius]

or why this is still on hold?

It's on hold because I don't understand the details, and not understanding the details means I won't merge it until I do, and am ready to maintain it afterwards: there's no need to be passive-aggressive about it.

And in fact, bash doesn't even do proper monitoring that init process ought to do

Sounds like the best solution would be to get rid of bash overall: what about replacing the entrypoint with the PHP script entirely?

but here it is not, child is the final runtime of the script (container).

We still spawn git and gpg processes from it, but via symfony/console, which is much stricter about their execution.

[glensc]

Right, and if I pass in "-v --something-else" I would expect "-v" and "--something-else".

what do you mean by "pass", where? you need to realize that where you type the command in has it's own quoting styles.

Here's example from bash with my patch:

# gets $argv[1]="-v", $argv[2]="a value"
docker run --rm yourapp -v --something="a value"
# gets $argv[1]="-v", $argv[2]="a value"
docker run --rm yourapp -v --something='a value'
# gets $argv[1]="-v --something=false"
docker run --rm yourapp "-v --something=false"

without my patch you would get:

# gets $argv[1]="-v", $argv[2]="a", $argv[3]="value"
docker run --rm yourapp -v --something="a value"
# gets $argv[1]="-v", $argv[2]="--something=false"
docker run --rm yourapp "-v --something=false"

[glensc]

but here it is not, child is the final runtime of the script (container).

We still spawn git and gpg processes from it, but via symfony/console, which is much stricter about their execution.

none of that is related (read: nothing changes for them).

[glensc]

And in fact, bash doesn't even do proper monitoring that init process ought to do

Sounds like the best solution would be to get rid of bash overall: what about replacing the entrypoint with the PHP script entirely?

Right, no need to bash wrapper at all, so here's the PR:

• Replace bash wrapper for entrypoint #100