{"thread":{"id":"3405","subject":"Should we support Perl 5.6?","startedAt":"2006-02-20T18:37:28Z","lastAt":"2006-03-02T22:01:13Z","messageCount":68,"participants":["Johannes Schindelin","Eric Wong","Andreas Ericsson","Junio C Hamano","Alex Riesen","Sam Vilain","Ron Parker","Shawn Pearce","Martin Langhoff","Linus Torvalds","Christopher Faylor","Rutger Nijlunsing","Mark Wooding"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"16459","messageId":"Pine.LNX.4.63.0602201934270.28957@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3405","inReplyTo":null,"subject":"Should we support Perl 5.6?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-20T18:37:28Z","receivedAt":"2006-02-20T18:37:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nI just had a failure when pulling, because since a few days (to be exact, \nsince commit 1cb30387, git-fmt-merge-msg uses a syntax which is not \nunderstood by Perl 5.6.\n\nIt is this:\n\n\topen $fh, '-|', 'git-symbolic-ref', 'HEAD' or die \"$!\";\n\nI know that there was already some discussion on this list, but I don't \nremember if we decided on leaving 5.6 behind or not.\n\nSomebody remembers?\n\nCiao,\nDscho\n"},{"id":"16470","messageId":"20060220191011.GA18085@hand.yhbt.net","threadId":"3405","inReplyTo":"Pine.LNX.4.63.0602201934270.28957@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Should we support Perl 5.6?","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-02-20T19:10:12Z","receivedAt":"2006-02-20T19:10:12Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> I just had a failure when pulling, because since a few days (to be exact, \n> since commit 1cb30387, git-fmt-merge-msg uses a syntax which is not \n> understood by Perl 5.6.\n> \n> It is this:\n> \n> \topen $fh, '-|', 'git-symbolic-ref', 'HEAD' or die \"$!\";\n\nThis is just 5.8 shorthand for the following (which is 5.6-compatible,\nand probably for earlier versions, too):\n\n\tmy $pid = open my $fh, '-|';\n\tdefined $pid or die \"Unable to fork: $!\\n\";\n\tif ($pid == 0) {\n\t\texec 'git-symbolic-ref', 'HEAD' or die \"$!\";\n\t}\n\t\n\nAll of the Perl code I've written uses this method.\n\n> I know that there was already some discussion on this list, but I don't \n> remember if we decided on leaving 5.6 behind or not.\n> \n> Somebody remembers?\n\nIIRC, there was no clear decision.\n\nI still have some Debian Woody machines/chroots with 5.6 around in some\nplaces. I don't use git on them, but I may someday, but upgrading to\nSarge is more likely on those.\n\n-- \nEric Wong\n"},{"id":"16472","messageId":"43FA2E46.2000503@op5.se","threadId":"3405","inReplyTo":"20060220191011.GA18085@hand.yhbt.net","subject":"Re: Should we support Perl 5.6?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-20T21:01:58Z","receivedAt":"2006-02-20T21:01:58Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Eric Wong wrote:\n> Johannes Schindelin wrote:\n> \n>>Hi,\n>>\n>>I just had a failure when pulling, because since a few days (to be exact, \n>>since commit 1cb30387, git-fmt-merge-msg uses a syntax which is not \n>>understood by Perl 5.6.\n>>\n>>It is this:\n>>\n>>\topen $fh, '-|', 'git-symbolic-ref', 'HEAD' or die \"$!\";\n> \n> \n> This is just 5.8 shorthand for the following (which is 5.6-compatible,\n> and probably for earlier versions, too):\n> \n> \tmy $pid = open my $fh, '-|';\n> \tdefined $pid or die \"Unable to fork: $!\\n\";\n> \tif ($pid == 0) {\n> \t\texec 'git-symbolic-ref', 'HEAD' or die \"$!\";\n> \t}\n> \t\n> \n> All of the Perl code I've written uses this method.\n> \n> \n>>I know that there was already some discussion on this list, but I don't \n>>remember if we decided on leaving 5.6 behind or not.\n>>\n>>Somebody remembers?\n> \n> \n> IIRC, there was no clear decision.\n> \n\nI think we agreed not to bother at all with Perl 5.4 and earlier, and \nnot to bend over backwards to support 5.6. This seems like a simple fix \nthough, so I'm sure Junio will accept a patch.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16473","messageId":"7v1wxxd95n.fsf@assigned-by-dhcp.cox.net","threadId":"3405","inReplyTo":"43FA2E46.2000503@op5.se","subject":"Re: Should we support Perl 5.6?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-20T21:15:16Z","receivedAt":"2006-02-20T21:15:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> I think we agreed not to bother at all with Perl 5.4 and earlier, and\n> not to bend over backwards to support 5.6. This seems like a simple\n> fix though, so I'm sure Junio will accept a patch.\n\nCorrect. I wasn't being careful enough.\n"},{"id":"16474","messageId":"7vr75xbs8w.fsf_-_@assigned-by-dhcp.cox.net","threadId":"3405","inReplyTo":"20060220191011.GA18085@hand.yhbt.net","subject":"[PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-20T22:05:51Z","receivedAt":"2006-02-20T22:05:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\nSigned-off-by: Junio C Hamano \n\n---\n\n * Eric, thanks for the hint. I have this four-patch series.\n Could people with perl 5.6 please check them?\n\n git-fmt-merge-msg.perl | 24 ++++++++++++++++--------\n 1 files changed, 16 insertions(+), 8 deletions(-)\n\n615782c9609bf23be55b403e994d88c1047be996\ndiff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl\nindex c34ddc5..a77e94e 100755\n--- a/git-fmt-merge-msg.perl\n+++ b/git-fmt-merge-msg.perl\n@@ -28,11 +28,12 @@ sub andjoin {\n }\n \n sub repoconfig {\n-\tmy $fh;\n \tmy $val;\n \teval {\n-\t\topen $fh, '-|', 'git-repo-config', '--get', 'merge.summary'\n-\t\t or die \"$!\";\n+\t\tmy $pid = open(my $fh, '-|');\n+\t\tif (!$pid) {\n+\t\t\texec('git-repo-config', '--get', 'merge.summary');\n+\t\t}\n \t\t($val) = <$fh>;\n \t\tclose $fh;\n \t};\n@@ -41,25 +42,32 @@ sub repoconfig {\n \n sub current_branch {\n \tmy $fh;\n-\topen $fh, '-|', 'git-symbolic-ref', 'HEAD' or die \"$!\";\n+\tmy $pid = open($fh, '-|');\n+\tdie \"$!\" unless defined $pid;\n+\tif (!$pid) {\n+\t exec('git-symbolic-ref', 'HEAD') or die \"$!\";\n+\t}\n \tmy ($bra) = <$fh>;\n \tchomp($bra);\n+\tclose $fh or die \"$!\";\n \t$bra =~ s|^refs/heads/||;\n \tif ($bra ne 'master') {\n \t\t$bra = \" into $bra\";\n \t} else {\n \t\t$bra = \"\";\n \t}\n-\n \treturn $bra;\n }\n \n sub shortlog {\n \tmy ($tip, $limit) = @_;\n \tmy ($fh, @result);\n-\topen $fh, '-|', ('git-log', \"--max-count=$limit\", '--topo-order',\n-\t\t\t '--pretty=oneline', $tip, '^HEAD')\n-\t or die \"$!\";\n+\tmy $pid = open($fh, '-|');\n+\tdie \"$!\" unless defined $pid;\n+\tif (!$pid) {\n+\t exec('git-log', \"--max-count=$limit\", '--topo-order',\n+\t\t '--pretty=oneline', $tip, '^HEAD') or die \"$!\";\n+\t}\n \twhile (<$fh>) {\n \t\ts/^[0-9a-f]{40}\\s+//;\n \t\tpush @result, $_;\n-- \n1.2.2.g5be4ea\n"},{"id":"16475","messageId":"7vpslhaddv.fsf@assigned-by-dhcp.cox.net","threadId":"3405","inReplyTo":"7vr75xbs8w.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] rerere: avoid open \"-|\" list form for Perl 5.6","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-20T22:12:12Z","receivedAt":"2006-02-20T22:12:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\nSigned-off-by: Junio C Hamano \n\n---\n\n git-rerere.perl | 6 +++++-\n 1 files changed, 5 insertions(+), 1 deletions(-)\n\n46fa107ab91b25eb928a9945ce4e9143b9c36df3\ndiff --git a/git-rerere.perl b/git-rerere.perl\nindex df11951..d3664ff 100755\n--- a/git-rerere.perl\n+++ b/git-rerere.perl\n@@ -131,7 +131,11 @@ sub record_preimage {\n sub find_conflict {\n \tmy $in;\n \tlocal $/ = \"\\0\";\n-\topen $in, '-|', qw(git ls-files -z -u) or die \"$!: ls-files\";\n+\tmy $pid = open($in, '-|');\n+\tdie \"$!\" unless defined $pid;\n+\tif (!$pid) {\n+\t\texec(qw(git ls-files -z -u)) or die \"$!: ls-files\";\n+\t}\n \tmy %path = ();\n \tmy @path = ();\n \twhile (<$in>) {\n-- \n1.2.2.g5be4ea\n"},{"id":"16477","messageId":"7vk6bpaddo.fsf@assigned-by-dhcp.cox.net","threadId":"3405","inReplyTo":"7vr75xbs8w.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] send-email: avoid open \"-|\" list form for Perl 5.6","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-20T22:12:19Z","receivedAt":"2006-02-20T22:12:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\nSigned-off-by: Junio C Hamano \n\n---\n\n git-send-email.perl | 39 ++++++++++++++++++++++-----------------\n 1 files changed, 22 insertions(+), 17 deletions(-)\n\n044ece3bc8bde227babd2f710f8216f2cb631034\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 13b85dd..b4f04f9 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -59,24 +59,29 @@ my $rc = GetOptions(\"from=s\" => \\$from,\n \n # Now, let's fill any that aren't set in with defaults:\n \n-open(GITVAR,\"-|\",\"git-var\",\"-l\")\n-\tor die \"Failed to open pipe from git-var: $!\";\n-\n-my ($author,$committer);\n-while() {\n-\tchomp;\n-\tmy ($var,$data) = split /=/,$_,2;\n-\tmy @fields = split /\\s+/, $data;\n-\n-\tmy $ident = join(\" \", @fields[0...(@fields-3)]);\n-\n-\tif ($var eq 'GIT_AUTHOR_IDENT') {\n-\t\t$author = $ident;\n-\t} elsif ($var eq 'GIT_COMMITTER_IDENT') {\n-\t\t$committer = $ident;\n-\t}\n+sub gitvar {\n+ my ($var) = @_;\n+ my $fh;\n+ my $pid = open($fh, '-|');\n+ die \"$!\" unless defined $pid;\n+ if (!$pid) {\n+\texec('git-var', $var) or die \"$!\";\n+ }\n+ my ($val) = <$fh>;\n+ close $fh or die \"$!\";\n+ chomp($val);\n+ return $val;\n+}\n+\n+sub gitvar_ident {\n+ my ($name) = @_;\n+ my $val = gitvar($name);\n+ my @field = split(/\\s+/, $val);\n+ return join(' ', @field[0...(@field-3)]);\n }\n-close(GITVAR);\n+\n+$author = gitvar_ident('GIT_AUTHOR_IDENT');\n+$committer = gitvar_ident('GIT_COMMITTER_IDENT');\n \n my $prompting = 0;\n if (!defined $from) {\n-- \n1.2.2.g5be4ea\n"},{"id":"16476","messageId":"7vek1xaddb.fsf@assigned-by-dhcp.cox.net","threadId":"3405","inReplyTo":"7vr75xbs8w.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] svmimport: avoid open \"-|\" list form for Perl 5.6","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-20T22:12:32Z","receivedAt":"2006-02-20T22:12:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\nSigned-off-by: Junio C Hamano \n\n---\n\n git-svnimport.perl | 20 ++++++++++++++++----\n 1 files changed, 16 insertions(+), 4 deletions(-)\n\nf7e8f8415c5c88082daecac44cfbba561113a3d9\ndiff --git a/git-svnimport.perl b/git-svnimport.perl\nindex c536d70..ee2940f 100755\n--- a/git-svnimport.perl\n+++ b/git-svnimport.perl\n@@ -10,7 +10,6 @@\n # The head revision is on branch \"origin\" by default.\n # You can change that with the '-o' option.\n \n-require 5.008; # for shell-safe open(\"-|\",LIST)\n use strict;\n use warnings;\n use Getopt::Std;\n@@ -322,8 +321,12 @@ sub get_file($$$) {\n \t\treturn undef unless defined $name;\n \t}\n \n-\topen my $F, '-|', \"git-hash-object\", \"-w\", $name\n+\tmy $pid = open(my $F, '-|');\n+\tdie $! unless defined $pid;\n+\tif (!$pid) {\n+\t exec(\"git-hash-object\", \"-w\", $name)\n \t\tor die \"Cannot create object: $!\\n\";\n+\t}\n \tmy $sha = <$F>;\n \tchomp $sha;\n \tclose $F;\n@@ -398,7 +401,12 @@ sub copy_path($$$$$$$$) {\n \t\t\t$srcpath =~ s#/*$#/#;\n \t}\n \t\n-\topen my $f,\"-|\",\"git-ls-tree\",\"-r\",\"-z\",$gitrev,$srcpath;\n+\tmy $pid = open my $f,'-|';\n+\tdie $! unless defined $pid;\n+\tif (!$pid) {\n+\t\texec(\"git-ls-tree\",\"-r\",\"-z\",$gitrev,$srcpath)\n+\t\t\tor die $!;\n+\t}\n \tlocal $/ = \"\\0\";\n \twhile(<$f>) {\n \t\tchomp;\n@@ -554,7 +562,11 @@ sub commit {\n \t\t\t\t@o1 = @old;\n \t\t\t\t@old = ();\n \t\t\t}\n-\t\t\topen my $F, \"-|\", \"git-ls-files\", \"-z\", @o1 or die $!;\n+\t\t\tmy $pid = open my $F, \"-|\";\n+\t\t\tdie \"$!\" unless defined $pid;\n+\t\t\tif (!$pid) {\n+\t\t\t\texec(\"git-ls-files\", \"-z\", @o1) or die $!;\n+\t\t\t}\n \t\t\t@o1 = ();\n \t\t\tlocal $/ = \"\\0\";\n \t\t\twhile(<$F>) {\n-- \n1.2.2.g5be4ea\n"},{"id":"16478","messageId":"7v8xs5ad24.fsf_-_@assigned-by-dhcp.cox.net","threadId":"3405","inReplyTo":"7vr75xbs8w.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] cvsimport: avoid open \"-|\" list form for Perl 5.6","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-20T22:19:15Z","receivedAt":"2006-02-20T22:19:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\nSigned-off-by: Junio C Hamano \n\n---\n\n * Fifth of the four patch series. I cannot count ;-).\n\n git-cvsimport.perl | 6 +++++-\n 1 files changed, 5 insertions(+), 1 deletions(-)\n\neb815c1bb8a40ae18d80e99f8547137ea05318bf\ndiff --git a/git-cvsimport.perl b/git-cvsimport.perl\nindex 24f9834..b46469a 100755\n--- a/git-cvsimport.perl\n+++ b/git-cvsimport.perl\n@@ -846,8 +846,12 @@ while() {\n \t\t\tprint \"Drop $fn\\n\" if $opt_v;\n \t\t} else {\n \t\t\tprint \"\".($init ? \"New\" : \"Update\").\" $fn: $size bytes\\n\" if $opt_v;\n-\t\t\topen my $F, '-|', \"git-hash-object -w $tmpname\"\n+\t\t\tmy $pid = open(my $F, '-|');\n+\t\t\tdie $! unless defined $pid;\n+\t\t\tif (!$pid) {\n+\t\t\t exec(\"git-hash-object\", \"-w\", $tmpname)\n \t\t\t\tor die \"Cannot create object: $!\\n\";\n+\t\t\t}\n \t\t\tmy $sha = <$F>;\n \t\t\tchomp $sha;\n \t\t\tclose $F;\n-- \n1.2.2.g5be4ea\n"},{"id":"16506","messageId":"81b0412b0602210930w5c1a71aage12bad2079dd515a@mail.gmail.com","threadId":"3405","inReplyTo":"7vr75xbs8w.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-21T17:30:08Z","receivedAt":"2006-02-21T17:30:08Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/20/06, Junio C Hamano wrote:\n> * Eric, thanks for the hint. I have this four-patch series.\n> Could people with perl 5.6 please check them?\n\nDoes not work here (ActiveState Build 811, Perl 5.8.6):\n\n$ perl -e 'open(F, \"-|\")'\n'-' is not recognized as an internal or external command,\noperable program or batch file.\n"},{"id":"16519","messageId":"43FB79E2.1040307@vilain.net","threadId":"3405","inReplyTo":"81b0412b0602210930w5c1a71aage12bad2079dd515a@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-21T20:36:50Z","receivedAt":"2006-02-21T20:36:50Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Alex Riesen wrote:\n> On 2/20/06, Junio C Hamano wrote:\n> \n>> * Eric, thanks for the hint. I have this four-patch series.\n>> Could people with perl 5.6 please check them?\n> \n> \n> Does not work here (ActiveState Build 811, Perl 5.8.6):\n> \n> $ perl -e 'open(F, \"-|\")'\n> '-' is not recognized as an internal or external command,\n> operable program or batch file.\n\nPortability, Ease of Coding, Few CPAN Module Dependencies. Pick any two.\n\nSam.\n"},{"id":"16522","messageId":"20060221205618.GA23920@localdomain","threadId":"3405","inReplyTo":"81b0412b0602210930w5c1a71aage12bad2079dd515a@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-02-21T20:56:18Z","receivedAt":"2006-02-21T20:56:18Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Alex Riesen wrote:\n> On 2/20/06, Junio C Hamano wrote:\n> > * Eric, thanks for the hint. I have this four-patch series.\n> > Could people with perl 5.6 please check them?\n> \n> Does not work here (ActiveState Build 811, Perl 5.8.6):\n> \n> $ perl -e 'open(F, \"-|\")'\n> '-' is not recognized as an internal or external command,\n> operable program or batch file.\n\nBoth \"-|\" and \"|-\" forms of open() use fork() internally. Iirc, fork()\ndoesn't work too well on that platform.\n\n-- \nEric Wong\n"},{"id":"16527","messageId":"20060221215742.GA5948@steel.home","threadId":"3405","inReplyTo":"43FB79E2.1040307@vilain.net","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-21T21:57:42Z","receivedAt":"2006-02-21T21:57:42Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Sam Vilain, Tue, Feb 21, 2006 21:36:50 +0100:\n> >\n> >>* Eric, thanks for the hint. I have this four-patch series.\n> >> Could people with perl 5.6 please check them?\n> >\n> >\n> >Does not work here (ActiveState Build 811, Perl 5.8.6):\n> >\n> >$ perl -e 'open(F, \"-|\")'\n> >'-' is not recognized as an internal or external command,\n> >operable program or batch file.\n> \n> Portability, Ease of Coding, Few CPAN Module Dependencies. Pick any two.\n> \n\nSometimes an upgrade is just out of question. Besides, that'd mean an\nupgrade to another operating system, because very important scripts\nover here a just not portable to anything else but\n \"ActiveState Perl on Windows (TM)\"\nI just have no choice.\n"},{"id":"16528","messageId":"20060221220454.GB5948@steel.home","threadId":"3405","inReplyTo":"20060221205618.GA23920@localdomain","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-21T22:04:54Z","receivedAt":"2006-02-21T22:04:54Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Eric Wong, Tue, Feb 21, 2006 21:56:18 +0100:\n> > > * Eric, thanks for the hint. I have this four-patch series.\n> > > Could people with perl 5.6 please check them?\n> > \n> > Does not work here (ActiveState Build 811, Perl 5.8.6):\n> > \n> > $ perl -e 'open(F, \"-|\")'\n> > '-' is not recognized as an internal or external command,\n> > operable program or batch file.\n> \n> Both \"-|\" and \"|-\" forms of open() use fork() internally. Iirc, fork()\n> doesn't work too well on that platform.\n> \n\nAFAICS, it does not exist. There is emulation of it in that active-perl,\nthough so this works:\n\n if ( !fork ) { something }\n\nbut not \"too well\" (you have to be carefule not spawn too many (which\nis around 50) processes. Perl'll crash otherwise).\n"},{"id":"16531","messageId":"1cf1c57a0602211413n22e77fd0l4e2846e7feb5429e@mail.gmail.com","threadId":"3405","inReplyTo":"1cf1c57a0602211412r1988b14ao435edd29207dc0d0@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Ron Parker","fromEmail":"rdparker@gmail.com","sentAt":"2006-02-21T22:13:12Z","receivedAt":"2006-02-21T22:13:12Z","isPatch":true,"sender":{"key":"rdparker@gmail.com","avatar":"https://gravatar.com/avatar/76a05f80dce0dda79f160ace37597a89ea7932279d593b55c2d2bcb4ae62bca6?d=mp&s=160"},"body":"On 2/21/06, Alex Riesen wrote:\n\n> AFAICS, it does not exist. There is emulation of it in that active-perl,\n> though so this works:\n>\n> if ( !fork ) { something }\n>\n> but not \"too well\" (you have to be carefule not spawn too many (which\n> is around 50) processes. Perl'll crash otherwise).\n\nIIRC this has to do with some child-process thread limits in Windows.\n\n--\nWindows, the multi-thrashing OS.\n"},{"id":"16535","messageId":"Pine.LNX.4.63.0602212315400.12634@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3405","inReplyTo":"20060221215742.GA5948@steel.home","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-21T22:19:25Z","receivedAt":"2006-02-21T22:19:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 21 Feb 2006, Alex Riesen wrote:\n\n> Sam Vilain, Tue, Feb 21, 2006 21:36:50 +0100:\n> > >\n> > >>* Eric, thanks for the hint. I have this four-patch series.\n> > >> Could people with perl 5.6 please check them?\n> > >\n> > >\n> > >Does not work here (ActiveState Build 811, Perl 5.8.6):\n> > >\n> > >$ perl -e 'open(F, \"-|\")'\n> > >'-' is not recognized as an internal or external command,\n> > >operable program or batch file.\n> > \n> > Portability, Ease of Coding, Few CPAN Module Dependencies. Pick any two.\n> > \n> \n> Sometimes an upgrade is just out of question. Besides, that'd mean an\n> upgrade to another operating system, because very important scripts\n> over here a just not portable to anything else but\n> \"ActiveState Perl on Windows (TM)\"\n> I just have no choice.\n\nMaybe I am stating the obvious, but it seems that\n\n\topen (F, \"git-blabla -option |\");\n\nwould be more portable.\n\nAlex, would this work on ActiveState?\n\nPerl gurus, is the latter way to open a pipe considered awful or what?\n\nCiao,\nDscho\n\nP.S.: Eric, we rely on fork() anyway. Most of git's programs just don't \nwork without a fork().\n"},{"id":"16538","messageId":"20060221223535.GC18085@hand.yhbt.net","threadId":"3405","inReplyTo":"Pine.LNX.4.63.0602212315400.12634@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-02-21T22:35:35Z","receivedAt":"2006-02-21T22:35:35Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 21 Feb 2006, Alex Riesen wrote:\n> \n> > Sam Vilain, Tue, Feb 21, 2006 21:36:50 +0100:\n> > > >\n> > > >>* Eric, thanks for the hint. I have this four-patch series.\n> > > >> Could people with perl 5.6 please check them?\n> > > >\n> > > >\n> > > >Does not work here (ActiveState Build 811, Perl 5.8.6):\n> > > >\n> > > >$ perl -e 'open(F, \"-|\")'\n> > > >'-' is not recognized as an internal or external command,\n> > > >operable program or batch file.\n> > > \n> > > Portability, Ease of Coding, Few CPAN Module Dependencies. Pick any two.\n> > > \n> > \n> > Sometimes an upgrade is just out of question. Besides, that'd mean an\n> > upgrade to another operating system, because very important scripts\n> > over here a just not portable to anything else but\n> > \"ActiveState Perl on Windows (TM)\"\n> > I just have no choice.\n> \n> Maybe I am stating the obvious, but it seems that\n> \n> \topen (F, \"git-blabla -option |\");\n> \n> would be more portable.\n> \n> Alex, would this work on ActiveState?\n> \n> Perl gurus, is the latter way to open a pipe considered awful or what?\n\nIt's OK as long as all arguments are are shell-safe (quoted/escaped\nproperly). Shouldn't be a problem with constant strings at all.\n\n> P.S.: Eric, we rely on fork() anyway. Most of git's programs just don't \n> work without a fork().\n\nYes, apparently there's some fork() emulation in some *doze places and\nnot others.\n\n-- \nEric Wong\n"},{"id":"16540","messageId":"20060221223808.GC20744@spearce.org","threadId":"3405","inReplyTo":"Pine.LNX.4.63.0602212315400.12634@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-21T22:38:08Z","receivedAt":"2006-02-21T22:38:08Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> Maybe I am stating the obvious, but it seems that\n> \n> \topen (F, \"git-blabla -option |\");\n> \n> would be more portable.\n\nYes but that gets broken up and processed according to your shell.\nWhich could be ugly if you try to include shell meta-characters.\nOn the other hand if the entire string passed to open is a constant\nin the script then there's really no danger and it would be more\nportable.\n \n> P.S.: Eric, we rely on fork() anyway. Most of git's programs just don't \n> work without a fork().\n\nWhich is why GIT requires Cygwin on Windows. So why not use\nthe Cygwin perl when using GIT? I think that uses Cygwin's fork\nemulation to implement fork, rather than the ActiveState emulation\nof fork.\n\nOf course fork on Cygwin is painfully slow. :-|\n\n-- \nShawn.\n"},{"id":"16541","messageId":"43FB9656.8050308@vilain.net","threadId":"3405","inReplyTo":"20060221215742.GA5948@steel.home","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-21T22:38:14Z","receivedAt":"2006-02-21T22:38:14Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Alex Riesen wrote:\n>>>Does not work here (ActiveState Build 811, Perl 5.8.6):\n>>>$ perl -e 'open(F, \"-|\")'\n>>>'-' is not recognized as an internal or external command,\n>>>operable program or batch file.\n>>Portability, Ease of Coding, Few CPAN Module Dependencies. Pick any two.\n> Sometimes an upgrade is just out of question. Besides, that'd mean an\n> upgrade to another operating system, because very important scripts\n> over here a just not portable to anything else but\n> \"ActiveState Perl on Windows (TM)\"\n> I just have no choice.\n\nSure, but perhaps IPC::Open2 or some other CPAN module has solved this \nproblem already.\n\nI guess what I'm saying is that if you want to limit the modules that \nPerl script uses, you end up either impacting on the portability of the \nscript or rediscovering problems with early wheel designs.\n\nSam.\n"},{"id":"16544","messageId":"46a038f90602211500m287d82far5fd41270400652a9@mail.gmail.com","threadId":"3405","inReplyTo":"Pine.LNX.4.63.0602212315400.12634@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-02-21T23:00:37Z","receivedAt":"2006-02-21T23:00:37Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 2/22/06, Johannes Schindelin wrote:\n> Maybe I am stating the obvious, but it seems that\n>\n> open (F, \"git-blabla -option |\");\n>\n> would be more portable.\n\n\nAnd\n\n open (F, \"git-blabla|\", '-option', '$%!|');\n\nwould be portable AND safe ;-)\n\ncheers,\n\n\nmartin\n"},{"id":"16573","messageId":"81b0412b0602220835p4c4243edm145ee827eb706121@mail.gmail.com","threadId":"3405","inReplyTo":"43FB9656.8050308@vilain.net","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-22T16:35:46Z","receivedAt":"2006-02-22T16:35:46Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/21/06, Sam Vilain wrote:\n> Alex Riesen wrote:\n> >>>Does not work here (ActiveState Build 811, Perl 5.8.6):\n> >>>$ perl -e 'open(F, \"-|\")'\n> >>>'-' is not recognized as an internal or external command,\n> >>>operable program or batch file.\n> >>Portability, Ease of Coding, Few CPAN Module Dependencies. Pick any two.\n> > Sometimes an upgrade is just out of question. Besides, that'd mean an\n> > upgrade to another operating system, because very important scripts\n> > over here a just not portable to anything else but\n> > \"ActiveState Perl on Windows (TM)\"\n> > I just have no choice.\n>\n> Sure, but perhaps IPC::Open2 or some other CPAN module has solved this\n> problem already.\n\nIPC::Open2 works! Well \"kind of\": there are still strange segfaults regarding\nstack sometimes. And I don't know yet whether and how the arguments are escaped\n(Windows has no argument array. It has that bloody stupid one-line command line)\n\n> I guess what I'm saying is that if you want to limit the modules that\n> Perl script uses, you end up either impacting on the portability of the\n> script or rediscovering problems with early wheel designs.\n\nIPC::Open{2,3} seem to be installed on every system I have access to.\n"},{"id":"16582","messageId":"Pine.LNX.4.63.0602221914590.4362@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3405","inReplyTo":"81b0412b0602220835p4c4243edm145ee827eb706121@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-22T19:44:49Z","receivedAt":"2006-02-22T19:44:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 22 Feb 2006, Alex Riesen wrote:\n\n> IPC::Open{2,3} seem to be installed on every system I have access to.\n\nI can confirm that the platforms I usually work on also provide it \n(Linux, Linux, old IRIX, old macosx, MinGW32).\n\nCiao,\nDscho\n"},{"id":"16583","messageId":"43FCC0D0.5050307@vilain.net","threadId":"3405","inReplyTo":"81b0412b0602220835p4c4243edm145ee827eb706121@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-22T19:51:44Z","receivedAt":"2006-02-22T19:51:44Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Alex Riesen wrote:\n>>I guess what I'm saying is that if you want to limit the modules that\n>>Perl script uses, you end up either impacting on the portability of the\n>>script or rediscovering problems with early wheel designs.\n> IPC::Open{2,3} seem to be installed on every system I have access to.\n\nChecking in Module::CoreList, that module goes right back to the Perl \n5.0 release, so every normal Perl 5 distribution should have it.\n\nSam.\n"},{"id":"16584","messageId":"7vmzgjmaog.fsf@assigned-by-dhcp.cox.net","threadId":"3405","inReplyTo":"43FCC0D0.5050307@vilain.net","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-22T19:54:23Z","receivedAt":"2006-02-22T19:54:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Vilain writes:\n\n> Checking in Module::CoreList, that module goes right back to the Perl\n> 5.0 release, so every normal Perl 5 distribution should have it.\n\nGood digging, but IIRC this thread started because something\nthat _claims_ to be 5.8 does not grok open(F, '-|') correctly,\nso...\n"},{"id":"16588","messageId":"Pine.LNX.4.63.0602222259480.6682@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3405","inReplyTo":"81b0412b0602220835p4c4243edm145ee827eb706121@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-22T22:00:45Z","receivedAt":"2006-02-22T22:00:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 22 Feb 2006, Alex Riesen wrote:\n\n> IPC::Open2 works!\n\nNote that there is a notable decrease in performance in my preliminary \ntests (about 10%).\n\nCiao,\nDscho\n"},{"id":"16589","messageId":"7v4q2rm3of.fsf@assigned-by-dhcp.cox.net","threadId":"3405","inReplyTo":"Pine.LNX.4.63.0602222259480.6682@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-22T22:25:36Z","receivedAt":"2006-02-22T22:25:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Wed, 22 Feb 2006, Alex Riesen wrote:\n>\n>> IPC::Open2 works!\n>\n> Note that there is a notable decrease in performance in my preliminary \n> tests (about 10%).\n\nDoesn't open(F, \"| foo bar\") or open(F, \"foo bar |\") with\ncareful shell quoting work?\n"},{"id":"16603","messageId":"81b0412b0602230000t58a88af6na1aa7e323dc0179d@mail.gmail.com","threadId":"3405","inReplyTo":"Pine.LNX.4.63.0602222259480.6682@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-23T08:00:24Z","receivedAt":"2006-02-23T08:00:24Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/22/06, Johannes Schindelin wrote:\n> > IPC::Open2 works!\n>\n> Note that there is a notable decrease in performance in my preliminary\n> tests (about 10%).\n\nI'll keep that in mind. But there are places where a safe pipe is unavoidable\n(filenames. No amount of careful quoting will save you).\n"},{"id":"16604","messageId":"7vwtfmihts.fsf@assigned-by-dhcp.cox.net","threadId":"3405","inReplyTo":"81b0412b0602230000t58a88af6na1aa7e323dc0179d@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-23T08:45:51Z","receivedAt":"2006-02-23T08:45:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" writes:\n\n> I'll keep that in mind. But there are places where a safe pipe is unavoidable\n> (filenames. No amount of careful quoting will save you).\n\nHuh?\n"},{"id":"16605","messageId":"81b0412b0602230135w472aa6f3v72980f6f63bb355f@mail.gmail.com","threadId":"3405","inReplyTo":"7vwtfmihts.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-23T09:35:16Z","receivedAt":"2006-02-23T09:35:16Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/23/06, Junio C Hamano wrote:\n> \"Alex Riesen\" writes:\n>\n> > I'll keep that in mind. But there are places where a safe pipe is unavoidable\n> > (filenames. No amount of careful quoting will save you).\n>\n> Huh?\n>\n\nBecause you never know what did the next interpreter took for unquoting:\n$SHELL, /bin/sh cmd /c, or something else.\n"},{"id":"16606","messageId":"81b0412b0602230141g46dbfaev6baa5083dee2d42@mail.gmail.com","threadId":"3405","inReplyTo":"81b0412b0602230135w472aa6f3v72980f6f63bb355f@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-23T09:41:23Z","receivedAt":"2006-02-23T09:41:23Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/23/06, Alex Riesen wrote:\n> On 2/23/06, Junio C Hamano wrote:\n> > \"Alex Riesen\" writes:\n> >\n> > > I'll keep that in mind. But there are places where a safe pipe is unavoidable\n> > > (filenames. No amount of careful quoting will save you).\n> >\n> > Huh?\n>\n> Because you never know what did the next interpreter took for unquoting:\n> $SHELL, /bin/sh cmd /c, or something else.\n>\nAnd that stupid activestate thing actually doesn't use any. Just tried:\n\n perl -e '$,=\" \";open(F, \"sleep 1000 ; # @ARGV |\") and print '\n\nIt passed the whole string \"1000 ; # @ARGV\" to sleep from $PATH.\nIt failed to sleep at all, of course. The same code works perfectly on\nalmost any UNIX system.\n"},{"id":"16607","messageId":"43FD84EB.3040704@op5.se","threadId":"3405","inReplyTo":"81b0412b0602230141g46dbfaev6baa5083dee2d42@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-23T09:48:27Z","receivedAt":"2006-02-23T09:48:27Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Alex Riesen wrote:\n> On 2/23/06, Alex Riesen wrote:\n> \n>>On 2/23/06, Junio C Hamano wrote:\n>>\n>>>\"Alex Riesen\" writes:\n>>>\n>>>\n>>>>I'll keep that in mind. But there are places where a safe pipe is unavoidable\n>>>>(filenames. No amount of careful quoting will save you).\n>>>\n>>>Huh?\n>>\n>>Because you never know what did the next interpreter took for unquoting:\n>>$SHELL, /bin/sh cmd /c, or something else.\n>>\n> \n> And that stupid activestate thing actually doesn't use any. Just tried:\n> \n> perl -e '$,=\" \";open(F, \"sleep 1000 ; # @ARGV |\") and print '\n> \n> It passed the whole string \"1000 ; # @ARGV\" to sleep from $PATH.\n> It failed to sleep at all, of course. The same code works perfectly on\n> almost any UNIX system.\n\n\nNot to be unhelpful or anything, but activestate perl seems to be quite \na lot of bother. Is it worth supporting it?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16608","messageId":"81b0412b0602230210r3ffe6e2dta5dc86d6516692b9@mail.gmail.com","threadId":"3405","inReplyTo":"43FD84EB.3040704@op5.se","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-23T10:10:23Z","receivedAt":"2006-02-23T10:10:23Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/23/06, Andreas Ericsson wrote:\n> Not to be unhelpful or anything, but activestate perl seems to be quite\n> a lot of bother. Is it worth supporting it?\n\nIt's not activestate perl actually. It's only one platform it also\n_has_ to support.\nIs it worth supporting Windows?\n"},{"id":"16615","messageId":"43FDB8CC.5000503@op5.se","threadId":"3405","inReplyTo":"81b0412b0602230210r3ffe6e2dta5dc86d6516692b9@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-23T13:29:48Z","receivedAt":"2006-02-23T13:29:48Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Alex Riesen wrote:\n> On 2/23/06, Andreas Ericsson wrote:\n> \n>>Not to be unhelpful or anything, but activestate perl seems to be quite\n>>a lot of bother. Is it worth supporting it?\n> \n> \n> It's not activestate perl actually. It's only one platform it also\n> _has_ to support.\n> Is it worth supporting Windows?\n\n\nWith or without cygwin? With cygwin, I'd say \"yes, unless it makes \nthings terribly difficult to maintain and so long as we don't take \nperformance hits on unices\". Without cygwin, I'd say \"What? It runs on \nwindows?\".\n\nIf we claim to support windows but do a poor job of it, no-one else will \nstart working on a windows-port. If we don't claim to support windows \nbut say that \"it's known to work with cygwin, although be aware of these \nperformance penalties...\", eventually someone will come along with their \nshiny Visual Express and hack up support for it, even if some tools will \nbe missing and others unnecessarily complicated.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16617","messageId":"81b0412b0602230607n22146a77k36929f0ad9e44d53@mail.gmail.com","threadId":"3405","inReplyTo":"43FDB8CC.5000503@op5.se","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-23T14:07:07Z","receivedAt":"2006-02-23T14:07:07Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/23/06, Andreas Ericsson wrote:\n> >\n> >>Not to be unhelpful or anything, but activestate perl seems to be quite\n> >>a lot of bother. Is it worth supporting it?\n> >\n> >\n> > It's not activestate perl actually. It's only one platform it also\n> > _has_ to support.\n> > Is it worth supporting Windows?\n>\n> With or without cygwin? With cygwin, I'd say \"yes, unless it makes\n> things terribly difficult to maintain and so long as we don't take\n> performance hits on unices\". Without cygwin, I'd say \"What? It runs on\n> windows?\".\n\nThere not much difference with or without cygwin. The penalties of\ndoing any kind of support for it will pile up (as they started to do\nwith pipes).\nSomeday we'll have to start dropping features on Windows or restrict them\nbeyond their usefullness. The fork emulation in cygwin isn't perfect,\nsignals do not work reliably (if at all), filesystem is slow and locked down,\nand exec-attribute is NOT really useful even on NTFS (it is somehow related\nto execute permission and open files. I still cannot figure out how exactly\nare they related).\n\n> If we claim to support windows but do a poor job of it, no-one else will\n> start working on a windows-port. If we don't claim to support windows\n> but say that \"it's known to work with cygwin, although be aware of these\n> performance penalties...\", eventually someone will come along with their\n> shiny Visual Express and hack up support for it, even if some tools will\n> be missing and others unnecessarily complicated.\n\nThat seem to be the case, except for shiny.\n(I really don't know what could possibly mean by that. It stinks, smears,\nand sometimes bounces. Never saw it shining).\n"},{"id":"16618","messageId":"43FDC533.3070905@op5.se","threadId":"3405","inReplyTo":"81b0412b0602230607n22146a77k36929f0ad9e44d53@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-23T14:22:43Z","receivedAt":"2006-02-23T14:22:43Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Alex Riesen wrote:\n> On 2/23/06, Andreas Ericsson wrote:\n> \n>>If we claim to support windows but do a poor job of it, no-one else will\n>>start working on a windows-port. If we don't claim to support windows\n>>but say that \"it's known to work with cygwin, although be aware of these\n>>performance penalties...\", eventually someone will come along with their\n>>shiny Visual Express and hack up support for it, even if some tools will\n>>be missing and others unnecessarily complicated.\n> \n> \n> That seem to be the case, except for shiny.\n> (I really don't know what could possibly mean by that. It stinks, smears,\n> and sometimes bounces. Never saw it shining).\n> \n\nThe logo has a little glint thing on it, like those things that go \n'ting' on a front tooth in commercials for toothpaste and particularly \nhealthy chewing gum.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16624","messageId":"Pine.LNX.4.64.0602230911410.3771@g5.osdl.org","threadId":"3405","inReplyTo":"81b0412b0602230607n22146a77k36929f0ad9e44d53@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-23T17:13:43Z","receivedAt":"2006-02-23T17:13:43Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Feb 2006, Alex Riesen wrote:\n>\n> Someday we'll have to start dropping features on Windows or restrict them\n> beyond their usefullness.\n\nOne thing that would help a bit would be to avoid shell.\n\nThere are many portable interpreters out there, and I don't mean perl. And \nwriting a small \"specialized for git\" one isn't even that hard. In fact, \nmost of the shell (and bash) hackery we do now would be unnecessary if we \njust made a small \"git interpreter\" that ran \"git scripts\".\n\nThe fact that it would also help portability is just an added advantage.\n\n\t\tLinus\n"},{"id":"16628","messageId":"7virr5hnw4.fsf@assigned-by-dhcp.cox.net","threadId":"3405","inReplyTo":"Pine.LNX.4.64.0602230911410.3771@g5.osdl.org","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-23T19:32:27Z","receivedAt":"2006-02-23T19:32:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> There are many portable interpreters out there, and I don't mean perl. And \n> writing a small \"specialized for git\" one isn't even that hard. In fact, \n> most of the shell (and bash) hackery we do now would be unnecessary if we \n> just made a small \"git interpreter\" that ran \"git scripts\".\n\nBefore anybody mentions tcl ;-).\n\nI agree with the above in principle, but I am afraid that is\nonly half of the solution to the problem Alex is having.\n\nIn the longer term, libified git with script language bindings\nwould make the way git things work together a lot better. I've\nalways wanted to make merge-base a subroutine callable from\nother things, so that I can say \"git diff A...B\" to mean \"diff\nup to B since B forked from A\" ;-).\n\nThat way, we would eliminate the current common pattern of\npiping rev-list output to diff-tree, or ls-files/diff-files\noutput to update-index --stdin. These components live in the\nsingle process, a calling \"git script\", and will talk with each\nother internally.\n\nBut we do need to talk to non-git things. git-grep needs a way\nfor ls-files to drive xargs/grep, for example. diff --cc reads\nfrom GNU diff output. And for these external tools, the way\nthey expect the input to be fed to them or their output is taken\nout is via UNIXy pipe.\n\nAnd the breakage Alex wants to work around is that the platform\nis not friendly to pipes, if you deny Cygwin. So I suspect\navoiding shell would not help much.\n"},{"id":"16629","messageId":"Pine.LNX.4.63.0602232037260.30630@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3405","inReplyTo":"7virr5hnw4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-23T19:38:46Z","receivedAt":"2006-02-23T19:38:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 23 Feb 2006, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > There are many portable interpreters out there, and I don't mean perl. And \n> > writing a small \"specialized for git\" one isn't even that hard. In fact, \n> > most of the shell (and bash) hackery we do now would be unnecessary if we \n> > just made a small \"git interpreter\" that ran \"git scripts\".\n> \n> Before anybody mentions tcl ;-).\n\nDarn, I had my suggestion sent out: Java ;-)\n\nCiao,\nDscho\n"},{"id":"16631","messageId":"Pine.LNX.4.64.0602231143290.3771@g5.osdl.org","threadId":"3405","inReplyTo":"7virr5hnw4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-23T19:51:43Z","receivedAt":"2006-02-23T19:51:43Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Feb 2006, Junio C Hamano wrote:\n>\n> Linus Torvalds writes: \n> > There are many portable interpreters out there, and I don't mean perl. And \n> > writing a small \"specialized for git\" one isn't even that hard. In fact, \n> > most of the shell (and bash) hackery we do now would be unnecessary if we \n> > just made a small \"git interpreter\" that ran \"git scripts\".\n> \n> Before anybody mentions tcl ;-).\n\nWell, I was thinking more of the \"embeddable\" ones - things that are so \nsmall that they can be compiled with the project. Things like Lua.\n\nNow, Lua is not really very useful for this use case: our scripts are much \nmore about combining other programs - piping the output from one to the \nother - than about any traditional scripting. Which, afaik, Lua isn't good \nat.\n\n> I agree with the above in principle, but I am afraid that is\n> only half of the solution to the problem Alex is having.\n> \n> In the longer term, libified git with script language bindings\n> would make the way git things work together a lot better. I've\n> always wanted to make merge-base a subroutine callable from\n> other things, so that I can say \"git diff A...B\" to mean \"diff\n> up to B since B forked from A\" ;-).\n\nYeah, we should libify some of it, to make things easier. That said, I \ndon't belive in the \"big-picture\" libification. The fact is, a lot of git \nreally _is_ about piping things from one part to another, and library \ninterfaces work horribly badly for that. You really want more of a \n\"stream\" interface, and that's just not something I see happening.\n\nI think one of the strengths of git is that you can use it in a very \ntraditional UNIX manner, and do your own pipelines. And that will \nobviously NEVER work well under Windows, if only because it's not the \nnatural way to do things.\n\nAgain, libification does nothing for that thing.\n\nWhat I'd suggest using an embedded interpreter for is literally just the \ncommon helper scripts. We'll never make \n\n\tgit-rev-list --header a..b -- tree | \n\t\tgrep -z '^author.*torvalds' |\n\t\t..\n\nstyle interesting power-user pipelines work in windows, but we _can_ make \nthe things like \"git commit\" work natively in windows without having to \nre-write it in C by just having an embedded interpreter.\n\nAnd I very much mean _embedded_. Otherwise we'll just have all the same \nproblems with perl and bash and versioning. \n\n> But we do need to talk to non-git things. git-grep needs a way\n> for ls-files to drive xargs/grep, for example. diff --cc reads\n> from GNU diff output. And for these external tools, the way\n> they expect the input to be fed to them or their output is taken\n> out is via UNIXy pipe.\n\nI was really thinking more of a simple shell-like script interpreter. \nSomething that we can make portable, by virtue of it _not_ being real \nshell. For example, the \"find | xargs\" stuff we do is really not that hard \nto do portably even on windows using standard C, it's just that you can't \ndo it THAT WAY portably without assuming that it's a full cygwin thing.\n\n\t\tLinus\n"},{"id":"16632","messageId":"Pine.LNX.4.64.0602231151580.3771@g5.osdl.org","threadId":"3405","inReplyTo":"Pine.LNX.4.63.0602232037260.30630@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-23T19:54:31Z","receivedAt":"2006-02-23T19:54:31Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Feb 2006, Johannes Schindelin wrote:\n> > \n> > Before anybody mentions tcl ;-).\n> \n> Darn, I had my suggestion sent out: Java ;-)\n\nI do see the smileys, but the fact is, \"perl\" is a hell of a lot more \nportable than either, if we want to talk executing processes and pipelines \netc. But even perl is clearly not portable enough, and has tons of version \nskew.\n\nJava, afaik, has absolutely _zero_ support for creating a new process and \npiping its output to another one and doing things like safe argument \nexpansion. Which is what almost all of the git scripts are all about.\n\n\t\tLinus\n"},{"id":"16633","messageId":"Pine.LNX.4.63.0602232112200.31035@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3405","inReplyTo":"Pine.LNX.4.64.0602231151580.3771@g5.osdl.org","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-23T20:19:03Z","receivedAt":"2006-02-23T20:19:03Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 23 Feb 2006, Linus Torvalds wrote:\n\n> On Thu, 23 Feb 2006, Johannes Schindelin wrote:\n> > > \n> > > Before anybody mentions tcl ;-).\n> > \n> > Darn, I had my suggestion sent out: Java ;-)\n> \n> I do see the smileys, but the fact is, \"perl\" is a hell of a lot more \n> portable than either, if we want to talk executing processes and pipelines \n> etc. But even perl is clearly not portable enough, and has tons of version \n> skew.\n> \n> Java, afaik, has absolutely _zero_ support for creating a new process and \n> piping its output to another one and doing things like safe argument \n> expansion. Which is what almost all of the git scripts are all about.\n\nYou are right, but for the wrong reason. Java is actually a wonderful \nthing to create new processes and talk between threads.\n\nBut Java is HUGE. No, it is rather HOOODGEEE.\n\nAnd I don't know if something like Lua does any good. The problem is not \nso much the language. It is the fork().\n\nAFAIAC, cygwin is pretty good at hiding Windows behind sortofa POSIX \nlayer. It hides it behind a POSIX layer *and* a \nperformance hit.\n\nI would rather like to see how all the fork()ing and |'ing can be done \nwith MinGW32.\n\nCiao,\nDscho\n"},{"id":"16634","messageId":"43FE1B9D.10403@vilain.net","threadId":"3405","inReplyTo":"Pine.LNX.4.64.0602231143290.3771@g5.osdl.org","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-23T20:31:25Z","receivedAt":"2006-02-23T20:31:25Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Linus Torvalds wrote:\n>>>There are many portable interpreters out there, and I don't mean perl. And \n>>>writing a small \"specialized for git\" one isn't even that hard. In fact, \n>>>most of the shell (and bash) hackery we do now would be unnecessary if we \n>>>just made a small \"git interpreter\" that ran \"git scripts\".\n>>Before anybody mentions tcl ;-).\n> Well, I was thinking more of the \"embeddable\" ones - things that are so \n> small that they can be compiled with the project. Things like Lua.\n [...]\n> I was really thinking more of a simple shell-like script interpreter. \n\nI like the term \"Domain Specific Language\" to refer to this sort of \nthing. It even hints at using the right kind of tools to achieve it, too :)\n\nSam.\n"},{"id":"16639","messageId":"20060223214353.GC5827@steel.home","threadId":"3405","inReplyTo":"Pine.LNX.4.64.0602230911410.3771@g5.osdl.org","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-23T21:43:53Z","receivedAt":"2006-02-23T21:43:53Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Linus Torvalds, Thu, Feb 23, 2006 18:13:43 +0100:\n> > Someday we'll have to start dropping features on Windows or restrict them\n> > beyond their usefullness.\n> \n> One thing that would help a bit would be to avoid shell.\n> \n> There are many portable interpreters out there, and I don't mean perl. And \n> writing a small \"specialized for git\" one isn't even that hard. In fact, \n> most of the shell (and bash) hackery we do now would be unnecessary if we \n> just made a small \"git interpreter\" that ran \"git scripts\".\n> \n> The fact that it would also help portability is just an added advantage.\n> \n\nI actually was dreaming about taking a vacation and rewrite at least\nthe most important scripts in C, but without cygwin. Implement the\nneeded subset of POSIX in compat/, workaround fork.\n\nThat'd help me to present git to my collegues without requiring them\nto install cygwin, perl and python first. It is a real problem to\nexplain why a new tool is better than the old one if the problem start\nright from installation, and it probably wont matter how bad the old\ntool is (it is, they know that too, but it has windows, doors and a\nmostly running man for busy-waiting cursor).\n\nA gits own interpreter would be more than, of course.\n"},{"id":"16655","messageId":"Pine.LNX.4.64.0602232229340.3771@g5.osdl.org","threadId":"3405","inReplyTo":"43FE1B9D.10403@vilain.net","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-24T06:43:52Z","receivedAt":"2006-02-24T06:43:52Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 24 Feb 2006, Sam Vilain wrote:\n> \n> I like the term \"Domain Specific Language\" to refer to this sort of thing. It\n> even hints at using the right kind of tools to achieve it, too :)\n\nJust for fun, I wrote a first cut at a script engine for passing pipes \naround.\n\nIt's designed so that the \"fork+exec with a pipe\" should be easily \nreplaced by \"spawn with a socket\" if that's what the target wants, but \nit also has some rather strange syntax, so I'm in no way claiming that \nthis is a sane approach.\n\nIt was fun to write, though. You can already do some strange things with \nit, like writing a script like this\n\n\tset @ --since=2.months.ago Makefile\n\texec git-rev-parse --default HEAD $@\n\t\tstdout arguments\n\texec git-rev-list $arguments\n\t\tstdout revlist\n\texec git-diff-tree --pretty --stdin\n\t\tstdin revlist\n\t\tstdout diff-tree-output\n\texec less -S\n\t\tstdin diff-tree-output\n\nwhich kind of shows the idea (it sets the \"@\" variable by hand, because \nthe silly \"git-script\" thing doesn't set it itself).\n\nI'm not sure this is worth pursuing (it really is a very strange kind of \nscript syntax), but it was amusing to do. \n\nNo docs - if you want to know how it works, you'll just have to read the \nequally strange sources.\n\n\t\tLinus\n\n----\ndiff-tree 3e7dbcaae63278ccd413d93ecf9cba65a0d07021 (from d27d5b3c5b97ca30dfc5c448dc8cdae914131051)\nAuthor: Linus Torvalds \nDate: Thu Feb 23 22:06:12 2006 -0800\n\n Add really strange script engine\n\ndiff --git a/Makefile b/Makefile\nindex 0c04882..247030b 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -164,7 +164,7 @@ PROGRAMS = \\\n \tgit-upload-pack$X git-verify-pack$X git-write-tree$X \\\n \tgit-update-ref$X git-symbolic-ref$X git-check-ref-format$X \\\n \tgit-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X \\\n-\tgit-describe$X git-merge-tree$X\n+\tgit-describe$X git-merge-tree$X git-script$X\n \n # what 'all' will build and 'install' will install, in gitexecdir\n ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)\n@@ -204,7 +204,7 @@ LIB_OBJS = \\\n \tquote.o read-cache.o refs.o run-command.o \\\n \tserver-info.o setup.o sha1_file.o sha1_name.o strbuf.o \\\n \ttag.o tree.o usage.o config.o environment.o ctype.o copy.o \\\n-\tfetch-clone.o \\\n+\tfetch-clone.o execute.o \\\n \t$(DIFF_OBJS)\n \n LIBS = $(LIB_FILE)\ndiff --git a/cache.h b/cache.h\nindex 5020f07..e4e66ce 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -352,4 +352,7 @@ extern int copy_fd(int ifd, int ofd);\n extern int receive_unpack_pack(int fd[2], const char *me, int quiet);\n extern int receive_keep_pack(int fd[2], const char *me, int quiet);\n \n+/* script execution engine.. */\n+extern int execute(const char *name, char *buf, unsigned int size);\n+\n #endif /* CACHE_H */\ndiff --git a/execute.c b/execute.c\nnew file mode 100644\nindex 0000000..abb6801\n--- /dev/null\n+++ b/execute.c\n@@ -0,0 +1,622 @@\n+/*\n+ * Stupid git script execution engine\n+ *\n+ * Copyrigt (C) 2006, Linus Torvalds\n+ *\n+ * There's one rule here: only ever expand a single level of variables.\n+ * In particular - we never expand as a string, and keep everything as\n+ * a list of entries. Always.\n+ *\n+ * This avoids all issues with quoting etc, since it's never an issue.\n+ * When we execute a program, we have a list of arguments, no quoting\n+ * or string parsing involved.\n+ */\n+#include \"cache.h\"\n+#include \n+\n+enum vartype {\n+\tvar_none,\n+\tvar_fd,\n+\tvar_array\n+};\n+\n+struct argument {\n+\tenum vartype type;\n+\tint fd, members, allocs, error;\n+\tconst char **array;\n+};\n+\n+struct variable {\n+\tconst char *name;\n+\tstruct variable *next;\n+\tstruct argument value;\n+};\n+\n+struct cmd_struct {\n+\tconst char *line;\n+\tunsigned int len;\n+\tstruct cmd_struct *subcmd;\n+\tstruct cmd_struct *next;\n+};\n+\n+struct parse_buf {\n+\tconst char *name;\n+\tconst char *error;\n+\tchar *prog;\n+\tunsigned int size;\n+\tunsigned int offset;\n+\tunsigned int line;\n+\tunsigned int linestart;\n+};\n+\n+static struct variable *vars = NULL;\n+static void run_program(struct cmd_struct *cmd);\n+\n+static int countline(struct parse_buf *buf)\n+{\n+\tint count = 0;\n+\tunsigned offset;\n+\n+\tfor (offset = buf->offset; offset < buf->size; offset++) {\n+\t\tunsigned char c = buf->prog[offset];\n+\t\tswitch (c) {\n+\t\tcase '\\n':\n+\t\t\tbuf->line++;\n+\t\t/* fallthrough */\n+\t\tcase '\\r':\n+\t\t\tcount = 0;\n+\t\t\tbuf->offset = offset + 1;\n+\t\t\tbuf->prog[offset] = 0;\n+\t\t\tcontinue;\n+\t\tcase ' ':\n+\t\t\tcount++;\n+\t\t\tcontinue;\n+\t\tcase '\\t':\n+\t\t\tcount = (count + 8) & ~7;\n+\t\t\tcontinue;\n+\t\tdefault:\n+\t\t\tbuf->linestart = offset;\n+\t\t\treturn count;\n+\t\t}\n+\t}\n+\tbuf->offset = offset;\n+\treturn -2;\n+}\n+\n+/*\n+ * When this is called, we've already done the indentation check,\n+ * and \"buf->linestart\" points to the actual start of the command.\n+ */\n+static struct cmd_struct *parse_one_line(struct parse_buf *buf)\n+{\n+\tunsigned int offset;\n+\tstruct cmd_struct *cmd = xmalloc(sizeof(*cmd));\n+\tmemset(cmd, 0, sizeof(*cmd));\n+\n+\toffset = buf->linestart;\n+\tcmd->line = buf->prog + offset;\n+\tfor ( ; offset < buf->size; offset++) {\n+\t\tunsigned char c = buf->prog[offset];\n+\t\tswitch (c) {\n+\t\tcase '\\n':\n+\t\t\tbuf->prog[offset++] = 0;\n+\t\t\tbuf->line++;\n+\t\t\tbreak;\n+\t\tdefault:\n+\t\t\tcontinue;\n+\t\t}\n+\t\tbreak;\n+\t}\n+\tbuf->offset = offset;\n+\treturn cmd;\n+}\n+\n+static struct cmd_struct *parse(struct parse_buf *buf, int indent)\n+{\n+\tstruct cmd_struct *first = NULL, *last = NULL;\n+\n+\tfor (;;) {\n+\t\tstruct cmd_struct *now;\n+\t\tint newindent = countline(buf);\n+\n+\t\tif (newindent < indent)\n+\t\t\tbreak;\n+\t\tif (!first)\n+\t\t\tindent = newindent;\n+\t\tif (newindent > indent) {\n+\t\t\tstruct cmd_struct *subcmd;\n+\t\t\tif (last->subcmd) {\n+\t\t\t\tbuf->error = \"bad indentation\";\n+\t\t\t\treturn NULL;\n+\t\t\t}\n+\t\t\tsubcmd = parse(buf, newindent);\n+\t\t\tif (!subcmd)\n+\t\t\t\treturn NULL;\n+\t\t\tlast->subcmd = subcmd;\n+\t\t\tcontinue;\n+\t\t}\n+\t\tnow = parse_one_line(buf);\n+\t\tif (!now)\n+\t\t\treturn NULL;\n+\t\tif (last)\n+\t\t\tlast->next = now;\n+\t\telse\n+\t\t\tfirst = now;\n+\t\tlast = now;\n+\t}\n+\treturn first;\n+}\n+\n+static struct cmd_struct *exec_bad(struct cmd_struct *cmd, struct argument *arg)\n+{\n+\tprintf(\"unrecognized command: '%s'\\n\", cmd->line);\n+\treturn NULL;\n+}\n+\n+static struct cmd_struct *exec_echo(struct cmd_struct *cmd, struct argument *arg)\n+{\n+\tint i;\n+\tfor (i = 0; i < arg->members; i++)\n+\t\tprintf(\"%s%c\", arg->array[i], i == arg->members-1 ? '\\n': ' ');\n+\treturn cmd->next;\n+}\n+\n+static struct variable *find_variable(const char *name)\n+{\n+\tstruct variable *var = vars;\n+\twhile (var) {\n+\t\tif (!strcmp(var->name, name))\n+\t\t\treturn var;\n+\t\tvar = var->next;\n+\t}\n+\treturn NULL;\n+}\n+\n+static struct variable *create_variable(const char *name)\n+{\n+\tstruct variable *var = find_variable(name);\n+\n+\tif (!var) {\n+\t\tvar = xmalloc(sizeof(*var));\n+\t\tmemset(var, 0, sizeof(*var));\n+\t\tvar->name = name;\n+\t\tvar->next = vars;\n+\t\tvars = var;\n+\t}\n+\treturn var;\n+}\n+\n+static struct cmd_struct *exec_set(struct cmd_struct *cmd, struct argument *arg)\n+{\n+\tint count = arg->members;\n+\tstruct variable *var;\n+\tconst char *name;\n+\tunsigned size;\n+\n+\tif (!count)\n+\t\treturn cmd->next;\n+\tname = arg->array[0];\n+\tvar = create_variable(arg->array[0]);\n+\n+\tvar->value.members = count-1;\n+\tsize = count * sizeof(var->value.array[0]);\n+\tvar->value.array = xmalloc(size);\n+\tmemcpy(var->value.array, arg->array+1, size);\n+\n+\treturn cmd->next;\n+}\n+\n+static void free_arg_list(struct argument *arg)\n+{\n+\t/*\n+\t * We can't free the actual entries, since we re-use them\n+\t * on expansion. Right or wrong, that's how it is...\n+\t */\n+\tfree(arg->array);\n+}\n+\n+static void drop_variable(struct variable *var)\n+{\n+\tfree_arg_list(&var->value);\n+\tfree(var);\n+}\n+\n+static struct cmd_struct *exec_unset(struct cmd_struct *cmd, struct argument *arg)\n+{\n+\tint i;\n+\n+\tfor (i = 0; i < arg->members; i++) {\n+\t\tconst char *name = arg->array[i];\n+\t\tstruct variable *var, **p = &vars;\n+\n+\t\twhile ((var = *p) != NULL) {\n+\t\t\tif (!strcmp(var->name, name)) {\n+\t\t\t\t*p = var->next;\n+\t\t\t\tdrop_variable(var);\n+\t\t\t\tbreak;\n+\t\t\t}\n+\t\t\tp = &var->next;\n+\t\t}\n+\t}\n+\treturn cmd->next;\n+}\n+\n+static struct cmd_struct *exec_exit(struct cmd_struct *cmd, struct argument *arg)\n+{\n+\tint value = 0;\n+\tif (arg->members)\n+\t\tvalue = atoi(arg->array[0]);\n+\texit(value);\n+}\n+\n+static struct cmd_struct *exec_else(struct cmd_struct *cmd, struct argument *arg)\n+{\n+\treturn cmd->next;\n+}\n+\n+static struct cmd_struct *exec_if(struct cmd_struct *cmd, struct argument *arg)\n+{\n+\tstruct cmd_struct *pos, *neg;\n+\n+\tpos = cmd->subcmd;\n+\tneg = cmd->next;\n+\tif (neg) {\n+\t\tif (!strncmp(neg->line, \"else\", 4))\n+\t\t\tneg = neg->subcmd;\n+\t\telse\n+\t\t\tneg = NULL;\n+\t}\n+\tif (!arg->members)\n+\t\tpos = neg;\n+\trun_program(pos);\n+\treturn cmd->next;\n+}\n+\n+static int match_cmd(const char *match, struct cmd_struct *cmd)\n+{\n+\tint len = strlen(match), cmdlen = strlen(cmd->line);\n+\tif (cmdlen < len)\n+\t\treturn 0;\n+\tif (cmdlen > len && !isspace(cmd->line[len]))\n+\t\treturn 0;\n+\treturn !memcmp(match, cmd->line, len);\n+}\n+\n+static int set_input(int *redirect, const char *val)\n+{\n+\tstruct variable *var;\n+\n+\twhile (isspace(*val))\n+\t\tval++;\n+\tvar = find_variable(val);\n+\tif (!var || var->value.type != var_fd)\n+\t\tdie(\"bad 'fd' variable %s\", val);\n+\n+\t*redirect = var->value.fd;\n+\tvar->value.fd = -1;\n+\treturn 0;\n+}\n+\n+static int set_output(int *redirect, const char *val)\n+{\n+\tint fd[2];\n+\tstruct variable *var;\n+\n+\twhile (isspace(*val))\n+\t\tval++;\n+\tvar = create_variable(val);\n+\n+\tif (pipe(fd) < 0)\n+\t\tdie(\"unable to pipe\");\n+\tvar->value.type = var_fd;\n+\tvar->value.fd = fd[0];\n+\t*redirect = fd[1];\n+\treturn 0;\n+}\n+\n+/*\n+ * Only these routines should need to be ported to a \"spawn()\" interface\n+ */\n+static struct cmd_struct *exec_exec(struct cmd_struct *cmd, struct argument *arg)\n+{\n+\tint redirect[3];\n+\tpid_t pid;\n+\tint nr = arg->members;\n+\tstruct cmd_struct *io;\n+\n+\tif (!nr) {\n+\t\trun_program(cmd->subcmd);\n+\t\treturn cmd->next;\n+\t}\n+\n+\tmemset(redirect, 0, sizeof(redirect));\n+\tfor (io = cmd->subcmd; io ; io = io->next) {\n+\t\tif (match_cmd(\"stdin\", io)) {\n+\t\t\tset_input(redirect+0, io->line + 5);\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (match_cmd(\"stdout\", io)) {\n+\t\t\tset_output(redirect+1, io->line + 6);\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (match_cmd(\"stderr\", io)) {\n+\t\t\tset_output(redirect+2, io->line + 6);\n+\t\t\tcontinue;\n+\t\t}\n+\t}\n+\n+\t/*\n+\t * HERE! Use spawn if necessary - the fd redirect table has been set up\n+\t */\n+\tpid = vfork();\n+\tif (pid < 0) {\n+\t\terror(\"vfork failed (%s)\", strerror(errno));\n+\t\treturn NULL;\n+\t}\n+\n+\tif (!pid) {\n+\t\tint retval;\n+\t\tif (redirect[0]) {\n+\t\t\tdup2(redirect[0], 0);\n+\t\t\tclose(redirect[0]);\n+\t\t}\n+\t\tif (redirect[1]) {\n+\t\t\tdup2(redirect[1], 1);\n+\t\t\tclose(redirect[1]);\n+\t\t}\n+\t\tif (redirect[2]) {\n+\t\t\tdup2(redirect[2], 2);\n+\t\t\tclose(redirect[2]);\n+\t\t}\n+\t\tretval = execvp(arg->array[0], (char *const*) arg->array);\n+\t\texit(255);\n+\t}\n+\n+\tif (redirect[0])\n+\t\tclose(redirect[0]);\n+\tif (redirect[1])\n+\t\tclose(redirect[1]);\n+\tif (redirect[2])\n+\t\tclose(redirect[2]);\n+\n+\t/*\n+\t * If we don't have anybody waiting for output,\n+\t * wait for it\n+\t */\n+\tif (!redirect[1]) {\n+\t\tint status;\n+\t\twhile (waitpid(pid, &status, 0) < 0) {\n+\t\t\tif (errno == EINTR)\n+\t\t\t\tcontinue;\n+\t\t\terror(\"unable to wait for child (%s)\", strerror(errno));\n+\t\t\treturn NULL;\n+\t\t}\n+\t\t/* FIXME! Put exit status in a variable! */\n+\t}\n+\trun_program(cmd->subcmd);\n+\treturn cmd->next;\n+}\n+\n+static struct cmd_struct *exec_nop(struct cmd_struct *cmd, struct argument *arg)\n+{\n+\treturn cmd->next;\n+}\n+\n+static const struct cmd_def {\n+\tconst char *n;\n+\tint len;\n+\tstruct cmd_struct *(*exec)(struct cmd_struct *, struct argument *);\n+} cmds[] = {\n+\t{ \"bad\", 0, exec_bad },\n+\t{ \"set\", 3, exec_set },\n+\t{ \"unset\", 5, exec_unset },\n+\t{ \"echo\", 4, exec_echo },\n+\t{ \"exit\", 4, exec_exit },\n+\t{ \"if\", 2, exec_if },\n+\t{ \"else\", 4, exec_else },\n+\t{ \"exec\", 4, exec_exec },\n+\t{ \"stdin\", 5, exec_nop },\n+\t{ \"stdout\", 6, exec_nop },\n+\t{ \"stderr\", 6, exec_nop },\n+};\n+\n+static void add_argument(struct argument *arg, const char *n)\n+{\n+\tint allocs = arg->allocs, members = arg->members;\n+\n+\tif (members+1 >= allocs) {\n+\t\tallocs = (allocs * 3) / 2 + 32;\n+\t\targ->array = xrealloc(arg->array, allocs*sizeof(arg->array[0]));\n+\t\targ->allocs = allocs;\n+\t}\n+\targ->array[members++] = n;\n+\targ->array[members] = NULL;\n+\targ->members = members;\n+}\n+\n+static int get_word(const char *line, const char **res)\n+{\n+\tint quoted = 0;\n+\tint offset = 0;\n+\tint stop = 0;\n+\tchar *buf;\n+\n+\tfor (;;) {\n+\t\tunsigned char c = line[offset];\n+\t\tif (!c)\n+\t\t\tbreak;\n+\t\toffset++;\n+\t\tif (c == '\\\\') {\n+\t\t\tquoted ^= 1;\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (quoted) {\n+\t\t\tquoted = 0;\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (stop) {\n+\t\t\tif (c == stop)\n+\t\t\t\tstop = 0;\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (c == '\\'' || c == '\"') {\n+\t\t\tstop = c;\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (!isspace(c)) {\n+\t\t\tcontinue;\n+\t\t}\n+\t\toffset--;\n+\t\tbreak;\n+\t}\n+\tif (quoted || stop)\n+\t\treturn -1;\n+\tbuf = xmalloc(offset+1);\n+\tmemcpy(buf, line, offset);\n+\tbuf[offset] = 0;\n+\t*res = buf;\n+\treturn offset;\n+}\n+\n+static int expand_word(const char *line, struct argument *arg)\n+{\n+\tconst char *word;\n+\tint offset = get_word(line, &word);\n+\n+\tif (offset > 0)\n+\t\tadd_argument(arg, word);\n+\treturn offset;\n+}\n+\n+static void convert_fd_into_array(struct variable *var)\n+{\n+\tint fd = var->value.fd;\n+\tchar buffer[8192];\n+\tint len, offset, last;\n+\n+\tvar->value.fd = -1;\n+\tvar->value.type = var_array;\n+\tlen = 0;\n+\tfor (;;) {\n+\t\tint ret = read(fd, buffer + len, sizeof(buffer) - len);\n+\t\tif (!ret)\n+\t\t\tbreak;\n+\t\tif (ret < 0) {\n+\t\t\tif (errno == EINTR)\n+\t\t\t\tcontinue;\n+\t\t\tbreak;\n+\t\t}\n+\t\tlen += ret;\n+\t\tif (len >= sizeof(buffer))\n+\t\t\tbreak;\n+\t}\n+\n+\tlast = 0;\n+\tfor (offset = 0; offset < len; offset++) {\n+\t\tunsigned char c = buffer[offset];\n+\t\tif (c == '\\n') {\n+\t\t\tbuffer[offset] = 0;\n+\t\t\tadd_argument(&var->value, buffer+last);\n+\t\t\tlast = offset+1;\n+\t\t\tcontinue;\n+\t\t}\n+\t}\t\t\n+}\n+\n+static int expand_variable(const char *line, struct argument *arg)\n+{\n+\tconst char *word;\n+\tint offset = get_word(line+1, &word);\n+\n+\tif (offset > 0) {\n+\t\tstruct variable *var = find_variable(word);\n+\t\toffset++;\t/* The '$' character itself */\n+\t\tif (var) {\n+\t\t\tint i;\n+\t\t\tif (var->value.type == var_fd)\n+\t\t\t\tconvert_fd_into_array(var);\n+\t\t\tfor (i = 0; i < var->value.members; i++)\n+\t\t\t\tadd_argument(arg, var->value.array[i]);\n+\t\t}\n+\t}\n+\treturn offset;\n+}\n+\n+static int expand_value(const char *line, struct argument *arg)\n+{\n+\tunsigned char c = *line;\n+\n+\tswitch (c) {\n+\tcase '$':\n+\t\treturn expand_variable(line, arg);\n+\tdefault:\n+\t\treturn expand_word(line, arg);\n+\t}\n+}\n+\n+static struct argument *expand_line(const char *line)\n+{\n+\tstruct argument *arg;\n+\n+\targ = xmalloc(sizeof(*arg));\n+\tmemset(arg, 0, sizeof(*arg));\n+\targ->type = var_array;\n+\tfor (;;) {\n+\t\tint n;\n+\t\twhile (isspace(*line)) {\n+\t\t\tline++;\n+\t\t}\n+\t\tif (!*line)\n+\t\t\tbreak;\n+\t\tn = expand_value(line, arg);\n+\t\tif (n <= 0)\n+\t\t\tbreak;\n+\t\tline += n;\n+\t}\n+\treturn arg;\n+}\n+\n+static void run_program(struct cmd_struct *cmd)\n+{\n+\twhile (cmd) {\n+\t\tint i;\n+\t\tconst struct cmd_def *run = cmds+0;\n+\t\tstruct argument *arg = NULL;\n+\t\tint cmdlen = strlen(cmd->line);\n+\n+\t\tfor (i = 1; i < sizeof(cmds)/sizeof(cmds[0]); i++) {\n+\t\t\tconst struct cmd_def *def = cmds + i;\n+\t\t\tint len = def->len;\n+\t\t\tif (len > cmdlen)\n+\t\t\t\tcontinue;\n+\t\t\tif (len < cmdlen && !isspace(cmd->line[len]))\n+\t\t\t\tcontinue;\n+\t\t\tif (memcmp(cmd->line, def->n, len))\n+\t\t\t\tcontinue;\n+\t\t\trun = def;\n+\t\t\targ = expand_line(cmd->line + len);\n+\t\t\tbreak;\n+\t\t}\n+\t\tcmd = run->exec(cmd, arg);\n+\t}\n+}\n+\n+int execute(const char *name, char *buf, unsigned int size)\n+{\n+\tstruct parse_buf p;\n+\tstruct cmd_struct *program;\n+\n+\tp.name = name;\n+\tp.prog = buf;\n+\tp.size = size;\n+\tp.offset = 0;\n+\tp.line = 1;\n+\tp.error = \"empty program\";\n+\n+\tprogram = parse(&p, -1);\n+\tif (!program || p.offset != p.size)\n+\t\tdie(\"parse error at %s:%d: %s\", p.name, p.line, p.error);\n+\n+\trun_program(program);\n+\treturn 0;\n+}\ndiff --git a/script.c b/script.c\nnew file mode 100644\nindex 0000000..ae85598\n--- /dev/null\n+++ b/script.c\n@@ -0,0 +1,58 @@\n+/*\n+ * Silly git script language\n+ *\n+ * Copyright (C) 2006, Linus Torvalds\n+ */\n+#include \"cache.h\"\n+\n+static const char script_usage[] = \"git-script \";\n+\n+int main(int argc, char **argv)\n+{\n+\tint fd;\n+\tchar *buf;\n+\tconst char *filename;\n+\tunsigned int size, alloc;\n+\n+\tfd = 0;\n+\tswitch (argc) {\n+\tcase 1:\n+\t\tfilename = \"stdin\";\n+\t\tfd = dup(0);\n+\t\tclose(0);\n+\t\topen(\"/dev/null\", O_RDONLY);\n+\t\tbreak;\n+\tcase 2:\n+\t\tfilename = argv[1];\n+\t\tfd = open(filename, O_RDONLY);\n+\t\tif (fd < 0)\n+\t\t\tdie(\"unable to open '%s': %s\", filename, strerror(errno));\n+\t\tbreak;\n+\tdefault:\n+\t\tusage(script_usage);\n+\t}\n+\n+\tbuf = NULL;\n+\talloc = 0;\n+\tsize = 0;\n+\tfor (;;) {\n+\t\tint nr;\n+\t\tif (size >= alloc) {\n+\t\t\talloc = (alloc * 3) / 2 + 8192;\n+\t\t\tbuf = xrealloc(buf, alloc);\n+\t\t}\n+\t\tnr = read(fd, buf + size, alloc - size);\n+\t\tif (!nr)\n+\t\t\tbreak;\n+\t\tif (nr < 0) {\n+\t\t\tif (errno == EAGAIN || errno == EINTR)\n+\t\t\t\tcontinue;\n+\t\t\tdie(\"script read failed (%s)\", strerror(errno));\n+\t\t}\n+\t\tsize += nr;\n+\t}\n+\tclose(fd);\n+\n+\texecute(filename, buf, size);\n+\treturn 0;\n+}\n"},{"id":"16666","messageId":"20060224120225.GE12309@localdomain","threadId":"3405","inReplyTo":"81b0412b0602220835p4c4243edm145ee827eb706121@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-02-24T12:02:25Z","receivedAt":"2006-02-24T12:02:25Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Alex Riesen wrote:\n> On 2/21/06, Sam Vilain wrote:\n> > Alex Riesen wrote:\n> > >>>Does not work here (ActiveState Build 811, Perl 5.8.6):\n> > >>>$ perl -e 'open(F, \"-|\")'\n> > >>>'-' is not recognized as an internal or external command,\n> > >>>operable program or batch file.\n> > >>Portability, Ease of Coding, Few CPAN Module Dependencies. Pick any two.\n> > > Sometimes an upgrade is just out of question. Besides, that'd mean an\n> > > upgrade to another operating system, because very important scripts\n> > > over here a just not portable to anything else but\n> > > \"ActiveState Perl on Windows (TM)\"\n> > > I just have no choice.\n> >\n> > Sure, but perhaps IPC::Open2 or some other CPAN module has solved this\n> > problem already.\n> \n> IPC::Open2 works! Well \"kind of\": there are still strange segfaults regarding\n> stack sometimes. And I don't know yet whether and how the arguments are escaped\n> (Windows has no argument array. It has that bloody stupid one-line command line)\n\nIt seems that ActiveState has more problems with pipes than it does with fork.\nIf it supports redirects reasonably well, this avoids pipes entirely and\nmay be more stable as a result (but possibly slower):\n\n# IO::File is standard in Perl 5.x, new_tmpfile\n# returns an open filehandle to an already unlinked file\n\nuse IO::File;\nmy $out = IO::File->new_tmpfile;\nfile\nmy $pid = fork;\ndefined $pid or die $!;\nif (!$pid) {\n\t# redirects STDOUT to $out file\n\topen STDOUT, '>&', $out or die $!;\n\texec('foo','bar');\n}\nwaitpid $pid, 0;\nseek $out, 0, 0;\nwhile (<$out>) {\n\t...\n}\n\nWriting and reading from a tempfile are very fast for me in Linux, and probably\nnot much slower than pipes. Of course I'm still assuming file descriptors stay\nshared after a 'fork', which may be asking too much on Windows. Using something\nfrom File::Temp to get a temp filename would still work.\n\n-- \nEric Wong\n"},{"id":"16673","messageId":"Pine.LNX.4.63.0602241440330.9461@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3405","inReplyTo":"20060224120225.GE12309@localdomain","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-24T13:44:08Z","receivedAt":"2006-02-24T13:44:08Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 24 Feb 2006, Eric Wong wrote:\n\n> Writing and reading from a tempfile are very fast for me in Linux, and \n> probably not much slower than pipes.\n\nSorry, but no. Really no. Pipes have several advantages over temporary \nfiles:\n\n- The second program can already work on the data before the first \n finishes.\n- Most simple temp file handling has security issues.\n- You need write access.\n\nHth,\nDscho\n"},{"id":"16680","messageId":"Pine.LNX.4.64.0602240800240.3771@g5.osdl.org","threadId":"3405","inReplyTo":"Pine.LNX.4.63.0602241440330.9461@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-24T16:14:52Z","receivedAt":"2006-02-24T16:14:52Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 24 Feb 2006, Johannes Schindelin wrote:\n> \n> Sorry, but no. Really no. Pipes have several advantages over temporary \n> files:\n> \n> - The second program can already work on the data before the first \n> finishes.\n\nThis really is a _huge_ issue in general, although probably not a very \nbig one in this case.\n\nThis is what I talked about when I said \"streaming\" data. Look at the \ndifference between\n\n\tgit whatchanged -s drivers/usb\n\nand\n\n\tgit log drivers/usb\n\nin the kernel repo. They give almost the same output, but...\n\nNotice how one starts _immediately_, while the other starts after a few \nseconds (or, if you have a slow machine, and an unpacked archive, after \ntens of seconds or longer).\n\nAnd the reason is that \"git log\" uses \"git-rev-list\" with a path limiter, \nand currently that ends up having to walk basically the whole history in \norder to generate a minimal graph.\n\nIn contrast, \"git-whatchanged\" uses \"git-diff-tree\" to limit the output, \nand git-diff-tree doesn't care about \"minimal graph\" or crud like that: it \njust cares about discarding any local commits that aren't interesting. It \ndoesn't need to worry about updating parent chains etc, so it can do it \nall incrementally - and can thus start output as soon as it gets anything \nat all.\n\nNow, maybe you think that \"a few seconds\" isn't a big deal. Sure, it's \nactually fast as hell, considering what it is doing, and anybody should be \nreally really impressed that we can do that at all.\n\nBut (a) it _is_ a huge deal. Responsiveness is really important. And \nworse: (b) it scales badly with repository size. Creating the whole \ndata-set before starting to output it really doesn't scale.\n\nNow, I have ways to make \"git-rev-list\" better. It doesn't really need to \nwalk the _whole_ history for its path limiting before it can start \noutputting stuff: it really _could_ do things more incrementally. However, \nit's a real bitch sometimes to work with incremental data when you don't \nknow everything, so it gets a lot more complicated. \n\nSo my point isn't that \"git log drivers/usb\" will get less and less \nresponsive over time. I can fix that - eventually. My point is that in \norder to make it more responsive, I need to make it less synchronous. More \n\"streaming\". \n\nAnd that is where a pipe is so much better than a file. It's very \nfundamentally a streaming interface.\n\nHowever, I suspect some of these issues are non-issues for the perl \nprograms that work with a few entries at a time.\n\n\t\tLinus\n"},{"id":"16759","messageId":"20060226195552.GA30735@trixie.casa.cgf.cx","threadId":"3405","inReplyTo":"81b0412b0602230607n22146a77k36929f0ad9e44d53@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-02-26T19:55:52Z","receivedAt":"2006-02-26T19:55:52Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:\n>On 2/23/06, Andreas Ericsson wrote:\n>>>>Not to be unhelpful or anything, but activestate perl seems to be quite\n>>>>a lot of bother. Is it worth supporting it?\n>>>\n>>>\n>>>It's not activestate perl actually. It's only one platform it also\n>>>_has_ to support. Is it worth supporting Windows?\n>>\n>>With or without cygwin? With cygwin, I'd say \"yes, unless it makes\n>>things terribly difficult to maintain and so long as we don't take\n>>performance hits on unices\". Without cygwin, I'd say \"What? It runs\n>>on windows?\".\n>\n>There not much difference with or without cygwin. The penalties of\n>doing any kind of support for it will pile up (as they started to do\n>with pipes). Someday we'll have to start dropping features on Windows\n>or restrict them beyond their usefullness. The fork emulation in\n>cygwin isn't perfect,\n\nIf the speed of cygwin's fork is an issue then I'd previously suggested\nusing spawn*. The spawn family of functions were designed to emulate\nWindows functions of the same name. They start a new process without\nthe requirement of forking.\n\n>signals do not work reliably (if at all),\n\nI'm not sure if you're mixing cygwin with windows here but if signals do\nnot work reliably in Cygwin then that is something that we'd like to\nknow about. Signals *obviously* have to work fairly well for programs\nlike ssh, bash, and X to work, however.\n\nNative Windows, OTOH, hardly has any signals at all and deals with\nsignals in a way that is only vaguely like linux.\n\n>filesystem is slow and locked down, and exec-attribute is NOT really\n>useful even on NTFS (it is somehow related to execute permission and\n>open files. I still cannot figure out how exactly are they related).\n\nAgain, it's not clear if you're talking about Windows or Cygwin but\nunder Cygwin, in the default configuration, the exec attribute means the\nsame thing to cygwin as it does to linux.\n\nAs always, if you have questions or problems with cygwin, you can ask in\nthe proper forum. The available cygwin mailing lists are here:\nhttp://cygwin.com/lists.html.\n\nWould getting git into the cygwin distribution solve any problems with\ngit adoption on Windows? This would get an automatic green light from\nanyone who was interested, if so. Someone would just have to send an\n\"ITP\" (Intent To Package) to the cygwin-apps mailing list and provide a\npackage using the guidelines here: http://cygwin.com/setup.html .\n\ncgf\n--\nChristopher Faylor\t\t\tspammer? ->\taaaspam@sourceware.org\nCygwin Co-Project Leader\nTimeSys, Inc.\n"},{"id":"16761","messageId":"Pine.LNX.4.64.0602261217080.22647@g5.osdl.org","threadId":"3405","inReplyTo":"20060226195552.GA30735@trixie.casa.cgf.cx","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-26T20:18:19Z","receivedAt":"2006-02-26T20:18:19Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 26 Feb 2006, Christopher Faylor wrote:\n> \n> If the speed of cygwin's fork is an issue then I'd previously suggested\n> using spawn*. The spawn family of functions were designed to emulate\n> Windows functions of the same name. They start a new process without\n> the requirement of forking.\n\nI thought that cygwin didn't implement the posix_spawn*() family?\n\nAnyway, we probably _can_ use posix_spawn() in various places, and \nespecially if that helps windows performance, we should.\n\n\t\tLinus\n"},{"id":"16766","messageId":"20060226203310.GB30735@trixie.casa.cgf.cx","threadId":"3405","inReplyTo":"43FDB8CC.5000503@op5.se","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-02-26T20:33:10Z","receivedAt":"2006-02-26T20:33:10Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Feb 23, 2006 at 02:29:48PM +0100, Andreas Ericsson wrote:\n>Alex Riesen wrote:\n>>On 2/23/06, Andreas Ericsson wrote:\n>>\n>>>Not to be unhelpful or anything, but activestate perl seems to be quite\n>>>a lot of bother. Is it worth supporting it?\n>>\n>>\n>>It's not activestate perl actually. It's only one platform it also\n>>_has_ to support.\n>>Is it worth supporting Windows?\n>\n>\n>With or without cygwin? With cygwin, I'd say \"yes, unless it makes \n>things terribly difficult to maintain and so long as we don't take \n>performance hits on unices\". Without cygwin, I'd say \"What? It runs on \n>windows?\".\n>\n>If we claim to support windows but do a poor job of it, no-one else will \n>start working on a windows-port. If we don't claim to support windows \n>but say that \"it's known to work with cygwin, although be aware of these \n>performance penalties...\", eventually someone will come along with their \n>shiny Visual Express and hack up support for it, even if some tools will \n>be missing and others unnecessarily complicated.\n\nWell, with Cygwin, you've at least got the ear of one of the Cygwin\nmaintainers, which should be worth something.\n\nEven if I disappear, you can always send concerns to the Cygwin mailing\nlist. Do the ActiveState folks respond to complaints about things as\nbasic as pipes not working in perl?\n\nCygwin's goal is to make Windows look as much like Linux as we can\nmanage, so, unless we're total incompetents (which has been hinted in\nthis mailing list from time to time), it has *got* to be better,\nsource-code-wise to target Windows-running-Cygwin than\njust-plain-Windows. However, as has been noted, that means that there\nwill be a speed tradeoff.\n\nI think that, for most projects, the convenience of not having to\nclutter the code with substantial accommodations for the windows/POSIX\nmismatch usually offsets the annoyance of the speed penalty. Maybe\nthat's not the case for git, however.\n\nAnyway, we're willing, within the limits of available time, to help out\nwhere git uncovers issues with Cygwin. I just fixed some stuff in\ndirent.h in the last Cygwin release, as a direct result of people noting\na problem here. Basically, I don't want git to be a morasse of #ifdef\n__CYGWIN_'s and I'll do whatever I can to help.\n\nWe're always trying to tweak things to improve speed in Cygwin and am\nopen to intelligent suggestions about how we can make things better.\nThe dance between total linux compatibility and speed is one that we\nstruggle with all of the time and, sadly, over time, we've probably\nsacrificed speed in the name of functionality. That's probably because\nit's easy to fix a problem like \"close-on-exec doesn't work for sockets\"\nand feel good that you've fixed a bug even if you've just added a few\nmicroseconds to fork/exec.\n\ncgf\n"},{"id":"16768","messageId":"20060226204027.GC30735@trixie.casa.cgf.cx","threadId":"3405","inReplyTo":"Pine.LNX.4.64.0602261217080.22647@g5.osdl.org","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-02-26T20:40:27Z","receivedAt":"2006-02-26T20:40:27Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Sun, Feb 26, 2006 at 12:18:19PM -0800, Linus Torvalds wrote:\n>On Sun, 26 Feb 2006, Christopher Faylor wrote:\n>>If the speed of cygwin's fork is an issue then I'd previously suggested\n>>using spawn*. The spawn family of functions were designed to emulate\n>>Windows functions of the same name. They start a new process without\n>>the requirement of forking.\n>\n>I thought that cygwin didn't implement the posix_spawn*() family?\n\nRight. It just implements the windows version of spawn. I looked more\nclosely at the posix_spawn functions after you last suggested it and,\nwhile it would be possible to implement this in cygwin, these functions\nare a lot more heavyweight than the windows-like implementation of spawn\nthat are already in cygwin. So, they would come with their own\nperformance penalty.\n\nThe cygwin/windows version of spawn is basically like an extended version\nof exec*():\n\npid = spawnlp (P_NOWAIT, \"/bin/ls\", \"ls\", \"-l\", NULL);\n\nwill start \"/bin/ls\" and return a pid which can be used in waitpid.\nThere is still some overhead to this function but it basically is just a\nwrapper around the Windows CreateProcess, which means that it doesn't\ngo through the annoying overhead of Cygwin's fork.\n\nThe posix_spawn stuff is in my todo list but the Windows spawn stuff\ncould be used now.\n\ncgf\n"},{"id":"16773","messageId":"20060226231701.GA11961@nospam.com","threadId":"3405","inReplyTo":"20060226195552.GA30735@trixie.casa.cgf.cx","subject":"NT directory traversal speed on 25K files on Cygwin","fromName":"Rutger Nijlunsing","fromEmail":"rutger@nospam.com","sentAt":"2006-02-26T23:17:01Z","receivedAt":"2006-02-26T23:17:01Z","isPatch":false,"sender":{"key":"rutger.nijlunsing@gmail.com","avatar":null},"body":"On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:\n> On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:\n> >filesystem is slow and locked down, and exec-attribute is NOT really\n> >useful even on NTFS (it is somehow related to execute permission and\n> >open files. I still cannot figure out how exactly are they related).\n> \n> Again, it's not clear if you're talking about Windows or Cygwin but\n> under Cygwin, in the default configuration, the exec attribute means the\n> same thing to cygwin as it does to linux.\n\nI don't know about native Windows speed, but comparing NutCracker with\nCygwin on a simple 'find . | wc -l' already gives a clue that looking\nat Cygwin to benchmark NT file inspection IO will give a skewed\npicture:\n\n##### NutCracker\n$ time find . | wc -l\n\nreal 0m 1.44s\nuser 0m 0.45s\nsys 0m 0.98s\n 25794\n\n##### Cygwin\n$ time c:\\\\cygwin\\\\bin\\\\find . | wc -l\n\nreal 0m 6.72s\nuser 0m 1.09s\nsys 0m 5.59s\n 25794\n\n##### CMD.EXE + DIR /S\nC:\\PROJECT> c:\\cygwin\\bin\\time cmd /c dir /s >NUL\n0.01user 0.01system 0:05.70elapsed 0%CPU (0avgtext+0avgdata 6320maxresident)k\n0inputs+0outputs (395major+0minor)pagefaults 0swaps\n\n##### Cygwin 'find -ls' (NutCracker doesn't have a '-ls')\nC:\\PROJECT> c:\\cygwin\\bin\\time c:\\cygwin\\bin\\find -ls | wc -l\n2.79user 7.81system 0:10.60elapsed 100%CPU (0avgtext+0avgdata 14480maxresident)k\n 25794\n\n\nRegards,\nRutger.\n\n-- \nRutger Nijlunsing ---------------------------------- eludias ed dse.nl\nnever attribute to a conspiracy which can be explained by incompetence\n----------------------------------------------------------------------\n"},{"id":"16786","messageId":"20060227011801.GB9264@trixie.casa.cgf.cx","threadId":"3405","inReplyTo":"20060226231701.GA11961@nospam.com","subject":"Re: NT directory traversal speed on 25K files on Cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-02-27T01:18:01Z","receivedAt":"2006-02-27T01:18:01Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Mon, Feb 27, 2006 at 12:17:01AM +0100, Rutger Nijlunsing wrote:\n>On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:\n>>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:\n>>>filesystem is slow and locked down, and exec-attribute is NOT really\n>>>useful even on NTFS (it is somehow related to execute permission and\n>>>open files. I still cannot figure out how exactly are they related).\n>>\n>>Again, it's not clear if you're talking about Windows or Cygwin but\n>>under Cygwin, in the default configuration, the exec attribute means\n>>the same thing to cygwin as it does to linux.\n>\n>I don't know about native Windows speed, but comparing NutCracker with\n>Cygwin on a simple 'find . | wc -l' already gives a clue that looking\n>at Cygwin to benchmark NT file inspection IO will give a skewed\n>picture:\n>\n>##### NutCracker $ time find . | wc -l\n>\n>real 0m 1.44s\n>user 0m 0.45s\n>sys 0m 0.98s\n>25794\n>\n>##### Cygwin $ time c:\\\\cygwin\\\\bin\\\\find . | wc -l\n>\n>real 0m 6.72s\n>user 0m 1.09s\n>sys 0m 5.59s\n>25794\n>\n>##### CMD.EXE + DIR /S C:\\PROJECT> c:\\cygwin\\bin\\time cmd /c dir /s\n>>NUL 0.01user 0.01system 0:05.70elapsed 0%CPU (0avgtext+0avgdata\n>6320maxresident)k 0inputs+0outputs (395major+0minor)pagefaults 0swaps\n>\n>##### Cygwin 'find -ls' (NutCracker doesn't have a '-ls') C:\\PROJECT>\n>c:\\cygwin\\bin\\time c:\\cygwin\\bin\\find -ls | wc -l 2.79user 7.81system\n>0:10.60elapsed 100%CPU (0avgtext+0avgdata 14480maxresident)k 25794\n\nI'm lost. What does this have to do with the exec attribute?\n\nOr, were you just climbing aboard the \"Cygwin sure is slow\" bandwagon?\n\ncgf\n"},{"id":"16801","messageId":"4402C40D.2010805@op5.se","threadId":"3405","inReplyTo":"20060226231701.GA11961@nospam.com","subject":"Re: NT directory traversal speed on 25K files on Cygwin","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-27T09:19:09Z","receivedAt":"2006-02-27T09:19:09Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Rutger Nijlunsing wrote:\n> On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:\n> \n>>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:\n>>\n>>>filesystem is slow and locked down, and exec-attribute is NOT really\n>>>useful even on NTFS (it is somehow related to execute permission and\n>>>open files. I still cannot figure out how exactly are they related).\n>>\n>>Again, it's not clear if you're talking about Windows or Cygwin but\n>>under Cygwin, in the default configuration, the exec attribute means the\n>>same thing to cygwin as it does to linux.\n> \n> \n> I don't know about native Windows speed, but comparing NutCracker with\n> Cygwin on a simple 'find . | wc -l' already gives a clue that looking\n> at Cygwin to benchmark NT file inspection IO will give a skewed\n> picture:\n> \n\nWell, naturally. Cygwin is a userland implementation of a sane \nfilesystem on top of a less sane one. File IO is bound to be slower when \none FS is emulated on top of another. I think cygwin users are aware of \nthis and simply accept the speed-for-sanity tradeoff. I know I would.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16839","messageId":"20060227183049.GA13195@nospam.com","threadId":"3405","inReplyTo":"20060227011801.GB9264@trixie.casa.cgf.cx","subject":"Re: NT directory traversal speed on 25K files on Cygwin","fromName":"Rutger Nijlunsing","fromEmail":"rutger@nospam.com","sentAt":"2006-02-27T18:30:49Z","receivedAt":"2006-02-27T18:30:49Z","isPatch":false,"sender":{"key":"rutger.nijlunsing@gmail.com","avatar":null},"body":"On Sun, Feb 26, 2006 at 08:18:01PM -0500, Christopher Faylor wrote:\n> On Mon, Feb 27, 2006 at 12:17:01AM +0100, Rutger Nijlunsing wrote:\n> >On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:\n> >>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:\n> >>>filesystem is slow and locked down, and exec-attribute is NOT really\n> >>>useful even on NTFS (it is somehow related to execute permission and\n> >>>open files. I still cannot figure out how exactly are they related).\n> >>\n> >>Again, it's not clear if you're talking about Windows or Cygwin but\n> >>under Cygwin, in the default configuration, the exec attribute means\n> >>the same thing to cygwin as it does to linux.\n> >\n> >I don't know about native Windows speed, but comparing NutCracker with\n> >Cygwin on a simple 'find . | wc -l' already gives a clue that looking\n> >at Cygwin to benchmark NT file inspection IO will give a skewed\n> >picture:\n> >\n> >##### NutCracker $ time find . | wc -l\n> >\n> >real 0m 1.44s\n> >user 0m 0.45s\n> >sys 0m 0.98s\n> >25794\n> >\n> >##### Cygwin $ time c:\\\\cygwin\\\\bin\\\\find . | wc -l\n> >\n> >real 0m 6.72s\n> >user 0m 1.09s\n> >sys 0m 5.59s\n> >25794\n> >\n> >##### CMD.EXE + DIR /S C:\\PROJECT> c:\\cygwin\\bin\\time cmd /c dir /s\n> >>NUL 0.01user 0.01system 0:05.70elapsed 0%CPU (0avgtext+0avgdata\n> >6320maxresident)k 0inputs+0outputs (395major+0minor)pagefaults 0swaps\n> >\n> >##### Cygwin 'find -ls' (NutCracker doesn't have a '-ls') C:\\PROJECT>\n> >c:\\cygwin\\bin\\time c:\\cygwin\\bin\\find -ls | wc -l 2.79user 7.81system\n> >0:10.60elapsed 100%CPU (0avgtext+0avgdata 14480maxresident)k 25794\n> \n> I'm lost. What does this have to do with the exec attribute?\n> \n> Or, were you just climbing aboard the \"Cygwin sure is slow\" bandwagon?\n\nI tried to get on the bandwagon 'NT file IO magnitudes slower => git\nmagnitudes slower', but missed the parade a week ago. Then another\nparade showed up, but I managed to delete most of it with a\nmisfortunate shift-something in mutt... And then even messed up in\nkeeping the wrong paragraph... *hmpf*\n\nHowever, the point I was trying to make was that git might be sped up\nby a magnitude (although not all of the magnitudes in comparison to\nLinux) by looking at why the file IO is this slow: Windows' file IO is\n_not_ the only reason. Using a different/new/better fitted interface\nto Cygwin or Win32 for a specific git task might help, although I have\nno clue what or how.\n\n-- \nRutger Nijlunsing ---------------------------------- eludias ed dse.nl\nnever attribute to a conspiracy which can be explained by incompetence\n----------------------------------------------------------------------\n"},{"id":"16840","messageId":"20060227183417.GA17978@trixie.casa.cgf.cx","threadId":"3405","inReplyTo":"20060227183049.GA13195@nospam.com","subject":"Re: NT directory traversal speed on 25K files on Cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-02-27T18:34:17Z","receivedAt":"2006-02-27T18:34:17Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Mon, Feb 27, 2006 at 07:30:49PM +0100, Rutger Nijlunsing wrote:\n>However, the point I was trying to make was that git might be sped up\n>by a magnitude (although not all of the magnitudes in comparison to\n>Linux) by looking at why the file IO is this slow: Windows' file IO is\n>_not_ the only reason. Using a different/new/better fitted interface\n>to Cygwin or Win32 for a specific git task might help, although I have\n>no clue what or how.\n\nI'm going to revisit Cygwin's file I/O soon to see if I can figure out\nwhat's adding the overhead and see if it really is inavoidable. It's\nbeen a while since I've gone through that exercise so it should prove\ninstructive.\n\ncgf\n"},{"id":"16842","messageId":"20060227184544.GB13195@nospam.com","threadId":"3405","inReplyTo":"4402C40D.2010805@op5.se","subject":"Re: NT directory traversal speed on 25K files on Cygwin","fromName":"Rutger Nijlunsing","fromEmail":"rutger@nospam.com","sentAt":"2006-02-27T18:45:44Z","receivedAt":"2006-02-27T18:45:44Z","isPatch":false,"sender":{"key":"rutger.nijlunsing@gmail.com","avatar":null},"body":"On Mon, Feb 27, 2006 at 10:19:09AM +0100, Andreas Ericsson wrote:\n> Rutger Nijlunsing wrote:\n> >On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:\n> >\n> >>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:\n> >>\n> >>>filesystem is slow and locked down, and exec-attribute is NOT really\n> >>>useful even on NTFS (it is somehow related to execute permission and\n> >>>open files. I still cannot figure out how exactly are they related).\n> >>\n> >>Again, it's not clear if you're talking about Windows or Cygwin but\n> >>under Cygwin, in the default configuration, the exec attribute means the\n> >>same thing to cygwin as it does to linux.\n> >\n> >\n> >I don't know about native Windows speed, but comparing NutCracker with\n> >Cygwin on a simple 'find . | wc -l' already gives a clue that looking\n> >at Cygwin to benchmark NT file inspection IO will give a skewed\n> >picture:\n> >\n> \n> Well, naturally. Cygwin is a userland implementation of a sane \n> filesystem on top of a less sane one. File IO is bound to be slower when \n> one FS is emulated on top of another. I think cygwin users are aware of \n> this and simply accept the speed-for-sanity tradeoff. I know I would.\n\nMKS NutCracker tries to solve the same issues as Cygwin tries to\nsolve. But maybe less sane, I don't know. But a simple 'find' is\nseveral times faster than a Cygwin 'find'. Yes, very\nunscientific. Just as unscientific as 'git is slow on Windows,\ntherefore Windows IO is slow'.\n\nI'm not saying Cygwin is bad (actually, I'm installing on every\nWindows PC I get my hand on ;), but using Cygwin for all file IO\ninstead of native Windows IO makes git a magnitude slower on Windows\nthan could-be. So a small portability layer with a function like\n'given all filenames with all mtimes' might help, or we could look at\nwhy Cygwin is slower in this case. Alas my Windows profiling skills\naren't that good...\n\nRegards,\nRutger.\n\n-- \nRutger Nijlunsing ---------------------------------- eludias ed dse.nl\nnever attribute to a conspiracy which can be explained by incompetence\n----------------------------------------------------------------------\n"},{"id":"17033","messageId":"81b0412b0603020540uf58c2c3x7fc8b3b086444803@mail.gmail.com","threadId":"3405","inReplyTo":"20060227184544.GB13195@nospam.com","subject":"Re: NT directory traversal speed on 25K files on Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-03-02T13:40:04Z","receivedAt":"2006-03-02T13:40:04Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/27/06, Rutger Nijlunsing wrote:\n> I'm not saying Cygwin is bad (actually, I'm installing on every\n> Windows PC I get my hand on ;), but using Cygwin for all file IO\n> instead of native Windows IO makes git a magnitude slower on Windows\n\nBy \"slow filesystem\" I actually meant the native filesystem access.\nCygwin does make it 6 times slower, that's right, and this can be\nconsidered a disaster of course, but not as big as the windows api.\n"},{"id":"17036","messageId":"81b0412b0603020610q41d0ec98x80d112b7daa179fa@mail.gmail.com","threadId":"3405","inReplyTo":"20060226195552.GA30735@trixie.casa.cgf.cx","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-03-02T14:10:30Z","receivedAt":"2006-03-02T14:10:30Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Christopher, I'm terribly sorry for the long delays,\nbut that is something I can't change at this moment.\n\nOn 2/26/06, Christopher Faylor wrote:\n> >>>It's not activestate perl actually. It's only one platform it also\n> >>>_has_ to support. Is it worth supporting Windows?\n> >>\n> >>With or without cygwin? With cygwin, I'd say \"yes, unless it makes\n> >>things terribly difficult to maintain and so long as we don't take\n> >>performance hits on unices\". Without cygwin, I'd say \"What? It runs\n> >>on windows?\".\n> >\n> >There not much difference with or without cygwin. The penalties of\n> >doing any kind of support for it will pile up (as they started to do\n> >with pipes). Someday we'll have to start dropping features on Windows\n> >or restrict them beyond their usefullness. The fork emulation in\n> >cygwin isn't perfect,\n>\n> If the speed of cygwin's fork is an issue then I'd previously suggested\n> using spawn*. The spawn family of functions were designed to emulate\n> Windows functions of the same name. They start a new process without\n> the requirement of forking.\n\nThe effort of porting git to spawn-like interface has already started,\nso there's no much left to say about the fork's speed...\n\n> >signals do not work reliably (if at all),\n>\n> I'm not sure if you're mixing cygwin with windows here but if signals do\n> not work reliably in Cygwin then that is something that we'd like to\n> know about. Signals *obviously* have to work fairly well for programs\n> like ssh, bash, and X to work, however.\n\nThat's not enough.\nTry interrupting busy processes. Like \"git pull\", \"git clone\" or make.\n\n> Native Windows, OTOH, hardly has any signals at all and deals with\n> signals in a way that is only vaguely like linux.\n\nThat makes the rest of installed system kind of useless in cygwin\nenvironment. After interrupting a build process, which uses java\n(don't ask) only make stops. The rest of the process runs happily\naway.\n\nNow, I know that windows has no signals at all and nothing which\neven closely resembles them. I wont be pressing anyone to\nimplement them in windows, having the knowledge.\nWhat I'd actually suggest is to drop their implementation entierly,\nreturning ENOSYS, so that programs are not fooled into believing\nthat the system will work as expected. It never will.\n\"Ctrl-C\" in windows console is just a shortcut to TerminateProcess,\nlive with that.\n\n> >filesystem is slow and locked down, and exec-attribute is NOT really\n> >useful even on NTFS (it is somehow related to execute permission and\n> >open files. I still cannot figure out how exactly are they related).\n>\n> Again, it's not clear if you're talking about Windows or Cygwin but\n> under Cygwin, in the default configuration, the exec attribute means the\n> same thing to cygwin as it does to linux.\n\nI'm talking about git and native windows interaction: I cannot use umask,\nbecause I have to use stupid windows programs, and they always create\n\"executable\" *.c and *.h, and I cannot blindly remove it with something\nlike \"chmod -R -x\", because it'd remove it also from executables. The\npoor executables lose their _rights_ to be executed (why does cygwin use\nwindows permissions? They cannot correlate to unix attributes, can they?)\nAn .bat or .cmd without right to execute it is a pain in my build system\n(and no, I'm not allowed to change that damn stupid build system).\n\nIs there any way to tell cygwin that the files it hasn't seen or touched yet\nare _not_executables_?\n"},{"id":"17037","messageId":"81b0412b0603020618q3b205cdeuabc7e204044cca5b@mail.gmail.com","threadId":"3405","inReplyTo":"20060226204027.GC30735@trixie.casa.cgf.cx","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-03-02T14:18:44Z","receivedAt":"2006-03-02T14:18:44Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/26/06, Christopher Faylor wrote:\n> The cygwin/windows version of spawn is basically like an extended version\n> of exec*():\n>\n> pid = spawnlp (P_NOWAIT, \"/bin/ls\", \"ls\", \"-l\", NULL);\n>\n\nBy the way, is argv worked around?\nAFAIK, windows has only one argument, returned by GetCommandLine?\n"},{"id":"17039","messageId":"20060302150016.GC2781@trixie.casa.cgf.cx","threadId":"3405","inReplyTo":"81b0412b0603020610q41d0ec98x80d112b7daa179fa@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-03-02T15:00:16Z","receivedAt":"2006-03-02T15:00:16Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Mar 02, 2006 at 03:10:30PM +0100, Alex Riesen wrote:\n>Christopher, I'm terribly sorry for the long delays,\n>but that is something I can't change at this moment.\n>\n>On 2/26/06, Christopher Faylor wrote:\n>> >>>It's not activestate perl actually. It's only one platform it also\n>> >>>_has_ to support. Is it worth supporting Windows?\n>> >>\n>> >>With or without cygwin? With cygwin, I'd say \"yes, unless it makes\n>> >>things terribly difficult to maintain and so long as we don't take\n>> >>performance hits on unices\". Without cygwin, I'd say \"What? It runs\n>> >>on windows?\".\n>> >\n>> >There not much difference with or without cygwin. The penalties of\n>> >doing any kind of support for it will pile up (as they started to do\n>> >with pipes). Someday we'll have to start dropping features on Windows\n>> >or restrict them beyond their usefullness. The fork emulation in\n>> >cygwin isn't perfect,\n>>\n>> If the speed of cygwin's fork is an issue then I'd previously suggested\n>> using spawn*. The spawn family of functions were designed to emulate\n>> Windows functions of the same name. They start a new process without\n>> the requirement of forking.\n>\n>The effort of porting git to spawn-like interface has already started,\n>so there's no much left to say about the fork's speed...\n>\n>> >signals do not work reliably (if at all),\n>>\n>> I'm not sure if you're mixing cygwin with windows here but if signals do\n>> not work reliably in Cygwin then that is something that we'd like to\n>> know about. Signals *obviously* have to work fairly well for programs\n>> like ssh, bash, and X to work, however.\n>\n>That's not enough.\n>Try interrupting busy processes. Like \"git pull\", \"git clone\" or make.\n\nAre you saying that typing CTRL-C doesn't work when you use \"git pull\"?\nIf so, give me a real bug report that I can look into. I interrupt\n\"busy\" processes on cygwin all of the time so I'm not going to spend a\nfew hours typing \"git pull\" on my system only to find out that you are\ntalking about an environment that uses ActiveState perl on Windows 95\nusing Netware.\n\nIf you are reporting a problem you need to provide details.\n\n>> Native Windows, OTOH, hardly has any signals at all and deals with\n>> signals in a way that is only vaguely like linux.\n>\n>That makes the rest of installed system kind of useless in cygwin\n>environment. After interrupting a build process, which uses java\n>(don't ask) only make stops. The rest of the process runs happily\n>away.\n\nThis sounds like a java bug which is entirely unrelated to git.\n\n>Now, I know that windows has no signals at all and nothing which\n>even closely resembles them.\n\nActually, Windows does understand CTRL-C and any native windows console\nprogram should honor CTRL-C in a manner similar to UNIX, i.e., if the\nprogram doesn't trap SIGINT with 'signal()', it will cause the program\nto terminate. There are also other mechanisms for a native windows\nprogram to deal with CTRL-C so this really shouldn't be an issue for\nany well-written program.\n\n>I wont be pressing anyone to implement them in windows, having the\n>knowledge. What I'd actually suggest is to drop their implementation\n>entierly, returning ENOSYS,\n\nYou're not being clear again, but if you are actually promoting the\nnotion of cygwin not implementing signals then that is a really daft\nidea. Really. Go to the Cygwin web site and look at all of the\npackages which have been ported. Now think about how they would work if\nCygwin didn't support signals. bash wouldn't work, openssh, X wouldn't\nwork.\n\n>so that programs are not fooled into believing that the system will\n>work as expected. It never will. \"Ctrl-C\" in windows console is just\n>a shortcut to TerminateProcess, live with that.\n\nLet me say it again since it isn't clear that you are getting it. If\nsignals in a pure cygwin environment don't work then that is *a bug*.\nIf you are running pure windows programs in the mix with cygwin programs\nthen if *they* don't stop when you hit CTRL-C, that is undoubtedly a bug\nin that pure windows program.\n\nIf you find that a pure windows program terminates when run from a\nwindows command prompt but keeps running when run by a cygwin program\nthen that is likely a cygwin problem that can be reported to the cygwin\nmailing list.\n\n>>>filesystem is slow and locked down, and exec-attribute is NOT really\n>>>useful even on NTFS (it is somehow related to execute permission and\n>>>open files. I still cannot figure out how exactly are they related).\n>>\n>>Again, it's not clear if you're talking about Windows or Cygwin but\n>>under Cygwin, in the default configuration, the exec attribute means\n>>the same thing to cygwin as it does to linux.\n>\n>I'm talking about git and native windows interaction:\n\nI'd suggest that using git with native windows programs should probably\nbe considered \"unsupported\" since you seem to be having so much trouble\nwith it.\n\n>I cannot use umask, because I have to use stupid windows programs, and\n>they always create \"executable\" *.c and *.h, and I cannot blindly\n>remove it with something like \"chmod -R -x\", because it'd remove it\n>also from executables.\n\n find . -name '*.[ch]' | xargs chmod a-x\n\n>The poor executables lose their _rights_ to be executed (why does\n>cygwin use windows permissions? They cannot correlate to unix\n>attributes, can they?)\n\nPlease read the Cygwin user's guide for a discussion about how file\npermissions are implemented. And, then, when you are outraged about how\nunclear that documentation is please send comments and improvements to\nthe cygwin mailing list.\n\nI don't see why it is appropriate to be discussing how Cygwin implements\nUNIX permissions in this mailing list unless the implementation affects\ngit somehow.\n\ncgf\n"},{"id":"17040","messageId":"slrne0e36r.fr9.mdw@metalzone.distorted.org.uk","threadId":"3405","inReplyTo":"81b0412b0603020618q3b205cdeuabc7e204044cca5b@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Mark Wooding","fromEmail":"mdw@distorted.org.uk","sentAt":"2006-03-02T15:18:51Z","receivedAt":"2006-03-02T15:18:51Z","isPatch":true,"sender":{"key":"mdw@distorted.org.uk","avatar":null},"body":"\"Alex Riesen\" wrote:\n\n> AFAIK, windows has only one argument, returned by GetCommandLine?\n\nThis is true, but there's a standard quoting convention which (in\nparticular) Microsoft's C library uses to split the single argument back\ninto an argv. The spawn* functions quote; the C library startup stuff\nunquotes and splits.\n\nThe actual quoting convention is /horrible/. I had to implement the\ndarned thing once. See\n\n http://sources.redhat.com/ml/cygwin/1999-08/msg00701.html\n\nfor the details.\n\n-- [mdw]\n"},{"id":"17042","messageId":"20060302152219.GG2781@trixie.casa.cgf.cx","threadId":"3405","inReplyTo":"81b0412b0603020618q3b205cdeuabc7e204044cca5b@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-03-02T15:22:19Z","receivedAt":"2006-03-02T15:22:19Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Mar 02, 2006 at 03:18:44PM +0100, Alex Riesen wrote:\n>On 2/26/06, Christopher Faylor wrote:\n>> The cygwin/windows version of spawn is basically like an extended version\n>> of exec*():\n>>\n>> pid = spawnlp (P_NOWAIT, \"/bin/ls\", \"ls\", \"-l\", NULL);\n>>\n>\n>By the way, is argv worked around?\n>AFAIK, windows has only one argument, returned by GetCommandLine?\n\nCygwin passes an argv list between cygwin processes and a quoted command\nline to pure windows processes.\n\ncgf\n"},{"id":"17051","messageId":"81b0412b0603020810l57f9ee5p270f9c288770d1a7@mail.gmail.com","threadId":"3405","inReplyTo":"20060302150016.GC2781@trixie.casa.cgf.cx","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-03-02T16:10:22Z","receivedAt":"2006-03-02T16:10:22Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/2/06, Christopher Faylor wrote:\n> >That's not enough.\n> >Try interrupting busy processes. Like \"git pull\", \"git clone\" or make.\n>\n> Are you saying that typing CTRL-C doesn't work when you use \"git pull\"?\n\nIt does. Almost always. It's the seldom cases when this does not\nreally work which annoy me that much.\n\n> If so, give me a real bug report that I can look into. I interrupt\n> \"busy\" processes on cygwin all of the time so I'm not going to spend a\n> few hours typing \"git pull\" on my system only to find out that you are\n> talking about an environment that uses ActiveState perl on Windows 95\n> using Netware.\n\nwell, it is almost exactly the case: WinNT 2K. And I cannot change this.\n\n> If you are reporting a problem you need to provide details.\n\nI am NOT reporting a problem. Everyone knows there are these problems,\nit's just almost no one (including me) cares enough about getting anything\nto work sanely on windows.\n\nPlease, stop assuming that every my complaint is a bug report about\ncygwin. It is not. You can use my mails as you please, even as bug reports.\nIf you ask nicely, I can provide more details maybe. But I am not asking\nYOU for anything, and not complaining to YOU about anything.\n\nI _do_not_ like how Cygwin workarounds windows, but I respect the\neffort and understand why it happens. Still, I'd prefer it die. I'll try to\nkeep it moving, but no farther than needed and only when I really have to.\n\n> There are also other mechanisms for a native windows\n> program to deal with CTRL-C so this really shouldn't be an issue for\n> any well-written program.\n\nIn windows you have to do hell of a lot useless typing to write what you\nconsider a \"well-written program\".\n\n> >I wont be pressing anyone to implement them in windows, having the\n> >knowledge. What I'd actually suggest is to drop their implementation\n> >entierly, returning ENOSYS,\n>\n> You're not being clear again, but if you are actually promoting the\n> notion of cygwin not implementing signals then that is a really daft\n> idea. Really. Go to the Cygwin web site and look at all of the\n> packages which have been ported. Now think about how they would work if\n> Cygwin didn't support signals. bash wouldn't work, openssh, X wouldn't\n> work.\n\nThat's right. They are not _ported_. I'm not interested in xterm which\nprints page in a minute.\n\n> >so that programs are not fooled into believing that the system will\n> >work as expected. It never will. \"Ctrl-C\" in windows console is just\n> >a shortcut to TerminateProcess, live with that.\n>\n> Let me say it again since it isn't clear that you are getting it. If\n> signals in a pure cygwin environment don't work then that is *a bug*.\n\nWhatever you say. I never expected them to, personally.\n\n> If you are running pure windows programs in the mix with cygwin programs\n> then if *they* don't stop when you hit CTRL-C, that is undoubtedly a bug\n> in that pure windows program.\n\nMaybe. I wouldn't blame that poor windows programmer though: it's hard,\nboring and in 99.9999% of starts of that program - dead code.\n\n> If you find that a pure windows program terminates when run from a\n> windows command prompt but keeps running when run by a cygwin program\n> then that is likely a cygwin problem that can be reported to the cygwin\n> mailing list.\n\ngui applications detach from cmd (not from cygwin console),\nso that kind of pointless exercise.\n\n> I'd suggest that using git with native windows programs should probably\n> be considered \"unsupported\" since you seem to be having so much trouble\n> with it.\n\nI'd suggest calling cygwin ports unsupported.\n\n> >I cannot use umask, because I have to use stupid windows programs, and\n> >they always create \"executable\" *.c and *.h, and I cannot blindly\n> >remove it with something like \"chmod -R -x\", because it'd remove it\n> >also from executables.\n>\n> find . -name '*.[ch]' | xargs chmod a-x\n\nfind . -name '*.[ch]' -o -name '*.[ch]pp' -o -name Makefile -o -name\n'*.txt' -o ...ooh! damn it^C -print0| xargs -0 chmod -x\nYou oversimplifying.\n"},{"id":"17052","messageId":"81b0412b0603020811r37edca03wde5562b926dab549@mail.gmail.com","threadId":"3405","inReplyTo":"slrne0e36r.fr9.mdw@metalzone.distorted.org.uk","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-03-02T16:11:37Z","receivedAt":"2006-03-02T16:11:37Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/2/06, Mark Wooding wrote:\n>\n> > AFAIK, windows has only one argument, returned by GetCommandLine?\n>\n> This is true, but there's a standard quoting convention which (in\n> particular) Microsoft's C library uses to split the single argument back\n> into an argv. The spawn* functions quote; the C library startup stuff\n> unquotes and splits.\n\nDoesn't for programs using WinMain, which is probably 90% of all\nwindows programs.\n"},{"id":"17053","messageId":"81b0412b0603020820j4b71057ay8e7c1e168d5cc4@mail.gmail.com","threadId":"3405","inReplyTo":"20060302152219.GG2781@trixie.casa.cgf.cx","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-03-02T16:20:33Z","receivedAt":"2006-03-02T16:20:33Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/2/06, Christopher Faylor wrote:\n> >> The cygwin/windows version of spawn is basically like an extended version\n> >> of exec*():\n> >>\n> >> pid = spawnlp (P_NOWAIT, \"/bin/ls\", \"ls\", \"-l\", NULL);\n> >>\n> >\n> >By the way, is argv worked around?\n> >AFAIK, windows has only one argument, returned by GetCommandLine?\n>\n> Cygwin passes an argv list between cygwin processes and a quoted command\n> line to pure windows processes.\n\nWhat for? They can't use it anyway.\n\n$ notepad '\"abc\"'\n"},{"id":"17064","messageId":"44072DEF.1070906@op5.se","threadId":"3405","inReplyTo":"81b0412b0603020810l57f9ee5p270f9c288770d1a7@mail.gmail.com","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-02T17:39:59Z","receivedAt":"2006-03-02T17:39:59Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Ye gawds, Alex. If you complained this much to your employer you'd get \nto run whatever OS you want.\n\nAlex Riesen wrote:\n\n[ lots of things ]\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"17074","messageId":"20060302220113.GD6183@steel.home","threadId":"3405","inReplyTo":"44072DEF.1070906@op5.se","subject":"Re: [PATCH] fmt-merge-msg: avoid open \"-|\" list form for Perl 5.6","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-03-02T22:01:13Z","receivedAt":"2006-03-02T22:01:13Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Andreas Ericsson, Thu, Mar 02, 2006 18:39:59 +0100:\n> Ye gawds, Alex. If you complained this much to your employer you'd get \n> to run whatever OS you want.\n\nI never stopped. I usually manage to convince them, it just hasn't\nhappened here yet.\n"}]}