Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I know that in ~/.bashrc one must not put spaces around = signs in assignment:

$ tail -n2 ~/.bashrc 
alias a="echo 'You hit a!'"
alias b = "echo 'You hit b!'"

$ a
You hit a!

$ b
b: command not found

I'm reviewing the MySQL config file /etc/my.cnf and I've found this:

key_buffer_size = 1024M
innodb_buffer_pool_size = 512M

How might I verify that the spaces around the = signs are not a problem?

Note that this question is not specific to the /etc/my.cnf file, but rather to *NIX config files in general. My first inclination is to RTFM but in fact man mysql makes no mention of the issue and if I need to go hunting online for each case, I'll never get anywhere. Is there any convention or easy way to check? As can be seen, multiple people have edited this file (different conventions for = signs) and I can neither force them all to use no spaces, nor can I go crazy checking everything that may have been configured and may or may not be correct.

EDIT: My intention is to ensure that currently-configured files are done properly. When configuring files myself, I go with the convention of whatever the package maintainer put in there.

share|improve this question
There is no such thing as "*NIX config files in general". If I want to allow spaces in my config file, I will write my program to allow them. If I want my config file to use colons or pipes instead of equal signs, then I will write my program to use them. Bash requires no spaces. Mysql allows them. –  hymie Jul 24 '14 at 17:06

6 Answers 6

up vote 3 down vote accepted

I'll answer that in a more general way - looking a bit at the whole "Unix learning experience".

In your example you use two tools, and see the language is similar. It just unclear when to use what exactly. Of course you can expect there is a clear structure, so you ask us to explain that.
The case with the space around = is only and example - there are lot's of similar-but-bot-quite cases.
There has to be a logic in it, right?!

The rules how to write code for some tool, shell, database etc only depend on what this particular tool requires.

That means that the tools are completely independent, technically. The logical relation that I think you expect simply does not exist.

The obvious similarity of the languages you are seeing are not part of the programm implementation. The similarity exist because developers had agreed how to do it when they wrote it down for a particular program. But humans can agree only partially.

The relation you are seeing is a cultural thing - it's neither part of the implementation, nor in the definition of the language.

So, now that we have handeled the theory, what to do in practise?

A big step is to accept that the consistency you expected does not exist - which is much easier when understanding the reasons - I hope the theory part helps with this.

If you have two tools, that do not use the same configuration language (eg. both bash scripting), knowing the details of the syntax of one does not help much with understanding the other;
So, indeed, you will have to look up details independently. Make sure you know where you find the reference documentation for each.

On the positive side, there is some consistency where you did not expect it: in the context of a single tool (or different tools using the same language), you can be fairly sure the syntax is consistent.
In your mysql example, that means you can assume that all lines have the same rule. So the rule is "space before and after = is not relevant".

There are wide differences in how hard it is to learn or use the configuration- or scripting language of a tool.
It can be some like "List foo values in cmd-foo.conf, one per line.".
It can be a full scripting language that is used elsewhere too. Then you have a powerful tool to write configuration - and in some cases that's just nice, in others you will really need that.
Complex tools, or large famillies of related tools sometimes just use very complex special configuration file syntax - (some famous examples are sendmail and vim).
Others use a general scripting language as base, and extend that language to support the special needs, some times in complex ways, as the language allows. That would be a very specific case of a domain-specific language (DSL).

share|improve this answer
Accepted as this is the answer that most addresses the answer from the question's point of view. Thanks! –  dotancohen Jul 27 '14 at 13:24

Bash will interpret a line that has text followed by a = as an assignment to a variable, but it will interpret a line that has text followed by a space as a command with an argument.

var=assignment vs command =argument

Bash scripts work on the principle that everything in the script is as if you have typed it into the command line.

In configuration files that aren't interpreted by bash (or another shell), it will be determined by the parser that is used to read the configuration file. Some parsers will take spaces, some won't. It's up to the application in that case. Personally, I go with whatever convention the default configuration file has used.

share|improve this answer
Thanks. I'm worried about how to check the extant files, now and in the future, that may have been configured by other budding devops types. When configuring files myself, I go with the convention of whatever the package maintainer put in there, as you suggest. I've edited the question to clarify. –  dotancohen Jul 24 '14 at 9:46
I guess if your checking existing files, I'd check the documentation of the product and use that as an example. Assuming you have documentation and it's not a custom built application. If it was a custom application, I'd stick with whatever was already there. "If it ain't broke, don't fix it" –  Lawrence Jul 24 '14 at 9:49
Unfortunately, some of them are broke. That's why I'm asking! –  dotancohen Jul 24 '14 at 10:17
In shells, don't ever use spaces around an equals. In anything that's not a shell, always use spaces. You can audit existing files using grep: 'grep "[^ ]=[^ ]" /etc/*' to find files with an = that doesn't have spaces. –  qris Jul 24 '14 at 12:53
@dotancohen (1.) For any config file, there should be at least one setting that it would be rather easy to check if it is broken. Whether a config file allows spaces or not, it should do so consistently throughout. (2.) You can always download an application and check the default configs it ships with. (3.) You can always leave out spaces altogether. a = b may not always be acceptable but a=b should always work. –  Two-Bit Alchemist Jul 25 '14 at 3:46

.bashrc is nothing more than a config file for bash, just like my.cnf, php.ini, httpd.conf or a launchd plist. Each has their own syntax, ranging from the no-space assignment of bash to the XML tag soup of launchd (there's also a binary version :-O )

There are no firm conventions, and you have already discovered the Prime Directive of Unix: Read The Fine Manual.

share|improve this answer
.bashrc is not a config file for bash. .bashrc is a shell script which bash runs every time a bash process starts. It can be used to configure bash but it can be used to do all sorts of other things too: it's a script, not a config file. –  Josh Jul 25 '14 at 5:34

Some programs offer a check of the configuration file, for example:

postfix check

Otherwise you could get the original config files from the repositories and compare them with diff to the current.

share|improve this answer
Actually, this looks like it really does address the core issue. Thanks! –  dotancohen Jul 24 '14 at 16:04

The spaces around = sign is always problem when you do an assignment in bash. There is no exception here, you must remove all spaces around = if you want to get a valid simple assignment (no expansion, no arithmetic, no array assignment)in bash.

For config file, because each software has its own parser to parsing its config file, bash has no relationship. You must read the documentation to know what syntax is allowed in config file.

An example is mysql, in its init script /etc/init.d/mysqld, it has a parser for my.cnf:

# Try to find basedir in /etc/my.cnf
  if test -r $conf
    dirs=`sed -e "/$subpat/!d" -e 's//\1/' $conf`
    for d in $dirs
      d=`echo $d | sed -e 's/[  ]//g'`
      if test -x "$d/bin/my_print_defaults"
      if test -x "$d/bin/mysql_print_defaults"
share|improve this answer
There's an exception in (( var = 12 )) or var=( value ) or $((var = 12)) or ${var[foo = 12]} –  Stéphane Chazelas Jul 24 '14 at 15:23
@StéphaneChazelas: Didn't about those cases in this question, add information. Thanks. –  cuonglm Jul 24 '14 at 15:29

I would say that when you use a bash command that means attribute a value to something, the sign = means assigment and you need to remove spaces around or it will attribute the space also.

While in a config file where = is to seperate a key from a value, you can or not put a space without problem and it will not take any special meaning.

share|improve this answer
The fact that the configuration is or may be ignored is a problem. If we configure (or think that we configured) MySQL to use 4 GiB RAM and it only uses 1 GiB (due to our misconfiguration) then that is a problem. –  dotancohen Jul 24 '14 at 9:45
No, in bash, a variable assignment needs the = directly after the name. With a space before, it just is not a variable assignment at all. The tight side value can start with a space, but you need to quote it, so the first char after the = would be a quote char of some sort. In foo=' bar' and foo=\ baz work in bash. –  Volker Siegel Jul 25 '14 at 0:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.