{"thread":{"id":"36137","subject":"New GSoC microproject ideas","startedAt":"2014-03-12T11:48:55Z","lastAt":"2014-03-13T17:06:39Z","messageCount":8,"participants":["Michael Haggerty","Junio C Hamano","David Kastrup","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"236572","messageId":"532049A7.6000304@alum.mit.edu","threadId":"36137","inReplyTo":null,"subject":"New GSoC microproject ideas","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-03-12T11:48:55Z","receivedAt":"2014-03-12T11:48:55Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Hi,\n\nI just added a few microproject suggestions to the list for\nnewly-arriving students [1].  A couple of them are weak, but I think\nnumber 17 has enough aspects to keep a whole crew of students busy for a\nwhile.\n\nMichael\n\n[1] http://git.github.io/SoC-2014-Microprojects.html\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"236604","messageId":"xmqq1ty7me6a.fsf@gitster.dls.corp.google.com","threadId":"36137","inReplyTo":"532049A7.6000304@alum.mit.edu","subject":"Re: New GSoC microproject ideas","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-12T19:04:29Z","receivedAt":"2014-03-12T19:04:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here is another, as I seem to have managed to kill another one ;-)\n\n-- >8 --\n\n\"VAR=VAL command\" is sufficient to run 'command' with environment\nvariable VAR set to value VAL without affecting the environment of\nthe shell itself, but we cannot do the same with a shell function\n(most notably, \"test_must_fail\"); we have subshell invocations with\nmultiple lines like this:\n\n\t... &&\n\t(\n        \tVAR=VAL &&\n                export VAR &&\n                test_must_fail git command\n\t) &&\n        ...\n\nbut that could be expressed as\n\n\t... &&\n        test_must_fail env VAR=VAL git comand &&\n\t...\n\nFind and shorten such constructs in existing test scripts.\n"},{"id":"236605","messageId":"87wqfzi5wa.fsf@fencepost.gnu.org","threadId":"36137","inReplyTo":"xmqq1ty7me6a.fsf@gitster.dls.corp.google.com","subject":"Re: New GSoC microproject ideas","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-03-12T19:16:53Z","receivedAt":"2014-03-12T19:16:53Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Here is another, as I seem to have managed to kill another one ;-)\n>\n> -- >8 --\n>\n> \"VAR=VAL command\" is sufficient to run 'command' with environment\n> variable VAR set to value VAL without affecting the environment of\n> the shell itself, but we cannot do the same with a shell function\n> (most notably, \"test_must_fail\");\n\nNo? bash:\n\ndak@lola:/usr/local/tmp/lilypond$ zippo()\n> {\n> echo $XXX\n> echo $XXX\n> }\ndak@lola:/usr/local/tmp/lilypond$ XXX=8 zippo\n8\n8\n\n\ndak@lola:/usr/local/tmp/lilypond$ /bin/dash\n$ zippo()\n> {\n> echo $XXX\n> echo $XXX\n> }\n$ XXX=8 zippo\n8\n8\n$ \n\ndak@lola:/usr/local/tmp/lilypond$ /bin/ash\n$ zippo()\n> {\n> echo $XXX\n> echo $XXX\n> }\n$ XXX=8 zippo\n8\n8\n$ \n\n\nSeems to work just fine with a set of typical shells.\n\n-- \nDavid Kastrup\n"},{"id":"236606","messageId":"20140312192108.GA1601@sigill.intra.peff.net","threadId":"36137","inReplyTo":"87wqfzi5wa.fsf@fencepost.gnu.org","subject":"Re: New GSoC microproject ideas","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-03-12T19:21:08Z","receivedAt":"2014-03-12T19:21:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 12, 2014 at 08:16:53PM +0100, David Kastrup wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> > Here is another, as I seem to have managed to kill another one ;-)\n> >\n> > -- >8 --\n> >\n> > \"VAR=VAL command\" is sufficient to run 'command' with environment\n> > variable VAR set to value VAL without affecting the environment of\n> > the shell itself, but we cannot do the same with a shell function\n> > (most notably, \"test_must_fail\");\n> \n> No? bash:\n> \n> dak@lola:/usr/local/tmp/lilypond$ zippo()\n> > {\n> > echo $XXX\n> > echo $XXX\n> > }\n> dak@lola:/usr/local/tmp/lilypond$ XXX=8 zippo\n> 8\n> 8\n\nTry:\n\n  zippo() {\n    echo $XXX\n  }\n  XXX=8 zippo\n  zippo\n\nXXX remains set after the first call under dash (but not bash). I\nbelieve \"ash\" has the same behavior.\n\n-Peff\n"},{"id":"236626","messageId":"87siqni25m.fsf@fencepost.gnu.org","threadId":"36137","inReplyTo":"20140312192108.GA1601@sigill.intra.peff.net","subject":"Re: New GSoC microproject ideas","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-03-12T20:37:41Z","receivedAt":"2014-03-12T20:37:41Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Mar 12, 2014 at 08:16:53PM +0100, David Kastrup wrote:\n>\n>> Junio C Hamano <gitster@pobox.com> writes:\n>> \n>> > Here is another, as I seem to have managed to kill another one ;-)\n>> >\n>> > -- >8 --\n>> >\n>> > \"VAR=VAL command\" is sufficient to run 'command' with environment\n>> > variable VAR set to value VAL without affecting the environment of\n>> > the shell itself, but we cannot do the same with a shell function\n>> > (most notably, \"test_must_fail\");\n>> \n>> No? bash:\n>> \n>> dak@lola:/usr/local/tmp/lilypond$ zippo()\n>> > {\n>> > echo $XXX\n>> > echo $XXX\n>> > }\n>> dak@lola:/usr/local/tmp/lilypond$ XXX=8 zippo\n>> 8\n>> 8\n>\n> Try:\n>\n>   zippo() {\n>     echo $XXX\n>   }\n>   XXX=8 zippo\n>   zippo\n>\n> XXX remains set after the first call under dash (but not bash). I\n> believe \"ash\" has the same behavior.\n\nYes.  I would lean towards considering this a bug.  But I agree that it\ndoes not help.\n\n-- \nDavid Kastrup\n"},{"id":"236628","messageId":"20140312204453.GA9702@sigill.intra.peff.net","threadId":"36137","inReplyTo":"87siqni25m.fsf@fencepost.gnu.org","subject":"Re: New GSoC microproject ideas","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-03-12T20:44:53Z","receivedAt":"2014-03-12T20:44:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 12, 2014 at 09:37:41PM +0100, David Kastrup wrote:\n\n> > Try:\n> >\n> >   zippo() {\n> >     echo $XXX\n> >   }\n> >   XXX=8 zippo\n> >   zippo\n> >\n> > XXX remains set after the first call under dash (but not bash). I\n> > believe \"ash\" has the same behavior.\n> \n> Yes.  I would lean towards considering this a bug.  But I agree that it\n> does not help.\n\nDash's behavior is POSIX (and \"bash --posix\" behaves the same way).\n\n  http://article.gmane.org/gmane.comp.version-control.git/137095\n\n-Peff\n"},{"id":"236631","messageId":"87k3bzi0j4.fsf@fencepost.gnu.org","threadId":"36137","inReplyTo":"20140312204453.GA9702@sigill.intra.peff.net","subject":"Re: New GSoC microproject ideas","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-03-12T21:12:47Z","receivedAt":"2014-03-12T21:12:47Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Mar 12, 2014 at 09:37:41PM +0100, David Kastrup wrote:\n>\n>> > Try:\n>> >\n>> >   zippo() {\n>> >     echo $XXX\n>> >   }\n>> >   XXX=8 zippo\n>> >   zippo\n>> >\n>> > XXX remains set after the first call under dash (but not bash). I\n>> > believe \"ash\" has the same behavior.\n>> \n>> Yes.  I would lean towards considering this a bug.  But I agree that it\n>> does not help.\n>\n> Dash's behavior is POSIX (and \"bash --posix\" behaves the same way).\n>\n>   http://article.gmane.org/gmane.comp.version-control.git/137095\n\nIn that case I consider it a standard-compliant bug (namely being a\nserious problem regarding the usefulness of shell functions).  Which\nmakes it unlikely to go away.  It makes it easier to interpret, say\n\nzippo() {\n  XXX=$XXX\n}\n\nXXX=8 zippo\necho $XXX\n\nas shell functions presumably should be able to assign to shell\nvariables like built-ins do.  But that's not really much of an\nadvantage.\n\nThe behavior does not make sense to me also with regard to special\nbuilt-ins.  Bash does\n\ndak@lola:/usr/local/tmp/git$ XXX=8 :\ndak@lola:/usr/local/tmp/git$ echo $XXX\n\ndak@lola:/usr/local/tmp/git$ \n\nAnd that makes sense to me.  Whatever, does not help.\n\n-- \nDavid Kastrup\n"},{"id":"236672","messageId":"5321E59F.8020003@alum.mit.edu","threadId":"36137","inReplyTo":"xmqq1ty7me6a.fsf@gitster.dls.corp.google.com","subject":"Re: New GSoC microproject ideas","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-03-13T17:06:39Z","receivedAt":"2014-03-13T17:06:39Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/12/2014 08:04 PM, Junio C Hamano wrote:\n> Here is another, as I seem to have managed to kill another one ;-)\n> \n> -- >8 --\n> \n> \"VAR=VAL command\" is sufficient to run 'command' with environment\n> variable VAR set to value VAL without affecting the environment of\n> the shell itself, but we cannot do the same with a shell function\n> (most notably, \"test_must_fail\"); we have subshell invocations with\n> multiple lines like this:\n> \n> \t... &&\n> \t(\n>         \tVAR=VAL &&\n>                 export VAR &&\n>                 test_must_fail git command\n> \t) &&\n>         ...\n> \n> but that could be expressed as\n> \n> \t... &&\n>         test_must_fail env VAR=VAL git comand &&\n> \t...\n> \n> Find and shorten such constructs in existing test scripts.\n\nThanks; I just added it.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"}]}