Skip to content

[2.6] Backport parser fixes from 3.3.0 - #325

Merged
GrahamCampbell merged 4 commits into
2.6from
parser-backport
Jan 28, 2019
Merged

GrahamCampbell merged 4 commits into
2.6from
parser-backport

Conversation

@GrahamCampbell

@GrahamCampbell GrahamCampbell commented Jan 28, 2019 •

Copy link
Copy Markdown
Collaborator

Note that this DOES NOT implement identical parsing to in 3.x. Every attempt has been made to ensure this backport behaves exactly as in 2.5.x, and also allows cases that previously crashed in 2.5.x, being as lenient as possible (where identical case in 3.3.x will hard fail).

This fixes the example from #332.


How does this differ from the parsing in 3.3+:

  1. Unquoted values without spaces starting with a hash are considered to be comments in 3.3+ but in 2.x are treated as literal values.
  2. Invalid escape sequences within quoted values in 2.5 fail silently, in 2.6 are permitted, and in 3.x will fail loudly (with a proper error message in 3.3+).

Example 1:

FOO=#foo

2.5: parses as #foo
2.6: parses as #foo
3.2: parses as #foo (considered a bug in the 3.x series)
3.3: parses as the empty string

Example 2:

FOO=#foo bar

2.5: parses as the empty string
2.6: parses as the empty string
3.2: parses as the empty string
3.3: parses as the empty string

Example 3:

FOO="#foo"

2.5: parses as #foo
2.6: parses as #foo
3.2: parses as #foo
3.3: parses as #foo

Example 4:

FOO="iiiiviiiixiiiiviiii\n"

2.5: fails silently
2.6: parses as iiiiviiiixiiiiviiii\n
3.2: fails with an obscure preg error
3.3: fails saying invalid escape sequence

Example 5:

FOO="iiiiviiiixiiiiviiii\\n"

2.5: parses as iiiiviiiixiiiiviiii\n
2.6: parses as iiiiviiiixiiiiviiii\n
3.2: parses as iiiiviiiixiiiiviiii\n
3.3: parses as iiiiviiiixiiiiviiii\n

@GrahamCampbell GrahamCampbell changed the title Backport new parser design, keeping BC [2.6] Backport new parser design Jan 28, 2019
@GrahamCampbell GrahamCampbell changed the title [2.6] Backport new parser design [2.6] Backport parser fixes from 3.3.0 Jan 28, 2019
@GrahamCampbell
GrahamCampbell merged commit f3aae28 into 2.6 Jan 28, 2019
@GrahamCampbell
GrahamCampbell deleted the parser-backport branch January 28, 2019 20:57
@mbrodala

Copy link
Copy Markdown

For some reason lines like foo='spaces with single quotes' now lead to an error:

PHP Fatal error:  Uncaught Dotenv\Exception\InvalidFileException: Dotenv values containing spaces must be surrounded by quotes. in /.../vendor/vlucas/phpdotenv/src/Parser.php:7

Changing the quotes from single (') to double (") fixes this. However, we need single quotes to escape $ in some values.

Is this intentional?

@GrahamCampbell

Copy link
Copy Markdown
Collaborator Author

Thanks for the report. It looks like we're missing some tests.

@mbrodala

mbrodala commented Jan 29, 2019 •

Copy link
Copy Markdown

Apparently single quotes are now parsed literally in general so we cannot use them for escaping $ at all anymore:

  • foo='$bar' (fails)
  • foo="\$bar" (fails)
  • foo="$bar" (works, but can lead to issues with pure shell sourcing)

@GrahamCampbell

Copy link
Copy Markdown
Collaborator Author

Please could you create an issue for this, and I'll fix today.

@mbrodala

Copy link
Copy Markdown

Did that now with #337

@mbrodala

Copy link
Copy Markdown

I am not sure either what did change, I can only see that the behaviour has changed. I wouldn't mind using double quotes everywhere if I had a way to escape $.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants