Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EnvironmentFile= honours backward slashes (unexpectedly) #10659

Closed
galaxy4public opened this issue Nov 6, 2018 · 4 comments

Comments

@galaxy4public
Copy link
Contributor

commented Nov 6, 2018

It is unexpected that when a file is fed to EnvironmentFile= variables' values containing backward slashes are processed as special. The documentation does not mention such a behaviour and it just seems wrong.

The expected behaviour would be if systemd parses the environment files as close to the way shell does as possible, i.e.:

VAR1=\value
VAR2="\value"
VAR3='\value'

For VAR1 the value should be value (since \v is in a bare string and is just v), but VAR2 and VAR3 should have values of \value.

Right now, systemd is resolving escapes unconditionally and it makes life very hard since you cannot source the same environment file from scripts (if there are backward slashes).

@boucman

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2018

to what extent is that variable-expansion logic universal ? do all shells agree to the rules you described ?

@galaxy4public galaxy4public changed the title EnvironmentFile= honours forward slashes (unexpectedly) EnvironmentFile= honours backward slashes (unexpectedly) Nov 7, 2018

@OhNoMoreGit

This comment has been minimized.

@galaxy4public

This comment has been minimized.

Copy link
Contributor Author

commented Nov 7, 2018

Yes, there is a standard: The Open Group Base Specifications (IEEE Std 1003.1-2017). Specifically, Section 2, subsections from 2.2.1 to 2.2.3:

2.2.1 Escape Character (Backslash)
A <backslash> that is not quoted shall preserve the literal value of the following character,
with the exception of a <newline>. If a <newline> follows the <backslash>, the shell shall
interpret this as line continuation. The <backslash> and <newline> shall be removed before
splitting the input into tokens. Since the escaped <newline> is removed entirely from the
input and is not replaced by any white space, it cannot serve as a token separator.

2.2.2 Single-Quotes
Enclosing characters in single-quotes ( '' ) shall preserve the literal value of each character
within the single-quotes. A single-quote cannot occur within single-quotes.

2.2.3 Double-Quotes
Enclosing characters in double-quotes ( "" ) shall preserve the literal value of all characters
within the double-quotes, with the exception of the characters backquote, <dollar-sign>, and
<backslash>, as follows [...]

P.S. I amended the title of the issue since I mistyped and put "forward" instead of "backward" slash.

@poettering

This comment has been minimized.

Copy link
Member

commented Nov 8, 2018

hmm, yeah, for environment files we should really follow shell syntax in that point

kragniz added a commit to kragniz/systemd that referenced this issue Jan 14, 2019
kragniz added a commit to kragniz/systemd that referenced this issue Jan 14, 2019
kragniz added a commit to kragniz/systemd that referenced this issue Jan 14, 2019
kragniz added a commit to kragniz/systemd that referenced this issue Jan 14, 2019
kragniz added a commit to kragniz/systemd that referenced this issue Jan 15, 2019
kragniz added a commit to kragniz/systemd that referenced this issue Jan 17, 2019
util-lib: follow shell syntax for escape in quotes
Fixes systemd#10659.

This changes the behaviour of parsing environment files to more closely
follow POSIX shell standards.

This has the effect that these variables defined in a file:

    VAR1='\value'
    VAR2="\value"

Are now interpreted as `\value` instead of interpreting the `\`
character and interpreting them as `value`.

For more information about the behaviour followed, see:

	http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.