#Dagger shell's with-exec and nested quotes

1 messages · Page 1 of 1 (latest)

bleak sun
#

I can't make quotes work inside with-exec -- sh -c '<something here with quotes>'

✔ container | from alpine | with-exec -- sh -c 'echo hello world' | stdout 0.0s
hello world                                                                                                                                                                                                                                                                                                                   

✘ container | from alpine | with-exec -- sh -c 'echo "hello world"' | stdout 0.0s
! function "with-exec": invalid argument "echo \"hello world\"" for "--args" flag: parse error on line 1, column 6: bare " in non-quoted-field
! Usage: with-exec <args> [--use-entrypoint] [--stdin string] [--redirect-stdout string] [--redirect-stderr string] [--expect ReturnType] [--experimental-privileged-nesting] [--insecure-root-capabilities] [--expand] [--no-init]

And if I run this from a dagger script, there is NO error whatsoever and the exit code is 0. Which seems quite misleading...

Is this a bug?
How to work around this? Some env vars point to directories that might have spaces in names. It would be unfortunate if rm got such a variable as an argument... Normally I'd be using quotes around the var, but it doesn't seem to work in dagger shell

sharp aspen
bleak sun
#
container | from alpine| with-exec sh,-c,'echo "hello world"' | stdout

this doesn't :/

sharp aspen
#

this works container | from alpine| with-exec sh,-c,"echo 'hello world'" @bleak sun

bleak sun
#

thanks. So no way to have double quotes nested inside single quotes?

shell does not interpolate variables in single quotes. It only interpolates in double quotes, a heredoc or w/o any quotes. heredocs are not supported everywhere, no-quote is prone to IFS tokenization.

It would really be nice to have it working properly, w/o having to remember all those exceptions, which sometimes may as well be blockers

#
  • if it's an error, should it not be hinted so in any way when running a daggerscript from file?

IDK, maybe it's just me, but dagger feels quite inconsistent with.. well.. inconsistent behaviour. This being one of such

hybrid jay
#

seems like a bug to me

sharp aspen
#

agree it seems to be a bug. I think it doesn't know how to escape the " as it's trying to send that over to the function argument. @red merlin probably knows about this 🙏

red merlin
red merlin
#

Here's the thing, I was thinking we can just skip additional flag parsing in with-exec, but it's from a specific set of conditions:

  • if the function has only one required argument and it's a []string
  • and if more than 1 positional argument has been provided
  • then we can skip additional flag parsing and use the positional arguments as the argument value directly

This means that with-exec -- sh -c 'echo "hello world"' will pass withExec(args: ["sh", "-c", "echo \"hello world\""]) directly to the query builder, which fixes the error. It also allows passing in commas like with-exec -- trivy fs --severity MEDIUM,HIGH,CRITICAL ....

The reason for "more than 1 positional argument" is to still support passing a single comma separated value, like with-exec sh,-c,"echo 'hello world'" as there's a lot of examples using it out there.

red merlin
bleak sun
red merlin