Re: [nant-dev] Re: [Nant-users] Problem with exec and input redirection to file
Gary, we seem to have a difference in underlying principles. I don't want to imply (that I think) that your principles/opinions are wrong, I'm just presenting mine as an alternative, and partial justification for my opinions. Well, then... On 6/29/05, Gary Feldman <[EMAIL PROTECTED]> wrote: > 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 > > > > where the shell attribute is optional? Absolutely nothing, but should there be a mechanism to set/override the default shell on a per-buildfile or per-invocation level? This would only affect exec calls that don't specify their own shell, so I'm not sure how useful it would really be... Actually, I've just back-flipped. Changing shells is likely to be disruptive enough that it shouldn't be as dynamic as a property or option. With the differences in how different shells handle quoting, and escaping, and redirecting, it probably makes most sense for a shell-sensitive command to explicitly: Perhaps it would be better for NAnt to recommend this approach than perform any magic "shelling" of commands under the covers. > That's the case I'm talking about. It's the difference between > > > and > > where I'm taking liberties with the syntax, since exec today can only > take one program. Liberties accepted. I don't think your second invocation is better than your first, but more on that below. > >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 > > > Flow control is in the territory of every procedural language. I don't > see why to favor NAnt for it. We're not comparing NAnt with procedural languages. We're comparing NAnt with shell scripts. And unless you're willing to install a unix shell in a Windows environment (with all the associated forward/backslash issues), NAnt is more portable. > >If NAnt were to introduce pipe support, then this could be split into > >multiple execs and dependence on the shell would be diminished... > > > 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. More on pipes below. > But my point is that it's still clearer to write > > > > and let the FtpFilesToRemoteNode contain >ls | perl makeftpscript.pl | ftp I personally think that this is an anti-pattern. It is a workaround to the fact that NAnt currently doesn't have support for pipes (so is using temporary files, incidentally). It obscures the flow of the script by segueing into a different file and exacerbates this by changing language as well. To be fair, it also mitigates both of these by using a meaningful name for the script, but that's documentation, not functionality - you can achieve the same effect by moving the exec into a similarly-named target. None of these things are issues for the person who wrote the scripts, and maintains them as part of his/her job. But that's not the point of maintainability. Each little obfuscation makes the system a little harder to learn, and to understand, for a new person asked to do some work on or pick up the build system. > >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. I like to think that NAnt compares favourably to unix-style scripting, because of an expressive syntax and support for modularising a (build) task through targets, and to a lesser extent child build files. I know unix-style scripts can do both of these, but the focus IMHO is inverted - more to subscripts, and less to functions. Regarding having less text in the entire build system, executing external scripts which perform magic rather than inlining that magic into the NA
RE: [nant-dev] Re: [Nant-users] Problem with exec and input redirection to file
Hello, mine 2 cents to this: - first I liked those pipe idea proposed - but Gary is mostly right - there is alot stuff possible via output/append - only missing is input redirection? - last line in example should be equivalent for pipe - intermediate files are cached by system, so no big slowdown I think. Not important IMHO. - I'd disagree with Gary in some points like - NAnt is great in flow control. - external shells could be hell. I personally trying to do all stuff in NAnt. - external shells are hard to maintain and port to other OS, NAnt script is not. Martin Aliger --- 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
Re: [nant-dev] Re: [Nant-users] Problem with exec and input redirection to file
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
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 call (delegating to
the shell).
That's the case I'm talking about. It's the difference between
and
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 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
call catching the output than with multiple 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:
If NAnt were to introduce pipe support, then this could be split into
multiple execs and dependence on the shell would be diminished...
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
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:
As indicated above,
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
[nant-dev] Re: [Nant-users] Problem with exec and input redirection to file
> >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
