Troy Laurin wrote:
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?
What's wrong with
<exec shell="cmd" ...>
where the shell attribute is optional?
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 <exec> call (delegating to
the shell).
That's the case I'm talking about. It's the difference between
<exec commandline="getfiles | filter .cs | filter modified_today |
sort -size" />
and
<exec commandline="getTodaysCSfilesInSizeOrder.sh" />
where I'm taking liberties with the syntax, since exec today can only
take one program.
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 <exec> calls. The only
Flow control is in the territory of every procedural language. I don't
see why to favor NAnt for it.
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
<exec> call catching the output than with multiple <exec> calls with
the same output (does exec even support appending to the output file
rather than overwriting?)
Actually, it does: append={"True"|"False"} is an option.
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:
<exec program="ls" commandline="| perl makeftpscript.pl | ftp" />
If NAnt were to introduce pipe support, then this could be split into
multiple execs and dependence on the shell would be diminished...
<exec program="ls" output="|ftp1" />
<exec program="perl makeftpscript.pl" input="|ftp1" output="|ftp2" />
<exec program="ftp" input="|ftp2" />
But if you do it this way, there's virtually no difference between using
a pipe and using a temporary file, at least as far as the way it's
written. You could just as easily say output="${temp}/ftp1", etc. The
only issue is cleaning up the files, which can be handled by using one
of a number of possible temp directories. But my point is that it's
still clearer to write
<exec program="FtpFilesToRemoteNode" />
and let the FtpFilesToRemoteNode contain
ls | perl makeftpscript.pl | ftp
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.
I don't agree with either of those as valid measures. Try to keep the
number of scripts to a minimum is what leads to monolithic scripts on
the UNIX side, which are not particularly maintainable. A better
measure is how much text, not how many files the text is spread across.
This is similar to the design philosophy of having each object
responsible for just one thing, with a multitude of very simple objects.
As for languages, I've always felt that software engineers should be
fluent in several. While I don't think there should be a multitude of
redundant languages - i.e., pick just one of Perl, Python, or Ruby - I
also don't believe there's enough overlap between NAnt and most other
languages or that NAnt is functional enough to justify using a NAnt as a
replacement for anything more than cmd.exe.
Also, pipes could allow the circumstance mentioned above (multiple
programs whose output is combined into a single file) to be naturally
performed in NAnt:
<output-pipe name="|file" />
<exec program="cmd1" output="|file" />
<exce program="cmd2" output="|file" />
<write-pipe name="|file" file="${filename}" />
As indicated above,
<exec program="cmd1" output="${filename}" />
<exec program="cmd2" output="${fielname}" append="True" />
already works, and is shorter.
Gary
-------------------------------------------------------
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_id=7477&alloc_id=16492&op=click
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
