`assume --exec` broken?

[abusch]

I might be using it wrong, but it seems that assume --exec <cmd> is broken if the command has more than 1 argument. For instance assume --exec "aws dynamodb list-tables" fails with:

usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help

aws: error: argument command: Invalid choice, valid choices are:
...

After a bit of investigation and debugging, it looks like all the arguments are smooshed together with spaces removed, so the command it tries to execute is aws dynamodblist-tables.

This was tested on bash and fish.

[abusch]

I suspect this might have something to do with the strings.Join(execCfg.Args, "") in this line (which probably should be strings.Join(execCfg.Args, " ")).

[JoshuaWilkes]

Thanks for raising this @abusch

For now you should be able to run assume --exec -- aws dynamodb list-tables

Using -- after the exec flag means you don't need to use quotes around your command.

I will look into the issue with the quoted exec syntax

[abusch]

Unfortunately, using -- doesn't seem to work, neither with bash nor fish. I'm getting the same issue.

[alqh]

PLus 1 to this issue...

--exec -- docker compose up

produces the following error:

docker: 'composeup' is not a docker command.

I'm on v0.20.5

It seems like its broken since v0.20.4

[lyoung-confluent]

I think @abusch correctly identified the root-cause as #549, I confirmed this by running assumego --verbose <profile> --exec -- aws sts get-caller-identity which shows that the multiple separate arguments are being correctly parsed:

[DEBUG] exec config:&{aws [sts get-caller-identity]}

However when the GrantedExec output is generated the final argument GRANTED_12 is the concatenated values:

GrantedExec <key> <secret> None us-west-2 None false None None None None aws stsget-caller-identity

Unfortunately I don't think fixing this is as easy as switching from "" to " " though because the IFS=' ' read line would read the additional arguments as different variables (ex: GRANTED_13, GRANTED_14, etc)...

[abusch]

I think the fix should work as long as the command to execute is the last variable. According to the read man page, the last variable should contain the whole remainder of the line, no matter if the separator appears in it or not.

[lyoung-confluent]

@abusch You're right, that's convenient, though the fix was a bit more nuanced as arguments with spaces need to be maintained as single arguments so have to be shell escaped: #584