On Mon, Aug 01, 2011 at 12:19:04AM +0200, Jilles Tjoelker wrote:
> On Thu, Jul 14, 2011 at 12:09:15PM +0200, Rudolf Polzer wrote:
> > I just retested with that very command, and yes, the FreeBSD /bin/sh
> > does behave the "non-POSIX" (and "obvious") way, and so does the
> > Solaris /bin/sh.
>
> Y
On Thu, Jul 14, 2011 at 12:09:15PM +0200, Rudolf Polzer wrote:
> I just retested with that very command, and yes, the FreeBSD /bin/sh
> does behave the "non-POSIX" (and "obvious") way, and so does the
> Solaris /bin/sh.
Yes, FreeBSD /bin/sh is not POSIX compliant here. Because the current
behaviou
Rudolf Polzer wrote:
> So basically - when using an assignment for the duration of a shell command
> execution, an explicit subshell must be used in portable scripts, as
> interpretation of this construct differs among shells and thus cannot be
> relied
> on.
If "shell command execution" means "
On Thu, Jul 14, 2011 at 04:26:16AM -0500, Jonathan Nieder wrote:
> Hi,
>
> Rudolf Polzer wrote:
>
> > foo=bar func
> > echo "foo is now $foo"
> >
> > will export foo=bar in global scope (i.e. it affects the execution
> > environment
> > after the function call).
> [...]
> > A shell function howe
Hi,
Rudolf Polzer wrote:
> foo=bar func
> echo "foo is now $foo"
>
> will export foo=bar in global scope (i.e. it affects the execution environment
> after the function call).
[...]
> A shell function however isn't a "special built-in" and also counts as a
> "command name", thus the last echo lin
Hi,
I noticed a little bug:
func()
{
echo "Inside the shell function, foo is $foo"
}
foo=foo
foo=bar func
echo "foo is now $foo"
will export foo=bar in global scope (i.e. it affects the execution environment
after the function call).
This is inconsistent with calls to commands (both bui
