threads / discuss / 36137

New GSoC microproject ideas

Subject: New GSoC microproject ideas

## tl;dr

8 messages between Mar 12, 2014 and Mar 13, 2014.

replies: 7people: 4as markdown or json

Michael Haggerty· Mar 12, 2014, 11:48 UTC · lore
Hi,

I just added a few microproject suggestions to the list for newly-arriving students [1]. A couple of them are weak, but I think number 17 has enough aspects to keep a whole crew of students busy for a while.

Michael
[1] http://git.github.io/SoC-2014-Microprojects.html
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Junio C Hamano· Mar 12, 2014, 19:04 UTC · re: Michael Haggerty · lore

Re: New GSoC microproject ideas

Here is another, as I seem to have managed to kill another one ;-)
-- >8 --

"VAR=VAL command" is sufficient to run 'command' with environment variable VAR set to value VAL without affecting the environment of the shell itself, but we cannot do the same with a shell function (most notably, "test_must_fail"); we have subshell invocations with multiple lines like this:

	... &&
	(
        	VAR=VAL &&
                export VAR &&
                test_must_fail git command
	) &&
        ...
but that could be expressed as
	... &&
        test_must_fail env VAR=VAL git comand &&
	...
Find and shorten such constructs in existing test scripts.
David Kastrup· Mar 12, 2014, 19:16 UTC · re: Junio C Hamano · lore

Re: New GSoC microproject ideas

Junio C Hamano <gitster@pobox.com> writes:
Show 8 quoted lines
> Here is another, as I seem to have managed to kill another one ;-)
>
> -- >8 --
>
> "VAR=VAL command" is sufficient to run 'command' with environment
> variable VAR set to value VAL without affecting the environment of
> the shell itself, but we cannot do the same with a shell function
> (most notably, "test_must_fail");
No? bash:
dak@lola:/usr/local/tmp/lilypond$ zippo()
> {
> echo $XXX
> echo $XXX
> }

dak@lola:/usr/local/tmp/lilypond$ XXX=8 zippo 8 8

dak@lola:/usr/local/tmp/lilypond$ /bin/dash $ zippo()

> {
> echo $XXX
> echo $XXX
> }

$ XXX=8 zippo 8 8 $

dak@lola:/usr/local/tmp/lilypond$ /bin/ash $ zippo()

> {
> echo $XXX
> echo $XXX
> }

$ XXX=8 zippo 8 8 $ 

Seems to work just fine with a set of typical shells.
-- 
David Kastrup
Jeff King· Mar 12, 2014, 19:21 UTC · re: David Kastrup · lore

Re: New GSoC microproject ideas

On Wed, Mar 12, 2014 at 08:16:53PM +0100, David Kastrup wrote:
Show 21 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Here is another, as I seem to have managed to kill another one ;-)
> >
> > -- >8 --
> >
> > "VAR=VAL command" is sufficient to run 'command' with environment
> > variable VAR set to value VAL without affecting the environment of
> > the shell itself, but we cannot do the same with a shell function
> > (most notably, "test_must_fail");
> 
> No? bash:
> 
> dak@lola:/usr/local/tmp/lilypond$ zippo()
> > {
> > echo $XXX
> > echo $XXX
> > }
> dak@lola:/usr/local/tmp/lilypond$ XXX=8 zippo
> 8
> 8
Try:
  zippo() {
    echo $XXX
  }
  XXX=8 zippo
  zippo

XXX remains set after the first call under dash (but not bash). I believe "ash" has the same behavior.

-Peff
David Kastrup· Mar 12, 2014, 20:37 UTC · re: Jeff King · lore

Re: New GSoC microproject ideas

Jeff King <peff@peff.net> writes:
Show 34 quoted lines
> On Wed, Mar 12, 2014 at 08:16:53PM +0100, David Kastrup wrote:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>> 
>> > Here is another, as I seem to have managed to kill another one ;-)
>> >
>> > -- >8 --
>> >
>> > "VAR=VAL command" is sufficient to run 'command' with environment
>> > variable VAR set to value VAL without affecting the environment of
>> > the shell itself, but we cannot do the same with a shell function
>> > (most notably, "test_must_fail");
>> 
>> No? bash:
>> 
>> dak@lola:/usr/local/tmp/lilypond$ zippo()
>> > {
>> > echo $XXX
>> > echo $XXX
>> > }
>> dak@lola:/usr/local/tmp/lilypond$ XXX=8 zippo
>> 8
>> 8
>
> Try:
>
>   zippo() {
>     echo $XXX
>   }
>   XXX=8 zippo
>   zippo
>
> XXX remains set after the first call under dash (but not bash). I
> believe "ash" has the same behavior.

Yes. I would lean towards considering this a bug. But I agree that it does not help.

-- 
David Kastrup
Jeff King· Mar 12, 2014, 20:44 UTC · re: David Kastrup · lore

Re: New GSoC microproject ideas

On Wed, Mar 12, 2014 at 09:37:41PM +0100, David Kastrup wrote:
Show 13 quoted lines
> > Try:
> >
> >   zippo() {
> >     echo $XXX
> >   }
> >   XXX=8 zippo
> >   zippo
> >
> > XXX remains set after the first call under dash (but not bash). I
> > believe "ash" has the same behavior.
> 
> Yes.  I would lean towards considering this a bug.  But I agree that it
> does not help.
Dash's behavior is POSIX (and "bash --posix" behaves the same way).
  http://article.gmane.org/gmane.comp.version-control.git/137095
-Peff
David Kastrup· Mar 12, 2014, 21:12 UTC · re: Jeff King · lore

Re: New GSoC microproject ideas

Jeff King <peff@peff.net> writes:
Show 19 quoted lines
> On Wed, Mar 12, 2014 at 09:37:41PM +0100, David Kastrup wrote:
>
>> > Try:
>> >
>> >   zippo() {
>> >     echo $XXX
>> >   }
>> >   XXX=8 zippo
>> >   zippo
>> >
>> > XXX remains set after the first call under dash (but not bash). I
>> > believe "ash" has the same behavior.
>> 
>> Yes.  I would lean towards considering this a bug.  But I agree that it
>> does not help.
>
> Dash's behavior is POSIX (and "bash --posix" behaves the same way).
>
>   http://article.gmane.org/gmane.comp.version-control.git/137095

In that case I consider it a standard-compliant bug (namely being a serious problem regarding the usefulness of shell functions). Which makes it unlikely to go away. It makes it easier to interpret, say

zippo() {
  XXX=$XXX
}

XXX=8 zippo echo $XXX

as shell functions presumably should be able to assign to shell variables like built-ins do. But that's not really much of an advantage.

The behavior does not make sense to me also with regard to special built-ins. Bash does

dak@lola:/usr/local/tmp/git$ XXX=8 : dak@lola:/usr/local/tmp/git$ echo $XXX

dak@lola:/usr/local/tmp/git$ 
And that makes sense to me.  Whatever, does not help.
-- 
David Kastrup
Michael Haggerty· Mar 13, 2014, 17:06 UTC · re: Junio C Hamano · lore

Re: New GSoC microproject ideas

On 03/12/2014 08:04 PM, Junio C Hamano wrote:
Show 25 quoted lines
> Here is another, as I seem to have managed to kill another one ;-)
> 
> -- >8 --
> 
> "VAR=VAL command" is sufficient to run 'command' with environment
> variable VAR set to value VAL without affecting the environment of
> the shell itself, but we cannot do the same with a shell function
> (most notably, "test_must_fail"); we have subshell invocations with
> multiple lines like this:
> 
> 	... &&
> 	(
>         	VAR=VAL &&
>                 export VAR &&
>                 test_must_fail git command
> 	) &&
>         ...
> 
> but that could be expressed as
> 
> 	... &&
>         test_must_fail env VAR=VAL git comand &&
> 	...
> 
> Find and shorten such constructs in existing test scripts.
Thanks; I just added it.
Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

← back to recent threads