Hi,
I have a question about the bash redirection and the curly braces.
The manual said the command in a pair of curly braces will excute
in the current context:
And I do following:

#{ cat file1 >&3 ; cat file2 } 3>&1 >&-

This command print the file1 normally as my exceptation, but
the second cat command give an error: standard output not open.

If the two cat commands excute in the same shell, the second
cat will use the same redirection as the first one. Am I right?
So, it can't produce any error. Why?

And when there is one or more pipelines in the curlly braces,
what the condition of redirections?

Thanks in advance!

On Sun, 03 Dec 2006 23:54:05 +0800, Bo Yang wrote:

> Hi,
> I have a question about the bash redirection and the curly braces.
> The manual said the command in a pair of curly braces will excute
> in the current context:
> And I do following:
>
> #{ cat file1 >&3 ; cat file2 } 3>&1 >&-
>
> This command print the file1 normally as my exceptation, but
> the second cat command give an error: standard output not open.
>
> If the two cat commands excute in the same shell, the second
> cat will use the same redirection as the first one. Am I right?
> So, it can't produce any error. Why?
>
> And when there is one or more pipelines in the curlly braces,
> what the condition of redirections?
>
> Thanks in advance!

The first thing that happens is you close stdout with >&-
When cat tries to write to stdout it finds it not open and raises an error.
Adam

Bo Yang wrote:
> Hi,
> I have a question about the bash redirection and the curly braces.
> The manual said the command in a pair of curly braces will excute
> in the current context:
> And I do following:
>
> #{ cat file1 >&3 ; cat file2 } 3>&1 >&-
>
> This command print the file1 normally as my exceptation, but
> the second cat command give an error: standard output not open.
>
> If the two cat commands excute in the same shell, the second
> cat will use the same redirection as the first one. Am I right?

No. Within the braces you just redirected the output for the first cat,
the second cat still connected to stdout. (And you closed stdout outside
the braces.) If you want all stdout to be redirected use exec >&3 ;

Janis

> So, it can't produce any error. Why?
>
> And when there is one or more pipelines in the curlly braces,
> what the condition of redirections?
>
> Thanks in advance!

Adam Price
> On Sun, 03 Dec 2006 23:54:05 +0800, Bo Yang wrote:
>
>> Hi,
>> I have a question about the bash redirection and the curly braces.
>> The manual said the command in a pair of curly braces will excute
>> in the current context:
>> And I do following:
>>
>> #{ cat file1 >&3 ; cat file2 } 3>&1 >&-
>>
>> This command print the file1 normally as my exceptation, but
>> the second cat command give an error: standard output not open.
>>
>> If the two cat commands excute in the same shell, the second
>> cat will use the same redirection as the first one. Am I right?
>> So, it can't produce any error. Why?
>>
>> And when there is one or more pipelines in the curlly braces,
>> what the condition of redirections?
>>
>> Thanks in advance!
>
> The first thing that happens is you close stdout with >&-
> When cat tries to write to stdout it finds it not open and raises an error.
> Adam

I know what the redirection means, and what I can't understand is
that if the two cat commands excute in the same shell, how the shell
implement so that the every command can have itself redirections.

Bo Yang wrote:
> Adam Price
>>On Sun, 03 Dec 2006 23:54:05 +0800, Bo Yang wrote:
>>
>>>Hi,
>>> I have a question about the bash redirection and the curly braces.
>>> The manual said the command in a pair of curly braces will excute
>>>in the current context:
>>> And I do following:
>>>
>>>#{ cat file1 >&3 ; cat file2 } 3>&1 >&-

BTW, you forgot a semicolon after the second cat command.

>>>
>>>This command print the file1 normally as my exceptation, but
>>>the second cat command give an error: standard output not open.
>>>
>>>If the two cat commands excute in the same shell, the second
>>>cat will use the same redirection as the first one. Am I right?
>>>So, it can't produce any error. Why?
>>>
>>>And when there is one or more pipelines in the curlly braces,
>>>what the condition of redirections?
>>>
>>>Thanks in advance!
>>
>>The first thing that happens is you close stdout with >&-
>>When cat tries to write to stdout it finds it not open and raises an error.
>>Adam
>
>
> I know what the redirection means, and what I can't understand is
> that if the two cat commands excute in the same shell, how the shell
> implement so that the every command can have itself redirections.

You don't understand that the commands...

cat file1 >wherever1
cat file2 >whereever2

....(which execute in the same shell) can have their own redirection?

You may want to clarify your question.

Janis

2006-12-04, 03:34(+01), Janis Papanagnou:
> Bo Yang wrote:
>> Adam Price
>>>On Sun, 03 Dec 2006 23:54:05 +0800, Bo Yang wrote:
>>>
>>>>Hi,
>>>> I have a question about the bash redirection and the curly braces.
>>>> The manual said the command in a pair of curly braces will excute
>>>>in the current context:
>>>> And I do following:
>>>>
>>>>#{ cat file1 >&3 ; cat file2 } 3>&1 >&-
>
> BTW, you forgot a semicolon after the second cat command.

You don't need it if your shell is zsh, though.

[...]
>> I know what the redirection means, and what I can't understand is
>> that if the two cat commands excute in the same shell, how the shell
>> implement so that the every command can have itself redirections.
[...]

Maybe you (Bo) misundertood the statement that said what was
inside { ... ; } was run in the same shell.

It means "the same shell/same environment as the one parsing the
commands outside the braces".

In

{ var=1; }; var=2

It is the same shell that parses var=1 and var=2. As opposed to:

(var=1); var=2

where (...) starts a subshell (or a different shell environment
for recent versions of ksh).

in any case, in

cat some-file > foo

as "cat" is (generally) an external command that needs to be
exec(2)uted, the shell forks a new process.

So it will do:

if (!fork()) {
// child
dup2(open("foo", ...), 0);
...
execvp("cat", ...)
}


--
Stéphane

Stephane CHAZELAS :
> 2006-12-04, 03:34(+01), Janis Papanagnou:
>> Bo Yang wrote:
>>> Adam Price
>>>> On Sun, 03 Dec 2006 23:54:05 +0800, Bo Yang wrote:
>>>>
>>>>> Hi,
>>>>> I have a question about the bash redirection and the curly braces.
>>>>> The manual said the command in a pair of curly braces will excute
>>>>> in the current context:
>>>>> And I do following:
>>>>>
>>>>> #{ cat file1 >&3 ; cat file2 } 3>&1 >&-
>> BTW, you forgot a semicolon after the second cat command.
>
> You don't need it if your shell is zsh, though.
>
> [...]
>>> I know what the redirection means, and what I can't understand is
>>> that if the two cat commands excute in the same shell, how the shell
>>> implement so that the every command can have itself redirections.
> [...]
>
> Maybe you (Bo) misundertood the statement that said what was
> inside { ... ; } was run in the same shell.
>
> It means "the same shell/same environment as the one parsing the
> commands outside the braces".
>
> In
>
> { var=1; }; var=2
>
> It is the same shell that parses var=1 and var=2. As opposed to:
>
> (var=1); var=2
>
> where (...) starts a subshell (or a different shell environment
> for recent versions of ksh).
>
> in any case, in
>
> cat some-file > foo
>
> as "cat" is (generally) an external command that needs to be
> exec(2)uted, the shell forks a new process.
>
> So it will do:
>
> if (!fork()) {
> // child
> dup2(open("foo", ...), 0);
> ...
> execvp("cat", ...)
> }
>
>
So, while it is about an external command, all commands
in a brace excute in the same environment but not the
same shell. I understand, Thank you Stephane !

Thanks!

2006-12-04, 19:52(+08), Bo Yang:
[...]
>> { var=1; }; var=2
>>
>> It is the same shell that parses var=1 and var=2. As opposed to:
>>
>> (var=1); var=2
>>
>> where (...) starts a subshell (or a different shell environment
>> for recent versions of ksh).
>>
>> in any case, in
>>
>> cat some-file > foo
>>
>> as "cat" is (generally) an external command that needs to be
>> exec(2)uted, the shell forks a new process.
>>
>> So it will do:
>>
>> if (!fork()) {
>> // child
>> dup2(open("foo", ...), 0);
>> ...
>> execvp("cat", ...)
>> }
>>
>>
> So, while it is about an external command, all commands
> in a brace excute in the same environment but not the
> same shell. I understand, Thank you Stephane !
[...]

Depends what you call same shell.

In

{ cmd1; }; cmd2

it's the same shell that runs the two commands, in the same
/environment/. That is, if cmd1 modifies the current shell
environment (as read, export, assignments, exec... do), then
cmd2 will see that modified environment.

The fact that the shell forks itself to run external commands is
a technical matter that is a separate thing. External commands
can't modify the shell environment anyway.

in

(cmd1); cmd2

cmd1 affects a separate copy of the environmnt only, if cmd1
modifies this environment, such as when cmd1 is "var=foo", the
change it makes will not be seen by cmd2.

The way that is achieved depends on the shell. Most shells fork
themselves to achieve that (so that changes are done in a
different process so that there's no way the parent process is
affected), but some others (mainly recent versions of ksh) may
not.

--
Stéphane

In article <ekuu7j$g3p$1@news.cn99.com>,
Bo Yang <struggle@mail.nankai.edu.cn> wrote:
>#{ cat file1 >&3 ; cat file2 } 3>&1 >&-
>
>This command print the file1 normally as my exceptation, but
>the second cat command give an error: standard output not open.

This behavior has explained well enough by other posters already. While
experimenting, I discovered that ash does the wrong thing:

$ echo this is file1 > file1
$ echo this is file2 > file2
$ { cat file1 >&3 ; cat file2 ; } 3>&1 >&-
this is file1
this is file2
$

--
The attacker\x92s overall goal would very probably be to convince other users
to run an unsafe program, by using the digital signature to convince them
that it is actually bona fide Microsoft software and therefore safe to run.
-- security bulletin MS01-017 ushers in a new definition of "safe"

Alan Curry :
> In article <ekuu7j$g3p$1@news.cn99.com>,
> Bo Yang <struggle@mail.nankai.edu.cn> wrote:
>> #{ cat file1 >&3 ; cat file2 } 3>&1 >&-
>>
>> This command print the file1 normally as my exceptation, but
>> the second cat command give an error: standard output not open.
>
> This behavior has explained well enough by other posters already. While
> experimenting, I discovered that ash does the wrong thing:
>
> $ echo this is file1 > file1
> $ echo this is file2 > file2
> $ { cat file1 >&3 ; cat file2 ; } 3>&1 >&-
> this is file1
> this is file2
> $
>
Oh, this is a bug?

2006-12-05, 16:27(+08), Bo Yang:
[...]
>> This behavior has explained well enough by other posters already. While
>> experimenting, I discovered that ash does the wrong thing:
>>
>> $ echo this is file1 > file1
>> $ echo this is file2 > file2
>> $ { cat file1 >&3 ; cat file2 ; } 3>&1 >&-
>> this is file1
>> this is file2
>> $
>>
> Oh, this is a bug?

It is indeed. It was not in the original ash, it may have been
introduce by one of the BSDs or by debian.

--
Stéphane

In article <slrnenad4t.44h.stephane.chazelas@spam.is.invalid> ,
Stephane CHAZELAS <this.address@is.invalid> wrote:
>2006-12-05, 16:27(+08), Bo Yang:
>[...]

Someone snipped the attribution, but the following hunk of text was mine:
>>> This behavior has explained well enough by other posters already. While
>>> experimenting, I discovered that ash does the wrong thing:
>>>
>>> $ echo this is file1 > file1
>>> $ echo this is file2 > file2
>>> $ { cat file1 >&3 ; cat file2 ; } 3>&1 >&-
>>> this is file1
>>> this is file2
>>> $

>> Oh, this is a bug?
>
>It is indeed. It was not in the original ash, it may have been
>introduce by one of the BSDs or by debian.

I did the above demonstration with Debian's ash (sufficiently modified that
they've started calling it "dash"). I'll try to find out where the bug got
added.

--
Alan Curry
pacman@world.std.com

I wrote:
>
>I did the above demonstration with Debian's ash (sufficiently modified that
>they've started calling it "dash"). I'll try to find out where the bug got
>added.

In case anyone's curious, the bug was already reported many months ago, as
Debian Bug#357091 (http://bugs.debian.org/357091) with a patch available.

--
Alan Curry
pacman@world.std.com