Better handling of values containing backslashes

[jasonmccreary]

trafficstars

Currently backslashes (and possibly other characters) are being lost from values as they are passed through Artisan. These need to be escaped so they are preserved in the final output. An appropriately placed call to addslashes should to the trick.

Example curl command:

curl --request POST https://example.com/pdf/extract --header 'Content-Type: multipart/form-data' --form 'file=C:\Users\secret\files\007.pdf'

[Treggats]

Seems like an issue in how the Http client receives/parses the option. Will some source diving later.

[Treggats]

The input is parsed by the StringInput class, which tokenises the input. Which is fine, but there it strips the slashes. Which in turn is passed back into our CurlCommand.

I'm doing some more digging wether or not it's possible to adapt the tokenisation, or if there's a way around this.

// vendor/symfony/console/Input/StringInput.php:49
private function tokenize(string $input): array
{
    (..)
    } elseif (preg_match('/'.self::REGEX_QUOTED_STRING.'/A', $input, $match, 0, $cursor)) {
        $token .= stripcslashes(substr($match[0], 1, -1));
    }
    (..)
}

[jasonmccreary]

@Treggats, again, I think if we addclashes before calling Artisan would solve the issue.

[Treggats]

@Treggats, again, I think if we addclashes before calling Artisan would solve the issue.

For sure, but when calling this command it's parsed by the base command class. That's where the issue is.

[jasonmccreary]

Interesting. I would still think there is a way to add slashes before passing the parameters to Artisan. Then again, can't be the only devs to pass slashed values to Artisan commands. So there's probably some option or double output happening elsewhere.

I'll take a look.