Should work in Condor version: 7.2
 
-When Condor is not busy running jobs from users, you may want it to run some other “backfill” task. Condor provides special support for backfilling with BOINC. However, the built-in support assumes that BOINC can decide for itself how many tasks to run in order to fill the idle cpus on a multi-cpu/core machine. At this time (BOINC 6.4), there is no such capability in BOINC. Therefore, the built-in support for BOINC is only really capable of backfilling a single slot. (If you set it up, Condor may show multiple slots in the backfill state, but in fact only a single instance of BOINC will be running and it will be running a configurable but constant number of work units in parallel—typically just one.)
+When Condor is not busy running jobs from users, you may want it to run some other “backfill” task. Condor provides special support for backfilling with BOINC. However, the built-in support assumes that BOINC can decide for itself how many tasks to run in order to fill the idle cpus on a multi-cpu/core machine. At this time (BOINC 6.4), there is no such capability in BOINC. Therefore, the built-in support for BOINC is only really capable of backfilling a single slot. (If you set it up, Condor may show multiple slots in the backfill state, but in fact only a single instance of BOINC will be running and it will be running a configurable but constant number of work units in parallel—typically just one.)
 
-To get around that problem, there is a different way to configure Condor to run BOINC backfill (or any other type of backfill task). It uses the startd’s fetch-work hook to run one instance of the backfill task per idle Condor slot. Here is an example configuration:
+To get around that problem, there is a different way to configure Condor to run BOINC backfill (or any other type of backfill task). It uses the startd’s fetch-work hook to run one instance of the backfill task per idle Condor slot. Here is an example configuration:
 
 {code}
 BOINC_HOME = /opt/boinc
@@ -13,7 +13,7 @@
 BOINC_InitialDir = $(BOINC_HOME)/var/$(BOINC_SLOT)
 BOINC_Owner = backfill
 BOINC_User = backfill@your.domain
-BOINC_Arguments = —allow_multiple_clients -attach_project http://einstein.phys.uwm.edu <insert_id>
+BOINC_Arguments = -allow_multiple_clients -attach_project http://einstein.phys.uwm.edu <insert_id>
 BOINC_Output = $(BOINC_HOME)/var/$(BOINC_SLOT)/boinc.out
 BOINC_Error = $(BOINC_HOME)/var/$(BOINC_SLOT)/boinc.err
 BOINC_Requirements = \
@@ -24,14 +24,14 @@
 # configure the startd to run BOINC backfill jobs
 STARTD_JOB_HOOK_KEYWORD = BOINC
 BOINC_HOOK_FETCH_WORK = $(BOINC_HOME)/fetch_work_boinc
-RANK = $(RANK) – (Owner =?= "backfill")
+RANK = $(RANK) &#8211; (Owner =?= "backfill")
 {endcode}
 
 The above example starts up BOINC after 20 minutes of the slot being unclaimed. (You will see an entry in the startd logs each time the startd calls out to the fetch-work script. The note says that the job requirements were not met whenever the above requirements expression is not true.)
 
-The BOINC jobs will run as “backfill”. It assumes BOINC has been installed in /opt/boinc/BOINC and directories for each instance of BOINC have been created in /opt/boinc/var/slot_1, slot_2, etc. The slot_X directories should be owned by the “backfill” user (or whatever user you have configured the slot to run as).
+The BOINC jobs will run as &#8220;backfill&#8221;. It assumes BOINC has been installed in /opt/boinc/BOINC and directories for each instance of BOINC have been created in /opt/boinc/var/slot_1, slot_2, etc. The slot_X directories should be owned by the &#8220;backfill&#8221; user (or whatever user you have configured the slot to run as).
 
-The “fetch_work_boinc” script can just be a shell script such as the following:
+The &#8220;fetch_work_boinc&#8221; script can just be a shell script such as the following:
 
 {code}
 #!/bin/sh