24

I am adding an env variable to /etc/environment but because the variable value contains # sign, string is stripped.

MYSQL_PWD="something#no"

Now if I do env above code yields MYSQL_PWD=something. How can I escape hash? I've already tried \ character.

Thomas Dickey
  • 76,765
Umair A.
  • 353
  • 1
  • 2
  • 5

5 Answers5

24

This doesn't appear to be possible with /etc/environment. It's meant as a common location for variables that's shell independent. Given this it doesn't look like it supports strings with hash marks (#) in them and there doesn't appear to be a way to escape them.

I found this SF Q&A titled: How does one properly escape a leading “#” character in linux etc/environment?. None of these methods worked:

  • control="hello"
  • test0="#hello"
  • test1="h\#ello"
  • test2="h#ello"
  • test3="h//#ello"
  • test4="h/#ello"
  • test5=h#ello
  • test6=h\#ello
  • test7=h#ello
  • test8=h//#ello
  • test9=h/#ello
  • test10='h#ello'
  • test11='h\#ello'
  • test12='h#ello'
  • test13='h//#ello'
  • test14='h/#ello'

The accepted answer to that question and what would also be my advice:

Well it is tricky stuff you want to do /etc/environment is not shell syntax, it looks like one , but it is not, which does frustrates people. The idea behind /etc/environment was wonderful. A shell-independent way to set up variables! Yay! But the practical limitations make it useless.

You can't pass variables in there. Try for example put MAIL=$HOME/Maildir/ into it and see what happens. Best just to stop trying to use it for any purpose whatsoever, alas. So you can't do things with it that you would expect to be able to do if it were processed by a shell.

Use /etc/profile or /etc/bashrc.

Yet still another Q&A gave this rational as to why this is the case:

There is no way in /etc/environment to escape the #(as it treated as a comment) as it is being parsed by he PAM module "pam_env" and it treats it as a simple list of KEY=VAL pairs and sets up the environment accordingly. It is not bash/shell, the parser has no language for doing variable expansion or characters escaping.

References

slm
  • 369,824
  • is that a bug or there's any reason behind it? – Umair A. Oct 26 '13 at 22:14
  • 2
    @UmairAshraf - not a bug, just limited functionality given the role of this file. This file spans across multiple shell technologies so it has to go with features that are supported in all the shells it will be used in. – slm Oct 26 '13 at 22:15
  • 1
    It might be useful to add information regarding pam_env.conf file. It is read right before /etc/environment by pam, and as suggested by the man page of pam_env.conf (that documents the use of both these files) can use variables and some for of escaping. – Ivan Lerner Jun 15 '23 at 18:00
5

Single quote within a double quote worked for me. Might help someone

test="'h/#ello'"
0

Testing with NodeJS (specifically in an Express app), if the variable contains reserved characters, you can put the entire variable in quotation marks.

EXAMPLE_VAR = he#llo
FIXED_EXAMPLE_VAR = "he#llo"

Then trying to use the variables:

console.log(process.env.EXAMPLE_VAR); // outputs `he`
console.log(process.env.FIXED_EXAMPLE_VAR); // outputs `he#llo`
-1

Probably too late, but three backslashes before # worked for me.

If the password is, say "admin#123", you can define it as

admin\\\#123
Stephen Kitt
  • 434,908
-1

Replace # with %23.

For example from:

postgres://user:#password#@server:port/database

To:

DB_URI="postgres://user:%23password%23@server:port/database"
αғsнιη
  • 41,407