* New GSoC microproject ideas
@ 2014-03-12 11:48 Michael Haggerty
2014-03-12 19:04 ` Junio C Hamano
0 siblings, 1 reply; 8+ messages in thread
From: Michael Haggerty @ 2014-03-12 11:48 UTC (permalink / raw)
To: git discussion list; +Cc: Fabian, Quint Guvernator
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New GSoC microproject ideas
2014-03-12 11:48 New GSoC microproject ideas Michael Haggerty
@ 2014-03-12 19:04 ` Junio C Hamano
2014-03-12 19:16 ` David Kastrup
2014-03-13 17:06 ` Michael Haggerty
0 siblings, 2 replies; 8+ messages in thread
From: Junio C Hamano @ 2014-03-12 19:04 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git discussion list, Fabian, Quint Guvernator
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New GSoC microproject ideas
2014-03-12 19:04 ` Junio C Hamano
@ 2014-03-12 19:16 ` David Kastrup
2014-03-12 19:21 ` Jeff King
2014-03-13 17:06 ` Michael Haggerty
1 sibling, 1 reply; 8+ messages in thread
From: David Kastrup @ 2014-03-12 19:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Haggerty, git discussion list, Fabian, Quint Guvernator
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
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New GSoC microproject ideas
2014-03-12 19:16 ` David Kastrup
@ 2014-03-12 19:21 ` Jeff King
2014-03-12 20:37 ` David Kastrup
0 siblings, 1 reply; 8+ messages in thread
From: Jeff King @ 2014-03-12 19:21 UTC (permalink / raw)
To: David Kastrup
Cc: Junio C Hamano, Michael Haggerty, git discussion list, Fabian,
Quint Guvernator
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.
-Peff
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New GSoC microproject ideas
2014-03-12 19:21 ` Jeff King
@ 2014-03-12 20:37 ` David Kastrup
2014-03-12 20:44 ` Jeff King
0 siblings, 1 reply; 8+ messages in thread
From: David Kastrup @ 2014-03-12 20:37 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Michael Haggerty, git discussion list, Fabian,
Quint Guvernator
Jeff King <peff@peff.net> writes:
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New GSoC microproject ideas
2014-03-12 20:37 ` David Kastrup
@ 2014-03-12 20:44 ` Jeff King
2014-03-12 21:12 ` David Kastrup
0 siblings, 1 reply; 8+ messages in thread
From: Jeff King @ 2014-03-12 20:44 UTC (permalink / raw)
To: David Kastrup
Cc: Junio C Hamano, Michael Haggerty, git discussion list, Fabian,
Quint Guvernator
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
-Peff
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New GSoC microproject ideas
2014-03-12 20:44 ` Jeff King
@ 2014-03-12 21:12 ` David Kastrup
0 siblings, 0 replies; 8+ messages in thread
From: David Kastrup @ 2014-03-12 21:12 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Michael Haggerty, git discussion list, Fabian,
Quint Guvernator
Jeff King <peff@peff.net> writes:
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New GSoC microproject ideas
2014-03-12 19:04 ` Junio C Hamano
2014-03-12 19:16 ` David Kastrup
@ 2014-03-13 17:06 ` Michael Haggerty
1 sibling, 0 replies; 8+ messages in thread
From: Michael Haggerty @ 2014-03-13 17:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git discussion list, Fabian, Quint Guvernator
On 03/12/2014 08:04 PM, Junio C Hamano wrote:
> 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/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-03-13 17:06 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-12 11:48 New GSoC microproject ideas Michael Haggerty
2014-03-12 19:04 ` Junio C Hamano
2014-03-12 19:16 ` David Kastrup
2014-03-12 19:21 ` Jeff King
2014-03-12 20:37 ` David Kastrup
2014-03-12 20:44 ` Jeff King
2014-03-12 21:12 ` David Kastrup
2014-03-13 17:06 ` Michael Haggerty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).