3dbucket / foreach error

AFNI Message Board
1

AFNI version info (afni -ver): Version AFNI_23.2.10

I am experiencing an error when trying to use a foreach loop for a 3dbucket script. I am relatively inexperienced with Linux, but this error does not occur when using in conjunction with other AFNI programs (e.g., AFNI_proc.py).

The error I receive is foreach: Words not parenthesized.

I have tried a number of different ways of structuring the foreach loop (e.g., excluding the set subj line, using ${subj} vs {$subj}) but receive this error each time.

#!/bin/tcsh -xef
#uses 

foreach subj (1000 1001 1002)
set subj = {$subj}

3dbucket -overwrite ~/Subjects/{$subj}/{$subj}.RS.results/stats.{$subj}_REML+tlrc'[7]' -prefix ~/Group_Analysis/BOLD_VF.Rest/RS/data/stats.{$subj}_REML
echo {$subj}

end
2

Hello,

I am not sure where a foreach error would come from, but for programs that take input as the last argument(s), any prefix option must precede the input. So try:

3dbucket -overwrite -prefix ~/Group_Analysis/BOLD_VF.Rest/RS/data/stats.{$subj}_REML \
    ~/Subjects/{$subj}/{$subj}.RS.results/stats.{$subj}_REML+tlrc'[7]'
  • rick
3

Also, you don't need the set subj ... line in your script; that's the job of the foreach to set the subj variable in each iteration of the loop.

4

Hi-

From googling a bit, it seems like that error message comes up if you have word like "in" used in your foreach ... line, like:

foreach subj in (1000 1001 1002)
    echo ${subj}
end

Is it possible that you had a version of your code doing that, at some point? Otherwise, I don't see how that would be happening with what you posted. To not get that error message, indeed you would use this proper syntax (which is like what you posted) instead, without that word "in":

foreach subj (1000 1001 1002)
    echo ${subj}
end

Also, on a sidenote, in shell syntax, you indeed use a $ character to start a variable name, like $name or $name_var_can_have_underscores. It is also possible to use curly brackets to more clearly delimit the bounds of the variable name, like ${name} and ${name_var_can_have_underscores}. This typically only matters if your variable is written next to something where it could be confusing to the shell/you about where it starts and ends, like in a string. Consider:

"$name_new.nii.gz"

The shell will think the full variable name is $name_new, but if you are trying to append _new.nii.gz to a variable $name, you would write this instead as:

${name}_new.nii.gz

In general, I am in the habit of using curly brackets to not have to worry about this, and to see variable names more easily. However, please note that if you are doing this, it is done with ${name}, not {$name}. The syntax of curly brackets outside the variable definition does something else---namely, you can provide a list of values to be expanded in like a list, something like: ls something_{lh,rh}.nii.gz, which could be used to list both something_lh.nii.gz and something_rh.nii.gz if those files exist on the computer. In your case, I don't think this difference and your actual usage is causing woe (your curly bracket usage is still just insulating the variable name, so it is OK), but at some point more subtle things might be happening.

--pt