Niall Smart wrote in list.freebsd-hackers:
>
> > I'm not sure if XPG4v2 requires command substitution to behave
> > like that. At least, both Solaris' and DEC UNIX... oops...
> > True64 UNIX do execute all command substitutions in a subshell
> > (`pwd` does not affect the surrounding shell),
Niall Smart wrote in list.freebsd-hackers:
>
> > I'm not sure if XPG4v2 requires command substitution to behave
> > like that. At least, both Solaris' and DEC UNIX... oops...
> > True64 UNIX do execute all command substitutions in a subshell
> > (`pwd` does not affect the surrounding shell)
> I'm not sure if XPG4v2 requires command substitution to behave
> like that. At least, both Solaris' and DEC UNIX... oops...
> True64 UNIX do execute all command substitutions in a subshell
> (`pwd` does not affect the surrounding shell), and both claim
> XPG4 compliance.
They only execute a su
> I'm not sure if XPG4v2 requires command substitution to behave
> like that. At least, both Solaris' and DEC UNIX... oops...
> True64 UNIX do execute all command substitutions in a subshell
> (`pwd` does not affect the surrounding shell), and both claim
> XPG4 compliance.
They only execute a s
On Tue, 13 Jul 1999, Oliver Fromme wrote:
> > But isn't that exactly what's happening here, where PWD is being tainted
> > by the commands evaluated within the substitution?
>
> Yes, I'd call that a bug which should be fixed.
> The manpage clearly says:
>
> "The shell expands the command s
Sheldon Hearn wrote in list.freebsd-hackers:
> On Tue, 13 Jul 1999 18:13:42 +0200, Oliver Fromme wrote:
>
> > Command substitution certainly has to spawn a subshell, even
> > for built-in commands, because otherwise you could modify
> > parent shell variables within command substitutions.
>
On Tue, 13 Jul 1999, Oliver Fromme wrote:
> > But isn't that exactly what's happening here, where PWD is being tainted
> > by the commands evaluated within the substitution?
>
> Yes, I'd call that a bug which should be fixed.
> The manpage clearly says:
>
> "The shell expands the command
Sheldon Hearn wrote in list.freebsd-hackers:
> On Tue, 13 Jul 1999 18:13:42 +0200, Oliver Fromme wrote:
>
> > Command substitution certainly has to spawn a subshell, even
> > for built-in commands, because otherwise you could modify
> > parent shell variables within command substitutions.
>
On Tue, 13 Jul 1999 18:13:42 +0200, Oliver Fromme wrote:
> Command substitution certainly has to spawn a subshell, even
> for built-in commands, because otherwise you could modify
> parent shell variables within command substitutions.
But isn't that exactly what's happening here, where PWD is b
Niall Smart wrote in list.freebsd-hackers:
> As I understand it most builtins will not spawn a new shell
> when they are used in command substitution:
>
> niall% echo `echo $$` $$
> 20354 20354
> niall%
Actually, that example doesn't prove anything. :-)
$ echo `echo $$` $$
8376 8376
$ ec
On Tue, 13 Jul 1999 18:13:42 +0200, Oliver Fromme wrote:
> Command substitution certainly has to spawn a subshell, even
> for built-in commands, because otherwise you could modify
> parent shell variables within command substitutions.
But isn't that exactly what's happening here, where PWD is
Niall Smart wrote in list.freebsd-hackers:
> As I understand it most builtins will not spawn a new shell
> when they are used in command substitution:
>
> niall% echo `echo $$` $$
> 20354 20354
> niall%
Actually, that example doesn't prove anything. :-)
$ echo `echo $$` $$
8376 8376
$ e
Sheldon Hearn wrote:
>
> On Mon, 12 Jul 1999 18:37:13 GMT, Niall Smart wrote:
>
> > The patch appended seems to fix this, I'd like someone familiar
> > with sh to review it though, since this may be symptomatic of
> > a general problem with command substitution.
>
> As I understand your patch, y
Sheldon Hearn wrote:
>
> On Mon, 12 Jul 1999 18:37:13 GMT, Niall Smart wrote:
>
> > The patch appended seems to fix this, I'd like someone familiar
> > with sh to review it though, since this may be symptomatic of
> > a general problem with command substitution.
>
> As I understand your patch,
On Mon, 12 Jul 1999 18:37:13 GMT, Niall Smart wrote:
> The patch appended seems to fix this, I'd like someone familiar
> with sh to review it though, since this may be symptomatic of
> a general problem with command substitution.
As I understand your patch, you're saying "we should fork off a c
Sheldon Hearn wrote:
> cd /tmp
> echo .`cd /`.
> pwd
>
> Any takers?
The patch appended seems to fix this, I'd like someone familiar
with sh to review it though, since this may be symptomatic of
a general problem with command substitution.
> PS: And no, this is not an invitation to chat about t
On Mon, 12 Jul 1999 18:37:13 GMT, Niall Smart wrote:
> The patch appended seems to fix this, I'd like someone familiar
> with sh to review it though, since this may be symptomatic of
> a general problem with command substitution.
As I understand your patch, you're saying "we should fork off a
Sheldon Hearn wrote:
> cd /tmp
> echo .`cd /`.
> pwd
>
> Any takers?
The patch appended seems to fix this, I'd like someone familiar
with sh to review it though, since this may be symptomatic of
a general problem with command substitution.
> PS: And no, this is not an invitation to chat about
Hi folks,
I'm hoping someone here is interested in tracking down a bug in our
/bin/sh . Changing directory within a backtick (``) subshell in sh
taints the parent's working directory. The following sample code gives
the expected result for /bin/csh, but breaks for /bin/sh
cd /tmp
echo .`cd /`.
p
Hi folks,
I'm hoping someone here is interested in tracking down a bug in our
/bin/sh . Changing directory within a backtick (``) subshell in sh
taints the parent's working directory. The following sample code gives
the expected result for /bin/csh, but breaks for /bin/sh
cd /tmp
echo .`cd /`.
20 matches
Mail list logo