A program to open various AFNI/SUMA files
afni_open [OPTIONS] FILE1 [FILE2 ...]
Examples:
afni_open xmat.1D.xmat
afni_open -aw roi_11.pdf
afni_open -r driv
Options:
===========
-w METHOD: Use METHOD to open FILES.
Acceptable values for METHOD are:
editor: Open with text editor.
downloader: Fetch with wget or curl.
browser: Open in browser
afni: Open with AFNI
suma: Open with SUMA
1dplot: Open with 1dplot
ExamineXmat: Open with ExamineXmat
iviewer: Open with image viewer
afniweb: Get from afni website.
readme: Search for appropriate README
This option is in the same spirit of
apsearch -view_readme option. To see a list of
all readme files, run:
apsearch -list_all_afni_readmes
-e: Same as -w editor
-d: Same as -w downloader
-x: Same as -w ExamineXmat
-b: Same as -w browser
-r: Same as -w readme
-aw: Same as -w afniweb
If no method is specified, the program tries to guess
from the filename.
-global_help: Show help for global options.
-gopts_help: Show help for global options.
-help: You're looking at it.
Global Options:
===============
-h: Mini help, at time, same as -help in many cases.
-help: The entire help output
-HELP: Extreme help, same as -help in majority of cases.
-h_view: Open help in text editor. AFNI will try to find a GUI editor
-hview : on your machine. You can control which it should use by
setting environment variable AFNI_GUI_EDITOR.
-h_web: Open help in web browser. AFNI will try to find a browser.
-hweb : on your machine. You can control which it should use by
setting environment variable AFNI_GUI_EDITOR.
-h_find WORD: Look for lines in this programs's -help output that match
(approximately) WORD.
-h_raw: Help string unedited
-h_spx: Help string in sphinx loveliness, but do not try to autoformat
-h_aspx: Help string in sphinx with autoformatting of options, etc.
-all_opts: Try to identify all options for the program from the
output of its -help option. Some options might be missed
and others misidentified. Use this output for hints only.
-overwrite: Overwrite existing output dataset.
Equivalent to setting env. AFNI_DECONFLICT=OVERWRITE
-ok_1D_text: Zero out uncommented text in 1D file.
Equivalent to setting env. AFNI_1D_ZERO_TEXT=YES
-Dname=val: Set environment variable 'name' to value 'val'
For example: -DAFNI_1D_ZERO_TEXT=YES
-Vname=: Print value of environment variable 'name' to stdout and quit.
This is more reliable that the shell's env query because it would
include envs set in .afnirc files and .sumarc files for SUMA
programs.
For example: -VAFNI_1D_ZERO_TEXT=
-skip_afnirc: Do not read the afni resource (like ~/.afnirc) file.
-pad_to_node NODE: Output a full dset from node 0 to MAX_NODE-1
** Instead of directly setting NODE to an integer you
can set NODE to something like:
ld120 (or rd17) which sets NODE to be the maximum
node index on an Icosahedron with -ld 120. See
CreateIcosahedron for details.
d:DSET.niml.dset which sets NODE to the maximum node found
in dataset DSET.niml.dset.
** This option is for surface-based datasets only.
Some programs may not heed it, so check the output if
you are not sure.
-pif SOMETHING: Does absolutely nothing but provide for a convenient
way to tag a process and find it in the output of ps -a
-echo_edu: Echos the entire command line to stdout (without -echo_edu)
for edification purposes
SPECIAL PURPOSE ARGUMENTS TO ADD *MORE* ARGUMENTS TO THE COMMAND LINE
------------------------------------------------------------------------
Arguments of the following form can be used to create MORE command
line arguments -- the principal reason for using these type of arguments
is to create program command lines that are beyond the limit of
practicable scripting. (For one thing, Unix command lines have an
upper limit on their length.) This type of expanding argument makes
it possible to input thousands of files into an AFNI program command line.
The generic form of these arguments is (quotes, 'single' or "double",
are required for this type of argument):
'<<XY list'
where X = I for Include (include strings from file)
or X = G for Glob (wildcard expansion)
where Y = M for Multi-string (create multiple arguments from multiple strings)
or Y = 1 for One-string (all strings created are put into one argument)
Following the XY modifiers, a list of strings is given, separated by spaces.
* For X=I, each string in the list is a filename to be read in and
included on the command line.
* For X=G, each string in the list is a Unix style filename wildcard
expression to be expanded and the resulting filenames included
on the command line.
In each case, the '<<XY list' command line argument will be removed and
replaced by the results of the expansion.
* '<<GM wildcards'
Each wildcard string will be 'globbed' -- expanded from the names of
files -- and the list of files found this way will be stored in a
sequence of new arguments that replace this argument:
'<<GM ~/Alice/*.nii ~/Bob/*.nii'
might expand into a list of hundreds of separate datasets.
* Why use this instead of just putting the wildcards on the command
line? Mostly to get around limits on the length of Unix command lines.
* '<<G1 wildcards'
The difference from the above case is that after the wildcard expansion
strings are found, they are catenated with separating spaces into one
big string. The only use for this in AFNI is for auto-catenation of
multiple datasets into one big dataset.
* '<<IM filenames'
Each filename string will result in the contents of that text file being
read in, broken at whitespace into separate strings, and the resulting
collection of strings will be stored in a sequence of new arguments
that replace this argument. This type of argument can be used to input
large numbers of files which are listed in an external file:
'<<IM Bob.list.txt'
which could in principle result in reading in thousands of datasets
(if you've got the RAM).
* This type of argument is in essence an internal form of doing something
like `cat filename` using the back-quote shell operator on the command
line. The only reason this argument (or the others) was implemented is
to get around the length limits on the Unix command line.
* '<<I1 filenames'
The difference from the above case is that after the files are read
and their strings are found, they are catenated with separating spaces
into one big string. The only use for this in AFNI is for auto-catenation
of multiple datasets into one big dataset.
* 'G', 'M', and 'I' can be lower case, as in '<<gm'.
* 'glob' is Unix jargon for wildcard expansion:
https://en.wikipedia.org/wiki/Glob_(programming)
* If you set environment variable AFNI_GLOB_SELECTORS to YES,
then the wildcard expansion with '<<g' will not use the '[...]'
construction as a Unix wildcard. Instead, it will expand the rest
of the wildcard and then append the '[...]' to the results:
'<<gm fred/*.nii[1..100]'
would expand to something like
fred/A.nii[1..100] fred/B.nii[1..100] fred/C.nii[1..100]
This technique is a way to preserve AFNI-style sub-brick selectors
and have them apply to a lot of files at once.
Another example:
3dttest++ -DAFNI_GLOB_SELECTORS=YES -brickwise -prefix Junk.nii \
-setA '<<gm sub-*/func/*rest_bold.nii.gz[0..100]'
* However, if you want to put sub-brick selectors on the '<<im' type
of input, you will have to do that in the input text file itself
(for each input filename in that file).
* BE CAREFUL OUT THERE!
------------------------------------------------------------------------
++ Compile date = Oct 17 2024 {AFNI_24.3.03:linux_ubuntu_24_64}
