When are spaces around the = sign forbidden?

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.

Asked By: dotancohen


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.

Answered By: Lawrence

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"
Answered By: cuonglm

.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.

Answered By: paul

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.

Answered By: user78568

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).

Answered By: Volker Siegel
Categories: Answers Tags: ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.