HCPpipelines
HCPpipelines copied to clipboard
TaskfMRILevel2.v?.0.sh - Contrasts with whitespaces in titles
I had problems with NumContrasts being wrongly set in TaskfMRILevel2.v?.sh. The problem was that I had spaces in my contrast names. The easy solution is to replace "wc -w" with "wc -l" in the calculation in those scripts.
Thanks -
Richard Watts, University of Vermont
If you want to generate a pull request we can accept it.
I'm not convinced that the proposed change will actually work as expected.
The ContrastNames
variable is populated by a statement that looks like:
ContrastNames=`cat ${FirstFolder}/design.con | grep "ContrastName" | cut -f 2`
This selects the "second field" from the lines in the design.con
file that have ContrastName
in them. The lines that have ContrastName
in them look something like:
/ContrastName1 CUE
/ContrastName2 LF
...
/ContrastName14 neg_CUE
/ContrastName15 neg_LF
...
/ContrastName25 AVG-RH
/ContrastName26 AVG-T
Assigning the results of this cat
, grep
, and cut
operation to the variable ContrastNames
gives it a value that looks like:
CUE LF ... neg_CUE neg_LF ... AVG-RH AVG-T
The value of the ContrastNames
variable is a space separated list of contrast names. It does not contain a set of separate lines, one line per contrast name.
Assigning a value to NumContrasts
using a statement like:
NumContrasts=`echo ${ContrastNames} | wc -w`
counts the number of space separated words in the ContrastNames
variable to come up with the number of contrasts. Using a statement like:
NumContrasts=`echo ${ContrastNames} | wc -l`
would count the number of lines in the ContrastNames
variable.
I've tested this by finding one of the design.con
files and executing the following statements:
$ ContrastNames=`grep "ContrastName" design.con | cut -f 2`
$ echo ${ContrastNames}
CUE LF LH RF RH T AVG CUE-AVG LF-AVG LH-AVG RF-AVG RH-AVG T-AVG neg_CUE neg_LF neg_LH neg_RF neg_RH neg_T neg_AVG AVG-CUE AVG-LF AVG-LH AVG-RF AVG-RH AVG-T
$ NumContrasts=`echo ${ContrastNames} | wc -w`
$ echo ${NumContrasts}
26
$ NumContrasts=`echo ${ContrastNames} | wc -l`
$ echo ${NumContrasts}
1
Using wc -w
gives 26 contrast names as expected. Using wc -l
gives an incorrect result of only 1 contrast name.
I believe the use of the wc -l
instead of the wc -w
would only seem to work, if you actually had only 1 contrast name. I don't believe it would matter whether that name had spaces in it or not. You would always get 1 for the value of NumContrasts
.
I think the best viable solution would be to simply not allow spaces in your contrast names. Following the example above, you could replace the spaces with either underscores, _
, or hyphens, -
.
I may be missing something here, but I'd be curious to see the value of ContrastNames
for which the wc -l
option works as expected.
I wondered about that but I'm glad you tested it. We could still use his suggestion if we ensured that the new lines are not converted to spaces with quotes.
The white spaces remain an issue for contrasts generated by FIR designs (contrast names are automatically generated with white spaces) like condition1 (1) condition1 (2) condition1 (3) condition1 (4)
using wc -c gives double the number of contrasts.
Using this construct instead might resolve this issue, but would need to be tested (and if there are any blank lines, that may throw it off):
NumContrasts=`echo "$ContrastNames" | wc -l`
Note, wc -c counts the number of bytes, and will give far more than double the desired answer.
Reopening, as this appears to have been closed too soon in the first place.
Also, the reason that just adding quotes around ContrastNames should work is that bash converts newlines to spaces when expanding a variable without quoting, and even a simple var=$(ls)
will keep the newlines in the variable (I often use quotes on assignment statements simply to make it more obvious, and so that spaces in a literal string can be preserved without being parsed as an altered-environment command). So, @tbbrown was incorrect in stating that ContrastNames was space-separated.
Tim, your suggestion did indeed fix it but as you say, probably needs to be tested further.