$_REMOTE_USER_HOMEshould always be set

Moving from\$ARGS to$ARGS because escaping here meant that the script written to file would have the literal$ARGS in it instead of the expanded result, which was not intended.

Where does ARGS come from and what does it contain? I wonder if we need to worry about quoting and/or newlines?

Right now a'," or\n would/could break the su command, example:

root@5110bc305062:/# su root -c 'echo hi>> there'hibash: -c: line 2: syntax error near unexpected token `newline'bash: -c: line 2: `>'

ARGS comes from the feature. A user could supply additional arguments here that are not covered by the feature. Itcould contain anything but should be in the form of additional command line arguments.

Maybe we need to escape this? (or just drop it altogether)

Gotcha, maybe we could use eval for simplicity?

> ARGS="--foo \"some thing\" --'bar'"> eval "declare -a args=($ARGS)"> declare -p argsdeclare -a args=([0]="--foo" [1]="some thing" [2]="--bar")

Used like this:

code-server "${args[@]}"

You can still do something sneaky, like:

ARGS="$(rm -rf /)"

But I don't know if we need care? Someone could just as well include a malicious feature? 🤷🏻‍♂️

The alternative is that we encode supported code-server flags/opts as explicit feature options, which lets us drop ARGS.

TIL ofeval 😄

I think the best course of action would be to ensure we support every CLI flag with a feature and dropARGS

I'm not sure of a better way to test this other than to grep the created entry point to ensure the directory is in the command to launch code-server

Would it make sense to verify more of the cmdline? Ports, args, etc?

Alt suggestion (to useless use of cat 😼):

Each separate feature test could do their own verifications of this yeah (my next PR is using this approach).

Where does ARGS come from and what does it contain? I wonder if we need to worry about quoting and/or newlines?

Right now a'," or\n would/could break the su command, example:

root@5110bc305062:/# su root -c 'echo hi>> there'hibash: -c: line 2: syntax error near unexpected token `newline'bash: -c: line 2: `>'

Would it make sense to verify more of the cmdline? Ports, args, etc?

Alt suggestion (to useless use of cat 😼):

Gotcha, maybe we could use eval for simplicity?

> ARGS="--foo \"some thing\" --'bar'"> eval "declare -a args=($ARGS)"> declare -p argsdeclare -a args=([0]="--foo" [1]="some thing" [2]="--bar")

Used like this:

code-server "${args[@]}"

You can still do something sneaky, like:

ARGS="$(rm -rf /)"

But I don't know if we need care? Someone could just as well include a malicious feature? 🤷🏻‍♂️

The alternative is that we encode supported code-server flags/opts as explicit feature options, which lets us drop ARGS.