> >As an interim measure, it would probably be easier if the could
> >detect the use of redirection (|<>) and prepend the command with
> >either "cmd /c" or "sh", depending on environment... that way, people
> >could use commands they are familiar with and get the full power of
> >redirection using NAnt, and it would be easier to port existing
> >scripts into NAnt in a piece-by-piece fashion.
>
> That might be easier, though I'd certainly like the shell to be
> configurable. But I don't believe NAnt will ever be a total replacement
> for shells or scripting languages, nor should it be. If you're running
> two different programs in a single NAnt exec, then I think it's clearer
> to just create a script that does it and have NAnt just call that
> script. A major reason that scripts become unmaintainable is that
> people don't refactor by extracting functions; the same applies to NAnt.
>
> Gary
Moving this one to the developers list, because I think I'd like these
ideas documented (in-list) a little more...
I have no issues with making the shell configurable, that's definitely
a Good Idea, although the actual nature of how to configure it would
probably need discussion. Would it be a normal (magical) property, or
a special parameter like the logger? Presumably it could be
overridden locally by the exec task itself?
I'm not sure that I understand what you mean by using an external
script to run multiple programs, but if I do then I don't think I
agree with you... if the programs are chained in a single expression,
then that could be encapsulated in a single call (delegating to
the shell). If there are several programs to be run in some order,
then that's flow control, which I think is more part of NAnt's
territory, so makes more sense to use multiple calls. The only
exception to this last that I can think of is where you want the
combined output from each program to be concatenated into a single
file - this (intent) would probably be more obvious with a single
call catching the output than with multiple calls with
the same output (does exec even support appending to the output file
rather than overwriting?)
An example of the first... say there's a legacy script which lists all
the files in a directory, sends it to a perl script for processing,
then pipes the result through an ftp client. The easiest way for this
to be ported to NAnt is if it could be brought across intact:
If NAnt were to introduce pipe support, then this could be split into
multiple execs and dependence on the shell would be diminished...
In this example, using NAnt pipes rather than a single exec probably
decreases maintainability of the script by itself, by increasing cut
and paste (in the pipe names)... but the idea is to add extra
opportunities to improve the script - perhaps the perl script could be
replaced with a NAnt script element in C# (or whatever is the
incumbent language in the organisation), reducing the number of
scripts to track and maintain, and the number of languages in the mix
- slowly improving the maintainability.
Also, pipes could allow the circumstance mentioned above (multiple
programs whose output is combined into a single file) to be naturally
performed in NAnt:
Then again, I'm not porting or maintaining build scripts at the
moment... maybe this is all just adding extra features to NAnt that
will need to be maintained that won't actually improve the language,
just provide more options for how things can be done.
Thoughts or input from others solicited and encouraged.
--
Troy
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
