From: Junio C Hamano <gitster@pobox.com>
To: Johannes Sixt <j.sixt@viscovery.net>
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 10:18:18 -0800 [thread overview]
Message-ID: <7vljfzz0yd.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: 4B5027B8.2090507@viscovery.net
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, or do you have more definitive descriptions
you can point at in POSIX.1, so that the log message can be improved to
help people avoid this issue in the future?
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.
[References]
*1* http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05
*2* http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_14
next prev parent reply other threads:[~2010-01-15 18: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 [this message]
2010-01-15 19:16 ` Johannes Sixt
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=7vljfzz0yd.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
--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 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).