Re: [PATCH] t4014: shell portability fix

On Wed, Jun 01, 2016 at 09:57:06AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Maybe: > > > > We sometimes get around this by using env, like: > > > > test_must_fail env FOO=BAR some-program > > > > But that works for test_must_fail because it further

Re: [PATCH] t4014: shell portability fix

Jeff King writes: > Maybe: > > We sometimes get around this by using env, like: > > test_must_fail env FOO=BAR some-program > > But that works for test_must_fail because it further runs its > arguments via the shell, so we can stick the "env" on the right-hand >

Re: [PATCH] t4014: shell portability fix

On Wed, Jun 01, 2016 at 08:07:16AM -0700, Junio C Hamano wrote: > > Here's the patch I wrote up earlier (but was too timid to send out after > > my barrage of emails :) ). > > Looks very sensible. I'll drop all these "Attempt to test with > ksh93 found these breakages" patches and queue this

Re: [PATCH] t4014: shell portability fix

Jeff King writes: >> >eval "${1%%=*}=\${1#*=}" >> >> Is this an elaborate way to say 'eval "$1"', or is there anything >> more subtle going on? > > Notice that the value half isn't expanded until we get inside the eval. Ahh, right. > Here's

Re: [PATCH] t4014: shell portability fix

On Tue, May 31, 2016 at 11:49:10PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > OK, last email tonight, I promise. > > > > Here's the subshell version. I'm a little embarrassed not to have > > thought of it sooner (though the other one was a fun exercise). > > > >

Re: [PATCH] t4014: shell portability fix

Junio C Hamano writes: >> *) >> "$@" >> exit > > ... or 'exec "$@"' Not really. I am an idiot. The whole point of this exercise is that we would want to have a shell

Re: [PATCH] t4014: shell portability fix

Jeff King writes: > OK, last email tonight, I promise. > > Here's the subshell version. I'm a little embarrassed not to have > thought of it sooner (though the other one was a fun exercise). > > test_env () { > ( > while test $# -gt 0 >

Re: [PATCH] t4014: shell portability fix

On Tue, May 31, 2016 at 10:31 PM, Jeff King wrote: > On Tue, May 31, 2016 at 08:09:43PM -0400, Eric Sunshine wrote: >> I was under the impression that the project was moving toward 'env' to >> deal[1] with this sort of issue. >> >> [1]: 512477b (tests: use "env" to run commands

Re: [PATCH] t4014: shell portability fix

On Wed, Jun 01, 2016 at 07:48:12AM +0200, Johannes Sixt wrote: > Am 01.06.2016 um 05:31 schrieb Jeff King: > > printf '%s' "$1" | sed "s/'/'''/g" > ... > > export -p | grep "^declare -x $1=" > ... > > "$fake_env_var_=$(shellquote > >

Re: [PATCH] t4014: shell portability fix

Am 01.06.2016 um 05:31 schrieb Jeff King: printf '%s' "$1" | sed "s/'/'''/g" ... export -p | grep "^declare -x $1=" ... "$fake_env_var_=$(shellquote "$fake_env_orig_")" ... eval

Re: [PATCH] t4014: shell portability fix

On Wed, Jun 01, 2016 at 01:33:25AM -0400, Jeff King wrote: > Here is the "final" version of the more complicated scheme I came up > with. That I think should be fairly portable, but the subshell thing is > probably way less gross. OK, last email tonight, I promise. Here's the subshell version.

Re: [PATCH] t4014: shell portability fix

On Tue, May 31, 2016 at 11:44:13PM -0400, Jeff King wrote: > So this is gross, but I think it actually _is_ portable, with the > exception of the "is it exported" check. Hmm. So after thinking on this, I realized we don't have to do the clean-up ourselves at all, if we simply operate in a

Re: [PATCH] t4014: shell portability fix

On Tue, May 31, 2016 at 11:44:13PM -0400, Jeff King wrote: > # probably not portable; also, possible without sub-program? > is_exported () { > export -p | grep "^declare -x $1=" > } Obviously this should have been "grep -q" (and my test didn't notice because the variable isn't actually

Re: [PATCH] t4014: shell portability fix

On Tue, May 31, 2016 at 11:31:40PM -0400, Jeff King wrote: > I wondered if we could implement our own "env" in the shell, but it's a > little non-trivial, because: > [...] > Here's what I came up with, which does seem to work. It's pretty gnarly, > though. Here's a revised version that drops the

Re: [PATCH] t4014: shell portability fix

On Tue, May 31, 2016 at 10:31:59PM -0400, Jeff King wrote: > On Tue, May 31, 2016 at 08:09:43PM -0400, Eric Sunshine wrote: > > > I was under the impression that the project was moving toward 'env' to > > deal[1] with this sort of issue. > > > > [1]: 512477b (tests: use "env" to run commands

Re: [PATCH] t4014: shell portability fix

On Tue, May 31, 2016 at 08:09:43PM -0400, Eric Sunshine wrote: > >> - GIT_AUTHOR_NAME="éxötìc" test_commit exotic && > >> + (export GIT_AUTHOR_NAME="éxötìc"; test_commit exotic) && > > Isn't "export FOO=val" unportable? Good catch. I was so busy looking for other cases I didn't even see

Re: [PATCH] t4014: shell portability fix

On Tue, May 31, 2016 at 6:56 PM, Jeff King wrote: > On Tue, May 31, 2016 at 03:53:15PM -0700, Junio C Hamano wrote: >> One-shot assignment to an environment variable, i.e. >> >> VAR=VAL cmd >> >> does not work as expected for "cmd" that is a shell function on >> certain

Re: [PATCH] t4014: shell portability fix

On 31/05/16 23:53, Junio C Hamano wrote: > One-shot assignment to an environment variable, i.e. > > VAR=VAL cmd > > does not work as expected for "cmd" that is a shell function on > certain shells. test_commit _is_ a helper function and cannot be > driven that way portably. > >

Re: [PATCH] t4014: shell portability fix

On Tue, May 31, 2016 at 03:53:15PM -0700, Junio C Hamano wrote: > One-shot assignment to an environment variable, i.e. > > VAR=VAL cmd > > does not work as expected for "cmd" that is a shell function on > certain shells. test_commit _is_ a helper function and cannot be > driven that way

[PATCH] t4014: shell portability fix

One-shot assignment to an environment variable, i.e. VAR=VAL cmd does not work as expected for "cmd" that is a shell function on certain shells. test_commit _is_ a helper function and cannot be driven that way portably. Signed-off-by: Junio C Hamano ---