From: Peter R. <p.r...@sh...> - 2010-11-17 13:29:02
|
On 17/11/10 08:44, Tomi Ollila wrote: > On Tue 16 Nov 2010 13:15, Peter Rockett<p.r...@sh...> writes: > >> One point that I have always wondered about: What was the original >> motivation of the UNIX creators in going for the fork() mechanism in the >> first place? Especially since it is invariably(?) followed by an exec*() >> call. (fork + exec* = spawn?) Does anybody know the history? > > I can give 3 examples why fork(2) (with or without or instead of) execve(2) > are one of the best inventions in computer science. > > > 1) fork(s) without exec > > #!/bin/sh > > ... > > case $# in 0) find . -name '*.src' ;; > *) for f; do echo $f; done ;; > esac | while read line; do basename "$line"; done > exit $? > > (2 forks (initially) there, for the pipeline. In use in a bit different format) > > > 2) exec without fork > > mkdir $HOME/bin > cat>> $HOME/bin/foo<< EOF > #!/bin/sh > > exec 2>/tmp/foo-execution.log > set -x > > exec /usr/bin/foo "$@" > EOF > chmod 755 $HOME/bin/foo > > PATH=$HOME/bin:$PATH execute_something_that_executes_foo > > A wrapper to a program, to get it's execution arguments; after executed > the pid of the executed program is the one parent originally executed... > in case exec is removed (executed program child of this shell script) one > can get 'segmentation fault' message (and such) from the shell in case of > that happens. > > > 3) fork& exec > > #!/usr/bin/perl > > ... > > sub xfork() > { > my $pid = fork(); > die "fork() failed: $!\n" unless defined $pid; > return $pid; > } > > ... > > if (@files) { > unless (xfork) > { > # child > chdir $tmp or die $!; > open STDOUT, '>', 'DEBIAN/md5sums' or die $!; > exec 'md5sum', @files; > exit 1; > } > wait; > } > > Ironically, this code is part of replacement dh_md5sums which was made > since the original dh_md5sums flaked on MSYS environment when the file > list grow too large. The replacement code is available here: > > http://meego.gitorious.org/meego-developer-tools/madde/blobs/master/src/debtools/dh_md5sums > > Note to self: that 'exit 1' there would be problematic if that 'exec' > ever returned (I guess it cannot); need something that just makes the > process vanish (without doing perl's cleanups on shared data structures). > > > and last, don't try this at work (or on shared student machine > (done that ;/ -- got a good lesson how 'social engineering' work)) > > perl -e 'fork while 1' > > >> P. > > Tomi > > and I don't do BASH so I have no idea of the significance of any of this. Can you explain in words why fork() is so great? P. |
From: Tor L. <tm...@ik...> - 2010-11-17 13:35:33
|
> Can you explain in words why fork() is so great? That has been done in this thread already. --tml |
From: Hehl, T. <Tho...@ac...> - 2010-11-17 13:34:18
|
Hey, guys, since this is OT and been going on for days, you think we can take this discussion off list, please? -----Original Message----- From: Peter Rockett [mailto:p.r...@sh...] Sent: Wednesday, November 17, 2010 8:29 AM To: MinGW Users List Subject: Re: [Mingw-users] fork(),waitpid() and setpid() On 17/11/10 08:44, Tomi Ollila wrote: > On Tue 16 Nov 2010 13:15, Peter Rockett<p.r...@sh...> writes: > >> One point that I have always wondered about: What was the original >> motivation of the UNIX creators in going for the fork() mechanism in the >> first place? Especially since it is invariably(?) followed by an exec*() >> call. (fork + exec* = spawn?) Does anybody know the history? > > I can give 3 examples why fork(2) (with or without or instead of) execve(2) > are one of the best inventions in computer science. > > > 1) fork(s) without exec > > #!/bin/sh > > ... > > case $# in 0) find . -name '*.src' ;; > *) for f; do echo $f; done ;; > esac | while read line; do basename "$line"; done > exit $? > > (2 forks (initially) there, for the pipeline. In use in a bit different format) > > > 2) exec without fork > > mkdir $HOME/bin > cat>> $HOME/bin/foo<< EOF > #!/bin/sh > > exec 2>/tmp/foo-execution.log > set -x > > exec /usr/bin/foo "$@" > EOF > chmod 755 $HOME/bin/foo > > PATH=$HOME/bin:$PATH execute_something_that_executes_foo > > A wrapper to a program, to get it's execution arguments; after executed > the pid of the executed program is the one parent originally executed... > in case exec is removed (executed program child of this shell script) one > can get 'segmentation fault' message (and such) from the shell in case of > that happens. > > > 3) fork& exec > > #!/usr/bin/perl > > ... > > sub xfork() > { > my $pid = fork(); > die "fork() failed: $!\n" unless defined $pid; > return $pid; > } > > ... > > if (@files) { > unless (xfork) > { > # child > chdir $tmp or die $!; > open STDOUT, '>', 'DEBIAN/md5sums' or die $!; > exec 'md5sum', @files; > exit 1; > } > wait; > } > > Ironically, this code is part of replacement dh_md5sums which was made > since the original dh_md5sums flaked on MSYS environment when the file > list grow too large. The replacement code is available here: > > http://meego.gitorious.org/meego-developer-tools/madde/blobs/master/src/ debtools/dh_md5sums > > Note to self: that 'exit 1' there would be problematic if that 'exec' > ever returned (I guess it cannot); need something that just makes the > process vanish (without doing perl's cleanups on shared data structures). > > > and last, don't try this at work (or on shared student machine > (done that ;/ -- got a good lesson how 'social engineering' work)) > > perl -e 'fork while 1' > > >> P. > > Tomi > > and I don't do BASH so I have no idea of the significance of any of this. Can you explain in words why fork() is so great? P. ------------------------------------------------------------------------ ------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ MinGW-users mailing list Min...@li... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Keith M. <kei...@us...> - 2010-11-17 15:00:49
|
On 17 November 2010 13:34, Hehl, Thomas <Tho...@ac...> wrote: > Hey, guys, since this is OT and been going on for days, you think we can > take this discussion off list, please? Who says it's off topic? It seems to be completely on topic to me, and I am one of the list moderators. I'm more likely to take you off the (subscription) list, for persistent top-posting, (but I'm not very likely to do that). -- Regards, Keith. |
From: Michael T. <my...@se...> - 2010-11-18 09:52:32
|
> Hey, guys, since this is OT and been going on for days, you think we can > take this discussion off list, please? Why? Since MinGW is used mostly for porting applications, this topic is perfectly non-OT. I think process creation is one of the major issues when porting an application. To understand how and why process creation is implemented on unix-like systems is the first step to properly port such program to different platforms. m. |
From: Keith M. <kei...@us...> - 2010-11-18 12:24:26
|
On 18 November 2010 09:52, Michael T. <myso77@...> wrote: >> Hey, guys, since this is OT and been going on for days, you think we can >> take this discussion off list, please? > > Why? Since MinGW is used mostly for porting applications, ... I don't know that this is strictly true. Porting is certainly one important use, but it doesn't necessarily predominate. > ... this topic is perfectly non-OT. I think so too. That is why I donned my moderator's hat, to take the OP to task over his (IMO inappropriate) request. > I think process creation is one of the major issues when porting an > application. To understand how and why process creation is implemented > on unix-like systems is the first step to properly port such program > to different platforms. Agreed. -- Regards, Keith. |
From: Tomi O. <tom...@ni...> - 2010-11-17 13:43:47
|
On Wed 17 Nov 2010 15:28, Peter Rockett <p.r...@sh...> writes: > I don't do BASH so I have no idea of the significance of any of this. > Can you explain in words why fork() is so great? I don't either; I try to make my scripts bourne shell compatible... or at least POSIX shell... ;) Anyway, I suggest everybody do sh/perl/python/<insert your favorite scripting language> work. But, let's think in words... fork() without exec() can be used to spawn multiple copies of the same process which then can provide services to requests without changing the state of the (parent) process launched... when work done the child process can just exit and system takes care of resource destruction. In my shell script example there were 2 subshells executed, with all the content that shell script has been created so far (functions, variables, etc.) where one subshell provided information to the another to do some work. exec() without fork() can be used (for example) in wrappers where some special work is done before the program that was intended to be run is executed. When that program gets run, it is the direct child of the original process starting the wrapper. fork(), following some settings in child process, which then exec()'s was used in my example first to change working directory to somewhere else, then redirecting the output of the command to a file. Now neither the parent nor the process exec()ed needed to do/know anything about these maneouvers, and therefore could be designed to be more generic. Tomi |
From: Peter R. <p.r...@sh...> - 2010-11-17 16:41:22
|
On 17/11/10 14:41, Keith Marshall wrote: > On 17 November 2010 13:43, Tomi Ollila<tom...@ni...> wrote: >> On Wed 17 Nov 2010 15:28, Peter Rockett<p.r...@sh...> writes: >> >>> I don't do BASH so I have no idea of the significance of any of this. >>> Can you explain in words why fork() is so great? >> ... >> >> fork() without exec() can be used to spawn multiple copies of the same >> process which then can provide services to requests without changing >> the state of the (parent) process launched... when work done the child >> process can just exit and system takes care of resource destruction. >> In my shell script example there were 2 subshells executed, with all the >> content that shell script has been created so far (functions, variables, >> etc.) where one subshell provided information to the another to do some >> work. > That's indisputably a useful capability, but unavailable on Windows, > (and hence MinGW), because Windows doesn't have a fork() compatible API. > >> exec() without fork() can be used (for example) in wrappers where some >> special work is done before the program that was intended to be run >> is executed. When that program gets run, it is the direct child of >> the original process starting the wrapper. > With POSIX semantics for exec(), yes, this is the case, but *not* with > Windows. When a Windows process calls exec(), the created process is > *completely* independent of the creator; it will run as a detached > process in its own right, while the creator will simply appear to have > terminated. Whatever process invoked the creator will resume as if the > creator had simply finished; it will never know that the exec()ed child > ever existed. > >> fork(), following some settings in child process, which then exec()'s >> was used in my example first to change working directory to somewhere >> else, then redirecting the output of the command to a file. Now neither >> the parent nor the process exec()ed needed to do/know anything about >> these maneouvers, and therefore could be designed to be more generic. > This is the scenario which Peter originally described as a "dog's > breakfast". What he is crucially overlooking is the "some settings in > the child, before exec()", which in his alternative have to be performed > in the parent, *before* the spawn() of the child; these settings damage > parent context, and it is the gymnastics which must be performed to > preserve that parent context which make > Peter's alternative the *real* Hang on a minute!! What alternative is that? All I did was to post a question asking about the original motivation behind fork() because it wasn't clear to me. I haven't proposed any alternative? Please do not ascribe opinions to me that I have not put forward. > "dog's breakfast" solution. When these settings are established in the > child, between the fork() and exec() calls, they do not interfere with > parent context, so there is no need for the gymnastics. > > And all of this has already been explained, previously in this thread! For what it's worth, it seems that Ken Thompson, one of the original UNIX guys from Bell, spent some time at Berkeley in the 1960s and borrowed the fork concept (and apparently other things) from the experimental SDS940 monitor program. Having looked at some documentation from this project (scanned, manual typewritten pages!) from 1966, it appears the fork() was simply a means of obtaining concurrent execution; intriguingly, forked SDS940 processes were able to share memory, something we now associate with only threads. (I think Tor hinted at the relationship with threads.) I am now suspecting that it's the exec*() family that is the add-on, not the fork() call. But I will try to track that down to my satisfaction. P. |
From: Keith M. <kei...@us...> - 2010-11-17 17:21:59
|
On 17 November 2010 16:41, Peter Rockett <p.r...@sh...> wrote: > Hang on a minute!! What alternative is that? The alternative of spawn() as a clean replacement for fork() + exec(), (which it isn't). Was it not you who suggested that? -- Regards, Keith. |
From: Peter R. <p.r...@sh...> - 2010-11-17 19:18:52
|
On 17/11/10 17:21, Keith Marshall wrote: > On 17 November 2010 16:41, Peter Rockett<p.r...@sh...> wrote: >> Hang on a minute!! What alternative is that? > The alternative of spawn() as a clean replacement for fork() + exec(), > (which it isn't). Was it not you who suggested that? > I don't believe so... but if I did, it was in the context of a question aimed at elucidating the difference, not proposing it as an alternative. P. |
From: Keith M. <kei...@us...> - 2010-11-17 21:39:59
|
On Wednesday 17 November 2010 19:18:43 Peter Rockett wrote: > > The alternative of spawn() as a clean replacement for fork() + > > exec(), (which it isn't). Was it not you who suggested that? > > I don't believe so... but if I did, it was in the context of a > question aimed at elucidating the difference, not proposing it as an > alternative. Your exact words: > What was the original > motivation of the UNIX creators in going for the fork() mechanism in > the first place? Especially since it is invariably(?) followed by an > exec*() call. (fork + exec* = spawn?) If that's not suggesting that spawn() is a suitable alternative to fork() + exec(), I don't know what it is. In a follow up, a short time later, you then qualified it further: > I have always wondered why such an elegantly-constructed > OS as UNIX uses what I regard as a dog's breakfast method of spawning > child processes... suggesting that you believe Microsoft's spawn() implementation is an elegant alternative to POSIX's fork() + exec() > unless I am missing some elegant feature of the fork() mechanism? I contend that you are; if you still think otherwise, then please show us your elegant use of spawn(), which will serve in place of: int my_pipe[2]; pid_t my_filter; if( pipe( my_pipe ) < 0 ) perror( "pipe" ); else { if( (my_filter = fork()) == 0 ) { /* In child... * Set up I/O context for filter program to read nominated * file as STDIN, writing STDOUT into my_pipe. */ int my_input = open( **argv, O_RDONLY ); dup2( my_input, STDIN_FILENO ); dup2( my_pipe[1], STDOUT_FILENO ); /* Leave reading from the pipe to the parent. */ close( my_pipe[0] ); /* Run the filter. */ execlp( "filter", "filter", NULL ); } else if( my_filter < 0 ) perror( "fork" ); else { int count; char buf[BUFSIZ]; /* Leave the child to write to the pipe, while we read it. */ close( my_pipe[1] ); while( (count = read( my_pipe[0], buf, BUFSIZ )) > 0 ) { ... } close( my_pipe[0] ); } } *without* trashing the STDIN and STDOUT file descriptors in the parent process. (Note: the foregoing is an off-the-cuff untested example; adding proper error checking, and robust handling of the read loop is left as an exercise for the reader). -- Regards, Keith. |
From: Peter R. <p.r...@sh...> - 2010-11-18 10:34:40
|
On 17/11/10 21:39, Keith Marshall wrote: > On Wednesday 17 November 2010 19:18:43 Peter Rockett wrote: >>> The alternative of spawn() as a clean replacement for fork() + >>> exec(), (which it isn't). Was it not you who suggested that? >> I don't believe so... but if I did, it was in the context of a >> question aimed at elucidating the difference, not proposing it as an >> alternative. > Your exact words: > >> What was the original >> motivation of the UNIX creators in going for the fork() mechanism in >> the first place? Especially since it is invariably(?) followed by an >> exec*() call. (fork + exec* = spawn?) > If that's not suggesting that spawn() is a suitable alternative to > fork() + exec(), I don't know what it is. In a follow up, a short time > later, you then qualified it further: > >> I have always wondered why such an elegantly-constructed >> OS as UNIX uses what I regard as a dog's breakfast method of spawning >> child processes... > suggesting that you believe Microsoft's spawn() implementation is an > elegant alternative to POSIX's fork() + exec() > >> unless I am missing some elegant feature of the fork() mechanism? > I contend that you are; if you still think otherwise, then please show > us your elegant use of spawn(), which will serve in place of: > > int my_pipe[2]; > pid_t my_filter; > > if( pipe( my_pipe )< 0 ) > perror( "pipe" ); > > else > { > if( (my_filter = fork()) == 0 ) > { > /* In child... > * Set up I/O context for filter program to read nominated > * file as STDIN, writing STDOUT into my_pipe. > */ > int my_input = open( **argv, O_RDONLY ); > dup2( my_input, STDIN_FILENO ); > dup2( my_pipe[1], STDOUT_FILENO ); > > /* Leave reading from the pipe to the parent. > */ > close( my_pipe[0] ); > > /* Run the filter. > */ > execlp( "filter", "filter", NULL ); > } > > else if( my_filter< 0 ) > perror( "fork" ); > > else > { > int count; > char buf[BUFSIZ]; > > /* Leave the child to write to the pipe, while we read it. > */ > close( my_pipe[1] ); > while( (count = read( my_pipe[0], buf, BUFSIZ ))> 0 ) > { > ... > } > close( my_pipe[0] ); > } > } > > *without* trashing the STDIN and STDOUT file descriptors in the parent > process. > > (Note: the foregoing is an off-the-cuff untested example; adding proper > error checking, and robust handling of the read loop is left as an > exercise for the reader). > Keith At the risk of descending to sarcasm, that funny little upside down hook with a dot at the bottom is what is called a question mark and implies the asking of a a question or uncertainty on the part of the writer. All the quotes from my earlier posts include these useful little devices of punctuation. That said, I now suspect that the fork() call was never originally intended as a means of launching a child process with a different image (a la spawn) but as a model of concurrent computation: a sort of early attempt at a thread. I further suspect that the exec*() functions are a convenient add-on and, rather than rewrite code that was already in fork(), the UNIX authors added exec*() to sit on top of fork(). So I conclude fork() was never designed as a means of launching a child process (as distinct from a clone of the parent process) but opportunistically used for that purpose. The enlightenment for me is that sometimes, it is desirable to do stuff between the fork() and the exec*() - I have never seen any examples of doing anything other than fork() immediately followed by exec*() in books, etc. Hence my question. So as a means of launching a (new image) child, fork() is a round-the-houses method. But clearly there are other benefits to fork(). Ultimately it's a judgement call, as with most engineering decisions. For my own interest, I will pursue the origins of exec*(). P. |
From: Tor L. <tm...@ik...> - 2010-11-18 10:50:19
|
> That said, I now suspect that the fork() call was never originally > intended as a means of launching a child process with a different image > (a la spawn) Well, consider that fork() is the *only* way to create a new process in Unix. And it has always been like that. That is *exactly* what makes it so elegant: The same simple API, with no parameters, no options, can be used for a different ultimate purposes depending on what else you do in the child process after the fork(). --tml |
From: Keith M. <kei...@us...> - 2010-11-18 12:57:02
|
On 18 November 2010 10:34, Peter Rockett <p.rockett@...> wrote: > > At the risk of descending to sarcasm, that funny little upside down hook > with a dot at the bottom is what is called a question mark and implies > the asking of a a question or uncertainty on the part of the writer. All > the quotes from my earlier posts include these useful little devices of > punctuation. Such devices of punctuation are also used by those playing Advocatus Diaboli. Not that there is anything fundamentally wrong with challenging any possibly suspect assertion, but when you persistently do so in a manner which suggests that you haven't bothered to even try to understand what it is you are challenging, you shouldn't be surprised to receive a response which may seem less respectful than you hoped. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-11-12 11:14:09
|
On 12 November 2010 10:07, M. Akila <ma...@be...> wrote: > I am not finding any header file in MinGW installation that has fork(), > waitpid() and setpid(). > > How do i include these functions As Tor has already pointed out, you don't; you port your code to use Windows APIs. This is asked so often, (in fact, Greg answered much the same question within the past day), it really ought to be a FAQ, but I don't see any appropriate reference at http://mingw.org/wiki/FAQ. In fact, it is on my low priority TODO list, to write a HOWTO on this subject. Personally, I would avoid the CreateProcess API Greg suggested -- it is way too ugly, complex and low level, as a good candidate for replacement of fork()/exec() when porting *nix code. IMO, the spawn() function API is much more suited to your needs -- it corresponds almost directly to the exec() function usage, (with a preceding vfork() implied), which you already have in your *nix code, although it does come with a significant gotcha -- Microsoft's implementation mishandles quoting of whitespace or embedded double quotes in arguments. Consider the wrappers from https://sourceforge.net/projects/mingw/files_beta/UserContributed/execwrap/ to get around that. -- Regards, Keith. |
From: M. A. <ma...@be...> - 2010-11-13 05:15:41
|
Sir, Thank you all for your inputs. i guess i would start with porting the code to use windows API. Regards M.Akila > On 12 November 2010 10:07, M. Akila <ma...@be...> wrote: >> I am not finding any header file in MinGW installation that has fork(), >> waitpid() and setpid(). >> >> How do i include these functions > > As Tor has already pointed out, you don't; you port your code to use > Windows APIs. > > This is asked so often, (in fact, Greg answered much the same question > within the past day), it really ought to be a FAQ, but I don't see any > appropriate reference at http://mingw.org/wiki/FAQ. In fact, it is on > my low priority TODO list, to write a HOWTO on this subject. > > Personally, I would avoid the CreateProcess API Greg suggested -- it is > way too ugly, complex and low level, as a good candidate for replacement > of fork()/exec() when porting *nix code. IMO, the spawn() function API > is much more suited to your needs -- it corresponds almost directly to > the exec() function usage, (with a preceding vfork() implied), which you > already have in your *nix code, although it does come with a significant > gotcha -- Microsoft's implementation mishandles quoting of whitespace or > embedded double quotes in arguments. Consider the wrappers from > https://sourceforge.net/projects/mingw/files_beta/UserContributed/execwrap/ > to get around that. > > -- > Regards, > Keith. > > ------------------------------------------------------------------------------ > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > client virtualization framework. Read more! > http://p.sf.net/sfu/dell-eql-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Member Research Staff Central Research Laboratory Bharat Electronics Ltd Jalahalli Bangalore - 560 013 Off Ph No: 080-28381125 Off Fax No: 28381168 Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Bharat Electronics or su...@be... immediately and destroy all copies of this message and any attachments. |
From: Keith M. <kei...@us...> - 2010-11-12 14:56:52
|
On 12 November 2010 14:07, Charles Wilson <cwi...@us...> wrote: > On 11/12/2010 6:26 AM, Keith Marshall wrote: >> On 12 November 2010 11:07, Peter Rockett <p.r...@pu...> wrote: >>> Or use Cygwin which does implement such stuff under Windows. >> >> If you develop it under Cygwin, then your program will become a Cygwin >> application, dependent on Cygwin DLLs for execution, and distribution >> will become subject to Cygwin licensing terms. > > This is also the case if you use the execwrap wrappers Keith mentioned > earlier. IIRC it also is GPL, just like cygwin. Yes, this is true of the current implementation. > However, you can still use the native windows spawn() functions > directly instead, without any licensing hassles: either ignore the > whitespace issues, or write your own wrapper to handle them. That's an immediately available option. FWIW, there is one code unit within the current implementation, which I wrote in collaboration with two other contributors to the (GNU) groff project; it is this one unit which forces the GPL licensing for the entire library. Besides this one unit, all the rest of the execwrap library is exclusively my own work. I've also recently rewritten the one GPL module from scratch, (without reference to the previous code). I think this later implementation is actually cleaner than the original; it is certainly noticeably different, and since it is now exclusively my own work, it would be legitimate for me to relicense it under a MIT style licence, and fold execwrap into libmingwex.a. If there is sufficient demand, I could be persuaded to put mingw-get on hold for a week or so, while I progress that. -- Regards, Keith. > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Tomi O. <tom...@ni...> - 2010-11-12 15:12:04
|
On Fri 12 Nov 2010 16:56, Keith Marshall <kei...@us...> writes: > That's an immediately available option. FWIW, there is one code unit > within the current implementation, which I wrote in collaboration with > two other contributors to the (GNU) groff project; it is this one unit > which forces the GPL licensing for the entire library. > > Besides this one unit, all the rest of the execwrap library is > exclusively my own work. I've also recently rewritten the one GPL > module from scratch, (without reference to the previous code). I think > this later implementation is actually cleaner than the original; it is > certainly noticeably different, and since it is now exclusively my own > work, it would be legitimate for me to relicense it under a MIT style > licence, and fold execwrap into libmingwex.a. If there is sufficient > demand, I could be persuaded to put mingw-get on hold for a week or so, > while I progress that. I could use the replacement code in here: http://meego.gitorious.org/meego-developer-tools/madde/blobs/master/src/toolwrapper/toolwrapper-win32.c > > -- > Regards, > Keith. Tomi |
From: Charles W. <cwi...@us...> - 2010-11-13 04:42:17
|
On 11/12/2010 9:56 AM, Keith Marshall wrote: > If there is sufficient > demand, I could be persuaded to put mingw-get on hold for a week or so, > while I progress that. Nah, I don't think it is a huge issue. mingw-get --remove is more important. :-) BTW, I didn't read email for a day or two, and by the time I saw your request to move stuff on the server, you'd already announced availability at the "bad" location. Do you still want me to move the new minget-get-inst to the "good" location? Obviously I need to fixup perms if possible regardless... -- Chuck |
From: Keith M. <kei...@us...> - 2010-11-13 20:24:17
|
On Saturday 13 November 2010 04:41:58 Charles Wilson wrote: > On 11/12/2010 9:56 AM, Keith Marshall wrote: > > If there is sufficient demand [for enhanced spawn/exec support in libmingwex.a], I could be persuaded to put mingw-get on hold for a week > > or so, while I progress that. > > Nah, I don't think it is a huge issue. Well, the code is mostly ready; I think I'll check it into CVS anyway, for safe keeping. All that's outstanding is to add appropriate support into process.h, and we'll likely need that anyway, when we get to the stage of adding post-install script support to mingw-get. > mingw-get --remove is more important. :-) Ack. I'll hold off on the process.h integration until I have that phase of mingw-get completed, together with `mingw-get list', for which I now have a preliminary implementation mostly working. (BTW, it will be `mingw-get remove', rather than `mingw-get --remove'; methinks that you have been spending too much time in RPM land) :-) > BTW, I didn't read email for a day or two, and by the time I saw your > request to move stuff on the server, you'd already announced > availability at the "bad" location. Do you still want me to move the > new minget-get-inst to the "good" location? I think it should be moved to the more logically natural location, perhaps with just a quick follow-up notification here, to advise users of the replacement URI. > Obviously I need to fixup perms if possible regardless... Yes please. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-11-14 20:26:34
|
On 11/13/2010 3:24 PM, Keith Marshall wrote: > On Saturday 13 November 2010 04:41:58 Charles Wilson wrote: >> BTW, I didn't read email for a day or two, and by the time I saw your >> request to move stuff on the server, you'd already announced >> availability at the "bad" location. Do you still want me to move the >> new minget-get-inst to the "good" location? > > I think it should be moved to the more logically natural location, > perhaps with just a quick follow-up notification here, to advise users > of the replacement URI. Done... >> Obviously I need to fixup perms if possible regardless... > > Yes please. ...and done. Will send a followup note in the correct thread shortly. -- Chuck |