Re: Shell script termination with exit function in backquotes
On Sat, 19 Mar 2011 09:44:57 -0700
Devin Teske dte...@vicor.com 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
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 dteske at vicor.com 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 31 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 Tue, 2011-03-22 at 12:32 +, RW wrote:
On Sat, 19 Mar 2011 09:44:57 -0700
Devin Teske dte...@vicor.com 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
in freebsd-questions Digest, Vol 354, Issue 10, Message: 4
On Sat, 19 Mar 2011 12:15:26 -0400 Maxim Khitrov m...@mxcrypt.com 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 Mon, Mar 14, 2011 at 6:40 PM, Andres Perera andre...@zoho.com wrote:
On Mon, Mar 14, 2011 at 7:46 AM, Maxim Khitrov m...@mxcrypt.com wrote:
On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera andre...@zoho.com wrote:
On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske dte...@vicor.com 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 Mar 19, 2011, at 9:15 AM, Maxim Khitrov wrote:
On Mon, Mar 14, 2011 at 6:40 PM, Andres Perera andre...@zoho.com wrote:
On Mon, Mar 14, 2011 at 7:46 AM, Maxim Khitrov m...@mxcrypt.com wrote:
On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera andre...@zoho.com wrote:
On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske dte...@vicor.com 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 Sat, Mar 19, 2011 at 12:44 PM, Devin Teske dte...@vicor.com wrote:
On Mar 19, 2011, at 9:15 AM, Maxim Khitrov wrote:
On Mon, Mar 14, 2011 at 6:40 PM, Andres Perera andre...@zoho.com wrote:
On Mon, Mar 14, 2011 at 7:46 AM, Maxim Khitrov m...@mxcrypt.com wrote:
On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera andre...@zoho.com wrote:
On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske dte...@vicor.com 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
Maxim Khitrov m...@mxcrypt.com 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 11:45 AM, Maxim Khitrov m...@mxcrypt.com 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
ash tries to overoptimize by running certain command substitutions
without a subshell
On Sun, Mar 13, 2011 at 7:56 PM, Maxim Khitrov m...@mxcrypt.com 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 Sun, Mar 13, 2011 at 9:49 PM, Devin Teske dte...@vicor.com 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
On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera andre...@zoho.com wrote: On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske dte...@vicor.com 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 Mon, Mar 14, 2011 at 7:46 AM, Maxim Khitrov m...@mxcrypt.com wrote: On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera andre...@zoho.com wrote: On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske dte...@vicor.com 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
Shell script termination with exit function in backquotes
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
Re: Shell script termination with exit function in backquotes
On Sun, Mar 13, 2011 at 9:59 PM, Scott Ballantyne boyva...@gmail.com wrote:
On Sun, Mar 13, 2011 at 8:26 PM, Maxim Khitrov m...@mxcrypt.com 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
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
