I'm torn here, as I would also like consistency but I also do not
want to break existing scripts (ours or others) that rely on the
existing syntax. One way forward is to create new tools which
wrap previous tools with new syntax. This wouldn't be too hard,
although it would add to the already high number of names
in $FSLDIR/bin. What do people generally think about this?
All the best,
Mark
On 2 Mar 2010, at 15:37, Michael Hanke wrote:
> On Tue, Mar 02, 2010 at 03:15:14PM +0000, Rolf Heckemann wrote:
>> I second the pleading. FSL currently does a great job of mimicking
>> all those inconsistencies in the unix world, but perhaps it would be
>> nicer for users if it stopped doing that and mimicked, say, GNU tools
>> instead, which are much more internally consistent.
>
> FSL is a slightly more than 100 lines of code. What you ask for is
> something that needs a little longer than an afternoon. If you (or
> anyone else interested in having this changed) have a patch that does
> the modifications for _all of FSL_ we could test-drive it on a fork of
> the Debian package.
>
> But be aware that you would have to put some manpower into maintaining
> such patch until it has proven to be fully functional _and_ migrated
> into FSL proper....
>
> Michael
>
>
>
>> On Tue, Mar 02, 2010 at 02:38:35PM +0000, Stephen Smith wrote:
>>>
>>> Just like across all Unix tools you mean?
>>>
>>> :)
>>>
>>> On 2 Mar 2010, at 14:34, wolf zinke wrote:
>>>
>>> Hi,
>>> I am really grateful for the FSL package and the great support.
>>> Thank
>>> you so much for providing it for free and also giving such a
>>> thorough
>>> support.
>>> However, nothing can't be perfect and there is always space for
>>> improvements. One aspect that I encounter pretty often when
>>> doing some
>>> scripting is a inconsistency of function arguments between
>>> different
>>> tools. I think this is most clear when comparing flirt and fnirt.
>>> While flirt uses the '-' convention with a space before the next
>>> argument, fnirt uses '--' with only '=' between the argument.
>>> Furthermore, some arguments seem to be named differently, eg
>>> 'nn' and
>>> 'nearestneighbour' for the interpolation method. I am currently
>>> writing a small wrapper script that switches between fnirt and
>>> flirt,
>>> and I need to build in some ad hoc correction routines that
>>> translate
>>> the arguments. It would be great, if such workarounds could be
>>> avoided
>>> by using the arguments in a consistent manner between the various
>>> tools.
>>> I guess that such inconsistencies are rare and a result of the
>>> development history, but whenever I encounter them they disturb my
>>> workflow quiet a bit :'( . So I just wanted to make this
>>> suggestion.
>>> Please don't feel offended, since I really do like working with
>>> the
>>> FSL tools.
>>> thanks,
>>> wolf
>>>
>>>
>>> ----------------------------------------------------------------------
>>> -----
>>> Stephen M. Smith, Professor of Biomedical Engineering
>>> Associate Director, Oxford University FMRIB Centre
>>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
>>> +44 (0) 1865 222726 (fax 222717)
>>> [1][log in to unmask] [2]http://www.fmrib.ox.ac.uk/~steve
>>>
>>> ----------------------------------------------------------------------
>>> -----
>>>
>>> References
>>>
>>> 1. mailto:[log in to unmask]
>>> 2. http://www.fmrib.ox.ac.uk/~steve
>>
>> --
>> Rolf A Heckemann, MD PhD
>> Médecin chercheur
>> Fondation Neurodis
>> CERMEP - Imagerie du Vivant
>> Hôpital Neurologique Pierre Wertheimer
>> 59 Boulevard Pinel
>> 69003 Lyon
>> France
>>
>>
>> 1267542281
>>
>
>
>
> --
> GPG key: 1024D/3144BE0F Michael Hanke
> http://mih.voxindeserto.de
>
|