Re: Shell script termination with exit function in backquotes
On Tue, 2011-03-22 at 12:32 +, RW wrote:
> On Sat, 19 Mar 2011 09:44:57 -0700
> Devin Teske wrote:
>
>
> > At least two variations to the rule that { ... } is a block of
> > commands executed in the current shell are:
> >
> > 1. When the block appears as a function
>
> Is that correct?
It depends on where and how you are using the function.
For example, ...
#!/bin/sh
:
abc()
{
x=2
}
:
x=1
abc
echo $x
# produces "2"
:
x=1
: `abc`
echo $x
# produces "1"
:
x=1
: `x=2`
echo $x
# produces "2"
:
x=1
: `{ x=2; }`
echo $x
# produces "2"
:
... in the above example, the function embedded within back-ticks is
executed in a sub-shell (but that is not to imply that back-ticks
themselves invoke a sub-shell -- as shown above, I put a simple
statement and a compound statement [surrounded in curlies] in back-ticks
and neither are executed in a sub-shell... only the function-call is
executed within a sub-shell when executed within back-ticks).
> I'd assumed that functions do execute in the current
> shell since you can alter variables from a function
Functions may or may-not execute in a sub-shell depending on the context
in which they are used.
> , whilst you can't
> from a "()".
Correct, parenthesetical blocks always form a sub-shell.
>
> e.g.
>
> $ cat /tmp/foo
> #!/bin/sh
>
> f (){
> x=2
> }
>
> x=1
> f
> echo $x
> ( x=3 )
> echo $x
>
>
>
> $ /tmp/foo
> 2
> 2
>
>
>
> ___
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
--
Cheers,
Devin Teske
-> FUN STUFF <-
-BEGIN GEEK CODE BLOCK-
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L
$ E-
W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b
+>++ DI+
D+(++) G++ e> h r+++ z+++
--END GEEK CODE BLOCK--
Learn about the "Geek Code": http://www.geekcode.com/
-> LEGAL DISCLAIMER <-
This message contains confidential and proprietary information
of the sender, and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person is strictly prohibited. If you have received this
message in error, please notify the e-mail sender immediately,
and delete the original message without making a copy.
-> END TRANSMISSION <-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
Maxim Khitrov wrote:
> [$(exit) exits the main shell environment]
This is a bug which is fixed in 9-current.
Another message:
> On Sat, Mar 19, 2011 at 12:44 PM, Devin Teske wrote:
> > [all elements of multi-command pipelines are executed in a subshell]
> > You're learning that there are deviations to the rule as-mentioned
> > in the man-page.
> I've learned this a long time ago :)
> My point is that these deviations should be noted in the man page to
> help eliminate such surprises. A single sentence would have sufficed
> in this case.
The man page is not complete, but this has been in it for a while, in
the Pipelines subsection:
] Note that unlike some other shells, sh executes each process in a
] pipeline with more than one command in a subshell environment and as a
] child of the sh process.
This means that in A | B | C, three processes are created with the shell
as their common parent. (Compared to the Bourne shell, where A and B are
children of C, and to the Korn shell which executes C in the main shell
process.)
Note, PR bin/34811 requests certain first commands of pipelines (in
particular, "jobs") to be executed in the main shell environment, not as
a subshell. POSIX permits this and it may be implemented at some point.
If the pipeline has two elements, the second element could be executed
in the main shell environment as well but this could be confusing.
> > The reason for these deviations is quite simple in-fact...
> > The shell needs to create a new set of stdin/stdout file-descriptors
> > for the block of commands that you've created, and executing said
> > commands within a sub-shell achieves that.
That is not the reason. Code like { ... } >F also redirects file
descriptors for the duration of the block but does not create a
subshell. For the Bourne shell freaks, exec 3>&1 >F; ...; exec >&3 3>&-
One of the reasons is job control. To keep things sane, all processes in
a job should be in the same process group. Executing part of the job in
the main shell process requires special effort to make sure tty
input/output/control works correctly and to handle ^Z, such as by
forking when ^Z happens (which may be unexpected).
Also, the Bourne shell has always executed all elements of pipelines in
a subshell and many shells have followed it.
--
Jilles Tjoelker
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
On Sat, 19 Mar 2011 09:44:57 -0700
Devin Teske wrote:
> At least two variations to the rule that { ... } is a block of
> commands executed in the current shell are:
>
> 1. When the block appears as a function
Is that correct? I'd assumed that functions do execute in the current
shell since you can alter variables from a function, whilst you can't
from a "()".
e.g.
$ cat /tmp/foo
#!/bin/sh
f (){
x=2
}
x=1
f
echo $x
( x=3 )
echo $x
$ /tmp/foo
2
2
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
in freebsd-questions Digest, Vol 354, Issue 10, Message: 4
On Sat, 19 Mar 2011 12:15:26 -0400 Maxim Khitrov wrote:
> Here's another, but related, problem that I just ran into. The man page
> reads:
>
> Commands may be grouped by writing either
>(list)
> or
>{ list; }
> The first form executes the commands in a subshell. Note that built-in
> commands thus executed do not affect the current shell...
>
> Here's my script:
>
>
> #!/bin/sh
>
> { A=1; }; echo $A
> echo | { B=2; }; echo $B
> { C=3; } > /dev/null; echo $C
>
>
> And here's the output:
>
>
> 1
>
> 3
>
>
> Where did the '2' go? Again, I have to assume that when stdin is piped
> to a group of commands, those commands are executed in a subshell
> despite curly braces. But where is this behavior documented? It seems
> that there are a lot of corner cases that can only be understood if
> you are familiar with the shell implementation. Documentation can
> certainly be improved in places.
See sh(1) /Pipelines - last para:
Note that unlike some other shells, sh executes each process in the pipe-
line as a child of the sh process. Shell built-in commands are the
exception to this rule. They are executed in the current shell, although
they do not affect its environment when used in pipelines.
The braces aren't relevant because it's a pipeline, so even without:
echo | B=2; echo $B
writes '', but
echo | { B=2; echo $B; }
or (equivalent within a pipeline)
echo | ( B=2; echo $B; )
writes '2'.
cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
On Sat, Mar 19, 2011 at 11:45 AM, Maxim Khitrov wrote:
>
> Here's another, but related, problem that I just ran into. The man page reads:
>
> Commands may be grouped by writing either
> (list)
> or
> { list; }
> The first form executes the commands in a subshell. Note that built-in
> commands thus executed do not affect the current shell...
and it also says that the rhs in a pipe is always executed in a subshell
>
> Here's my script:
>
>
> #!/bin/sh
>
> { A=1; }; echo $A
> echo | { B=2; }; echo $B
> { C=3; } > /dev/null; echo $C
>
>
> And here's the output:
>
>
> 1
>
> 3
>
>
> Where did the '2' go? Again, I have to assume that when stdin is piped
> to a group of commands, those commands are executed in a subshell
> despite curly braces. But where is this behavior documented? It seems
> that there are a lot of corner cases that can only be understood if
> you are familiar with the shell implementation. Documentation can
> certainly be improved in places.
>
this time it's a case of you not being familiar, and not violations of
principle of least suprise like ash command substitutions
the only broadly deployed shells that do not execute the (whole) rhs
in a subshell are ksh and descendants, and even then there are many
exceptions
the bracket grouping is irrelevant
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
Maxim Khitrov wrote: > ... these deviations should be noted in the man page to > help eliminate such surprises. A single sentence would > have sufficed in this case. As always, I'm sure patches would be welcome :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
On Sat, Mar 19, 2011 at 12:44 PM, Devin Teske wrote:
>
> On Mar 19, 2011, at 9:15 AM, Maxim Khitrov wrote:
>
>> On Mon, Mar 14, 2011 at 6:40 PM, Andres Perera wrote:
>>> On Mon, Mar 14, 2011 at 7:46 AM, Maxim Khitrov wrote:
On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera wrote:
> On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske wrote:
>> If you make the changes that I've suggested, you'll have consistent
>> execution. The reason you're having inconsistent behavior is because
>> Linux has /bin/sh symbolically linked to /bin/bash while FreeBSD has a
>> more traditional shell (we'll call it bourne shell "plus").
>
> that is misleading because command substitutions have traditionally
> invoked subshells, and freebsd sh(1)/ash is an exception, not the norm
>
> in this case, ksh and bash deviates are clearly closer to standard
> bourne behaviour
>
Thanks for that explanation. I can understand the benefits of
optimizing away subshell execution, but that can clearly lead to
unexpected behavior. Is there some documentation on when this
optimization is utilized (i.e. the command executed without a
subshell)? Would I be correct in assuming that it is only restricted
to built-in commands that are known not to produce any output, such as
'exit'?
>>>
>>> i would check the source, autoconf docs, and http://www.in-ulm.de/~mascheck/
>>>
>>> netbsd has been patched to fix `exit 1`, according to the last site
>>
>> Here's another, but related, problem that I just ran into. The man page
>> reads:
>>
>> Commands may be grouped by writing either
>> (list)
>> or
>> { list; }
>> The first form executes the commands in a subshell. Note that built-in
>> commands thus executed do not affect the current shell...
>>
>> Here's my script:
>>
>>
>> #!/bin/sh
>>
>> { A=1; }; echo $A
>> echo | { B=2; }; echo $B
>> { C=3; } > /dev/null; echo $C
>>
>>
>> And here's the output:
>>
>>
>> 1
>>
>> 3
>>
>>
>> Where did the '2' go?
>
> You're learning that there are deviations to the rule as-mentioned in the
> man-page.
I've learned this a long time ago :)
My point is that these deviations should be noted in the man page to
help eliminate such surprises. A single sentence would have sufficed
in this case.
> The reason for these deviations is quite simple in-fact...
>
> The shell needs to create a new set of stdin/stdout file-descriptors for the
> block of commands that you've created, and executing said commands within a
> sub-shell achieves that.
Something very similar to this should be noted in the man page. I
figured out why my code wasn't working quickly after thinking about
how data would be piped to stdin. Others may waste a lot of time
trying to figure out why their code doesn't do what the man page
states it should be doing.
- Max
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
On Mar 19, 2011, at 9:15 AM, Maxim Khitrov wrote:
> On Mon, Mar 14, 2011 at 6:40 PM, Andres Perera wrote:
>> On Mon, Mar 14, 2011 at 7:46 AM, Maxim Khitrov wrote:
>>> On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera wrote:
On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske wrote:
> If you make the changes that I've suggested, you'll have consistent
> execution. The reason you're having inconsistent behavior is because
> Linux has /bin/sh symbolically linked to /bin/bash while FreeBSD has a
> more traditional shell (we'll call it bourne shell "plus").
that is misleading because command substitutions have traditionally
invoked subshells, and freebsd sh(1)/ash is an exception, not the norm
in this case, ksh and bash deviates are clearly closer to standard
bourne behaviour
>>>
>>> Thanks for that explanation. I can understand the benefits of
>>> optimizing away subshell execution, but that can clearly lead to
>>> unexpected behavior. Is there some documentation on when this
>>> optimization is utilized (i.e. the command executed without a
>>> subshell)? Would I be correct in assuming that it is only restricted
>>> to built-in commands that are known not to produce any output, such as
>>> 'exit'?
>>
>> i would check the source, autoconf docs, and http://www.in-ulm.de/~mascheck/
>>
>> netbsd has been patched to fix `exit 1`, according to the last site
>
> Here's another, but related, problem that I just ran into. The man page reads:
>
> Commands may be grouped by writing either
> (list)
> or
> { list; }
> The first form executes the commands in a subshell. Note that built-in
> commands thus executed do not affect the current shell...
>
> Here's my script:
>
>
> #!/bin/sh
>
> { A=1; }; echo $A
> echo | { B=2; }; echo $B
> { C=3; } > /dev/null; echo $C
>
>
> And here's the output:
>
>
> 1
>
> 3
>
>
> Where did the '2' go?
You're learning that there are deviations to the rule as-mentioned in the
man-page.
At least two variations to the rule that { ... } is a block of commands
executed in the current shell are:
1. When the block appears as a function and
2. When the block appears on the right-hand side of a pipe (with or without
following pipe(s)).
The reason for these deviations is quite simple in-fact...
The shell needs to create a new set of stdin/stdout file-descriptors for the
block of commands that you've created, and executing said commands within a
sub-shell achieves that.
I hope that helps explain.
--
Devin
> Again, I have to assume that when stdin is piped
> to a group of commands, those commands are executed in a subshell
> despite curly braces. But where is this behavior documented? It seems
> that there are a lot of corner cases that can only be understood if
> you are familiar with the shell implementation. Documentation can
> certainly be improved in places.
>
> - Max
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
On Mon, Mar 14, 2011 at 6:40 PM, Andres Perera wrote:
> On Mon, Mar 14, 2011 at 7:46 AM, Maxim Khitrov wrote:
>> On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera wrote:
>>> On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske wrote:
If you make the changes that I've suggested, you'll have consistent
execution. The reason you're having inconsistent behavior is because Linux
has /bin/sh symbolically linked to /bin/bash while FreeBSD has a more
traditional shell (we'll call it bourne shell "plus").
>>>
>>> that is misleading because command substitutions have traditionally
>>> invoked subshells, and freebsd sh(1)/ash is an exception, not the norm
>>>
>>> in this case, ksh and bash deviates are clearly closer to standard
>>> bourne behaviour
>>>
>>
>> Thanks for that explanation. I can understand the benefits of
>> optimizing away subshell execution, but that can clearly lead to
>> unexpected behavior. Is there some documentation on when this
>> optimization is utilized (i.e. the command executed without a
>> subshell)? Would I be correct in assuming that it is only restricted
>> to built-in commands that are known not to produce any output, such as
>> 'exit'?
>
> i would check the source, autoconf docs, and http://www.in-ulm.de/~mascheck/
>
> netbsd has been patched to fix `exit 1`, according to the last site
Here's another, but related, problem that I just ran into. The man page reads:
Commands may be grouped by writing either
(list)
or
{ list; }
The first form executes the commands in a subshell. Note that built-in
commands thus executed do not affect the current shell...
Here's my script:
#!/bin/sh
{ A=1; }; echo $A
echo | { B=2; }; echo $B
{ C=3; } > /dev/null; echo $C
And here's the output:
1
3
Where did the '2' go? Again, I have to assume that when stdin is piped
to a group of commands, those commands are executed in a subshell
despite curly braces. But where is this behavior documented? It seems
that there are a lot of corner cases that can only be understood if
you are familiar with the shell implementation. Documentation can
certainly be improved in places.
- Max
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
On Mon, Mar 14, 2011 at 7:46 AM, Maxim Khitrov wrote: > On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera wrote: >> On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske wrote: >>> If you make the changes that I've suggested, you'll have consistent >>> execution. The reason you're having inconsistent behavior is because Linux >>> has /bin/sh symbolically linked to /bin/bash while FreeBSD has a more >>> traditional shell (we'll call it bourne shell "plus"). >> >> that is misleading because command substitutions have traditionally >> invoked subshells, and freebsd sh(1)/ash is an exception, not the norm >> >> in this case, ksh and bash deviates are clearly closer to standard >> bourne behaviour >> > > Thanks for that explanation. I can understand the benefits of > optimizing away subshell execution, but that can clearly lead to > unexpected behavior. Is there some documentation on when this > optimization is utilized (i.e. the command executed without a > subshell)? Would I be correct in assuming that it is only restricted > to built-in commands that are known not to produce any output, such as > 'exit'? i would check the source, autoconf docs, and http://www.in-ulm.de/~mascheck/ netbsd has been patched to fix `exit 1`, according to the last site > > - Max > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera wrote: > On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske wrote: >> If you make the changes that I've suggested, you'll have consistent >> execution. The reason you're having inconsistent behavior is because Linux >> has /bin/sh symbolically linked to /bin/bash while FreeBSD has a more >> traditional shell (we'll call it bourne shell "plus"). > > that is misleading because command substitutions have traditionally > invoked subshells, and freebsd sh(1)/ash is an exception, not the norm > > in this case, ksh and bash deviates are clearly closer to standard > bourne behaviour > Thanks for that explanation. I can understand the benefits of optimizing away subshell execution, but that can clearly lead to unexpected behavior. Is there some documentation on when this optimization is utilized (i.e. the command executed without a subshell)? Would I be correct in assuming that it is only restricted to built-in commands that are known not to produce any output, such as 'exit'? - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske wrote: > If you make the changes that I've suggested, you'll have consistent > execution. The reason you're having inconsistent behavior is because Linux > has /bin/sh symbolically linked to /bin/bash while FreeBSD has a more > traditional shell (we'll call it bourne shell "plus"). that is misleading because command substitutions have traditionally invoked subshells, and freebsd sh(1)/ash is an exception, not the norm in this case, ksh and bash deviates are clearly closer to standard bourne behaviour ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
ash tries to overoptimize by running certain command substitutions
without a subshell
On Sun, Mar 13, 2011 at 7:56 PM, Maxim Khitrov wrote:
> Hello everyone,
>
> I might be doing something dumb here, but this doesn't make sense to
> me. When I run the following script, I would expect to see no output:
>
>
> #!/bin/sh
>
> exit_prog()
> {
> echo -n 'before'
> exit 0
> echo -n 'after'
> }
>
> echo line 1: `exit_prog`
> echo line 2:
> echo line 3: `exit 1`
> echo line 4:
>
>
> The reason I expect to see no output is because 'exit 0' should be
> called before any of the echo lines are allowed to execute. Instead,
> what I get on FreeBSD 7 & 8 is:
>
>
> line 1: before
> line 2:
>
>
> I don't understand this because 'exit 0' seems to terminate the call
> to 'exit_prog', but the execution of the script continues. However,
> when 'exit 1' is called, the script terminates before printing out the
> last 2 lines.
>
> It seems that 'exit' inside a function doesn't work when that function
> is called with backquotes. I assume it has something to do with the
> fact that commands in backquotes are executed in a sub-shell, but the
> behavior is inconsistent.
>
> When I run the same script on RHEL using bash, all 4 lines are printed:
>
>
> line 1: before
> line 2:
> line 3:
> line 4:
>
>
> What's going on here?
>
> - Max
> ___
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
>
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
On Mar 13, 2011, at 5:26 PM, Maxim Khitrov wrote:
> Hello everyone,
>
> I might be doing something dumb here, but this doesn't make sense to
> me. When I run the following script, I would expect to see no output:
>
>
> #!/bin/sh
>
> exit_prog()
> {
> echo -n 'before'
> exit 0
> echo -n 'after'
> }
>
> echo line 1: `exit_prog`
> echo line 2:
> echo line 3: `exit 1`
Replace with:
echo line 3: `( exit 1 )`
This executes the command within a sub-shell (preventing the exit call from
effecting the current shell -- achieving what you desire).
> echo line 4:
>
>
> The reason I expect to see no output is because 'exit 0' should be
> called before any of the echo lines are allowed to execute. Instead,
> what I get on FreeBSD 7 & 8 is:
>
>
> line 1: before
> line 2:
>
>
> I don't understand this because 'exit 0' seems to terminate the call
> to 'exit_prog',
The function call is performed in a sub-shell (internally).
> but the execution of the script continues. However,
> when 'exit 1' is called, the script terminates before printing out the
> last 2 lines.
>
> It seems that 'exit' inside a function doesn't work when that function
> is called with backquotes. I assume it has something to do with the
> fact that commands in backquotes are executed in a sub-shell
That is incorrect. Here is a unit-test (to be performed on FreeBSD):
dteske@localhost ~ $ cat << "EOF" | /bin/sh -
> echo PS1=$PS1; : `unset PS1`; echo PS1=$PS1
> EOF
PS1=\[\e[32;1m\]\u@\H \[\e[34m\]\W \$\[\e[0m\]
PS1=
The above scriptlet does three things:
1. echo's the contents of the PS1 environment variable.
2. Executes "unset PS1" within back-ticks.
3. re-echo's the contents of the PS1 environment variable.
Upon execution, we see that despite being executed within back-ticks, the PS1
variable was wiped-out. If commands on FreeBSD under /bin/sh were executed
within a sub-shell, said sub-shell would have a separate environment that
wouldn't effect its parent. Contrast this behavior with the following scriptlet:
dteske@localhost ~ $ cat << "EOF" | /bin/sh -
> echo PS1=$PS1; : `(unset PS1)`; echo PS1=$PS1
> EOF
PS1=\[\e[32;1m\]\u@\H \[\e[34m\]\W \$\[\e[0m\]
PS1=\[\e[32;1m\]\u@\H \[\e[34m\]\W \$\[\e[0m\]
In the above, we've re-executed the same script but with one minor change --
we've placed the "unset PS1" command within parentheses, which under FreeBSD's
/bin/sh causes the creation of a sub-shell with separate environment and exit
code, etc.
You can read more on FreeBSD by searching sh(1) for "Grouping Commands
Together".
> , but the
> behavior is inconsistent.
>
> When I run the same script on RHEL using bash, all 4 lines are printed:
If you make the changes that I've suggested, you'll have consistent execution.
The reason you're having inconsistent behavior is because Linux has /bin/sh
symbolically linked to /bin/bash while FreeBSD has a more traditional shell
(we'll call it bourne shell "plus").
>
>
> line 1: before
> line 2:
> line 3:
> line 4:
>
>
> What's going on here?
>
> - Max
> ___
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
--
Cheers,
Devin Teske
-> LEGAL DISCLAIMER <-
This message contains confidential and proprietary information
of the sender, and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person is strictly prohibited. If you have received this
message in error, please notify the e-mail sender immediately,
and delete the original message without making a copy.
-> FUN STUFF <-
-BEGIN GEEK CODE BLOCK-
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E-
W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+
D+(++) G++ e> h r+++ z+++
--END GEEK CODE BLOCK--
http://www.geekcode.com/
-> END TRANSMISSION <-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Shell script termination with exit function in backquotes
On Sun, Mar 13, 2011 at 9:59 PM, Scott Ballantyne wrote:
> On Sun, Mar 13, 2011 at 8:26 PM, Maxim Khitrov wrote:
>>
>> Hello everyone,
>>
>> I might be doing something dumb here, but this doesn't make sense to
>> me. When I run the following script, I would expect to see no output:
>>
>>
>> #!/bin/sh
>>
>> exit_prog()
>> {
>> echo -n 'before'
>> exit 0
>> echo -n 'after'
>> }
>>
>> echo line 1: `exit_prog`
>> echo line 2:
>> echo line 3: `exit 1`
>> echo line 4:
>>
>>
>> The reason I expect to see no output is because 'exit 0' should be
>> called before any of the echo lines are allowed to execute. Instead,
>> what I get on FreeBSD 7 & 8 is:
>>
>>
>> line 1: before
>> line 2:
>>
>>
>> I don't understand this because 'exit 0' seems to terminate the call
>> to 'exit_prog', but the execution of the script continues. However,
>> when 'exit 1' is called, the script terminates before printing out the
>> last 2 lines.
>>
>> It seems that 'exit' inside a function doesn't work when that function
>> is called with backquotes. I assume it has something to do with the
>> fact that commands in backquotes are executed in a sub-shell, but the
>> behavior is inconsistent.
>>
>> When I run the same script on RHEL using bash, all 4 lines are printed:
>>
>>
>> line 1: before
>> line 2:
>> line 3:
>> line 4:
>>
>>
>> What's going on here?
>>
>> - Max
>
> Backquotes run the process in a sub process, that exits. and the original
> process continues.
>
Yes, my original expectation of having no output is incorrect, but
`exit 1` terminates the parent shell in FreeBSD. That's the source of
my confusion.
- Max
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
