All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Tarmigan Casebolt <tarmigan+git@gmail.com>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: [PATCH v2] Test t5560: Fix test when run with dash
Date: Fri, 15 Jan 2010 20:16:59 +0100	[thread overview]
Message-ID: <201001152017.00121.j6t@kdbg.org> (raw)
In-Reply-To: <7vljfzz0yd.fsf@alter.siamese.dyndns.org>

On Freitag, 15. Januar 2010, Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> > Tarmigan Casebolt schrieb:
> >>         REQUEST_METHOD="GET" some_shell_function
> >>
> >> I can't tell from my reading of the POSIX spec whether my usage was
> >> wrong or if dash is wrong,
> >
> > According to POSIX, variables set as shown above for shell functions are
> > not exported and retain their value after the function returns.
>
> I actually looked for this yesterday, but didn't find a relevant
> definition.  But "2.9.5 Function Definition Command" [*1*] seems to
> address the issue: "When a function is executed, it shall have the
> syntax-error and variable-assignment properties described for special
> built-in utilities...".
>
> And "2.14 Special Built-in Utilities" section [*2*] says "2. Variable
> assignments specified with special built-in utilities remain in effect
> after the built-in completes...".  Taking both together, it seems that
> the assignment should be in effect after the function returns.
>
> Does my reading match yours,

These are exactly the definitions that I meant. The statement that variables 
are not exported is in "2.9.1 Simple Commands" 
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01

"[If there is a command name], the variable assignments shall be exported for 
the execution environment of the command and shall not affect the current 
execution environment (except for special built-ins)."

> Yesterday, I saw rebase--interactive has a few codepaths where "output"
> shell function was used with the single-shot export; perhaps they need to
> also be fixed.

I knew these spots, and they were discussed when that code was introduced. 
Before I sent out the mail you were responding to, I tried various ways to 
show the failure in rebase--interactive, but it didn't fail...

-- Hannes

  reply	other threads:[~2010-01-15 19:18 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-28 22:04 [PATCH RFC 1/2] Smart-http tests: Break test t5560-http-backend into pieces Tarmigan Casebolt
2009-12-28 22:04 ` [PATCH RFC 2/2] Smart-http tests: Test http-backend without curl or a webserver Tarmigan Casebolt
2009-12-30 17:54 ` [PATCH RFC 1/2] Smart-http tests: Break test t5560-http-backend into pieces Junio C Hamano
2009-12-30 18:09   ` Tarmigan
2009-12-30 18:59     ` Tarmigan Casebolt
2009-12-30 18:59       ` [PATCH RFC 2/2] Smart-http tests: Test http-backend without curl or a webserver Tarmigan Casebolt
2010-01-01  5:15     ` [PATCH RFC 1/2] Smart-http tests: Break test t5560-http-backend into pieces Junio C Hamano
2010-01-02 20:44       ` Tarmigan
2010-01-02 20:45         ` [PATCH v3 RFC 1/3] Smart-http tests: Improve coverage in test t5560 Tarmigan Casebolt
2010-01-02 20:54           ` Shawn O. Pearce
2010-01-02 20:45         ` [PATCH v3 2/3] Smart-http tests: Break test t5560-http-backend into pieces Tarmigan Casebolt
2010-01-02 20:59           ` Shawn O. Pearce
2010-01-02 21:38             ` [PATCH v4 1/3] Smart-http tests: Improve coverage in test t5560 Tarmigan Casebolt
2010-01-02 21:38             ` [PATCH v4 2/3] Smart-http tests: Break test t5560-http-backend into pieces Tarmigan Casebolt
2010-01-02 21:38             ` [PATCH v4 3/3] Smart-http tests: Test http-backend without curl or a webserver Tarmigan Casebolt
2010-01-02 20:45         ` [PATCH v3 " Tarmigan Casebolt
2010-01-02 21:03           ` Shawn O. Pearce
2010-01-02 21:37             ` Tarmigan
2010-01-02 21:41               ` Shawn O. Pearce
2010-01-02 21:43                 ` [PATCH v4 " Tarmigan Casebolt
2010-01-14  5:27                   ` Michael Haggerty
2010-01-14  7:01                     ` [PATCH] Test t5560: Fix test when run with dash Tarmigan Casebolt
2010-01-14  8:23                       ` Michael Haggerty
2010-01-14  8:41                       ` Junio C Hamano
2010-01-15  6:44                         ` [PATCH v2] " Tarmigan Casebolt
2010-01-15  8:30                           ` Johannes Sixt
2010-01-15 18:18                             ` Junio C Hamano
2010-01-15 19:16                               ` Johannes Sixt [this message]
2010-01-15 19:53                                 ` Junio C Hamano
2010-01-16  1:05                                 ` Junio C Hamano
2010-01-21 16:15                                   ` Michael Haggerty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201001152017.00121.j6t@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mhagger@alum.mit.edu \
    --cc=spearce@spearce.org \
    --cc=tarmigan+git@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.