[lug] "errexit": suggested bash manpage clarification

Jeffrey S. Haemer jeffrey.haemer at gmail.com
Sat Jan 5 23:23:07 MST 2013


Chet,

Two great minds in one great rut. :-)

(Zan Lynx even makes exactly the point about fork() that you do, near the
end of the thread I'd forwarded.)

Thank you for your perennial efforts to improve the man page. I am actually
perversely gratified to see I remain a day late and a dollar short.

On Sat, Jan 5, 2013 at 2:05 PM, Chet Ramey <chet.ramey at case.edu> wrote:

> On 1/5/13 2:03 PM, Jeffrey S. Haemer wrote:
> > Chet,
> >
> > Hope you two had as much fun for Christmas and New Year's as Kristina
> and I
> > did. I was greatly relieved, since Thanksgiving had sucked.
>
> It was good, thanks.  Sorry Thanksgiving sucked for you guys; it was
> actually really good for us this year because my brothers and their
> families both came to Ohio (from Boise and St. Paul, respectively).
>
> > I want to recommend a documentation tweak in the man page to clarify a
> > behavior.
> >
> > The motivation is a recent discussion in the Boulder Linux Users Group
> > mailing list. To make a long story short, the following command prints
> > "from subshell" :
>
> I do love how the Internet is made up of so many little fiefdoms, each
> acting independently.  In this case, you might point folks to the
> bug-bash mailing list, where the most recent episode of this very
> discussion took place only recently:
>
> http://lists.gnu.org/archive/html/bug-bash/2012-12/msg00093.html
>
> My contribution has pointers to the right Posix standards and refers to
> previous instances of the same discussion:
>
> http://lists.gnu.org/archive/html/bug-bash/2012-12/msg00102.html
>
> It's much simpler than requiring some kind of `out-of-band information
> channel' to the child: fork() creates an exact copy of the parent shell,
> including the state information saying whether or not it's executing in
> a context where set -e should be ignored.  The child doesn't have to do
> anything special to know that -- it just has to know what to do, or what
> not to do, when it finds itself in such a context.
>
> > I'll send the relevant part of the man page in a second message, along
> with
> > a suggested change.
>
> This paragraph is in the current (development branch) version of the man
> page:
>
> If a compound command or shell function executes in a context
> where \fB\-e\fP is being ignored,
> none of the commands executed within the compound command or function body
> will be affected by the \fB\-e\fP setting, even if \fB\-e\fP is set
> and a command returns a failure status.
> If a compound command or shell function sets \fB\-e\fP while executing in
> a context where \fB\-e\fP is ignored, that setting will not have any
> effect until the compound command or the command containing the function
> call completes.
>
> > Do come visit again some Wednesday night.
>
> I was in Denver for Educause this year, but only made it up to Boulder as
> far as Boulder Beer.  Maybe next time. :-)
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    chet at case.edu
> http://cnswww.cns.cwru.edu/~chet/
>



-- 
Jeffrey Haemer <jeffrey.haemer at gmail.com>
720-837-8908 [cell], http://seejeffrun.blogspot.com [blog],
http://www.youtube.com/user/goyishekop [vlog]
*פרייהייט? דאס איז יאַנג דינען וואָרט.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20130105/81145f0b/attachment.html>


More information about the LUG mailing list