Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: John Passaro Newsgroups: gnu.bash.bug Subject: Re: local failure Date: Sun, 31 May 2020 23:57:03 -0400 Lines: 110 Approved: bug-bash@gnu.org Message-ID: References: <87tuzzh34x.fsf@hobgoblin.ariadne.com> <11340.1590942081@jinx.noi.kre.to> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: usenet.stanford.edu 1590983865 19416 209.51.188.17 (1 Jun 2020 03:57:45 GMT) X-Complaints-To: action@cs.stanford.edu Cc: Laurent Picquet , bug-bash@gnu.org, "bash@packages.debian.org" To: Robert Elz Envelope-to: bug-bash@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bn+PVy6W7Nv18CN0s5biFIGr/CMEpjF+eIxWYVbyfZg=; b=LAQCuHQ2gKZG3/MZ0Z1d0bF2UtEy0mz5JwVTn3MqhNlfFYjqls73SDC6S2KaubNqg8 GON3GT54uT5NWARm96phxGWhOZI3YEJL00Lc63/oJ3OWOPHLyN1Srlg3cwb4DLuYnseu kvGFY6Mgy+stnoPwVebLIae88sZwD5mWyxNh1jwG0yUQDQ4ZCLHQDC51oZEdpB/dDird JNagxLvzajy924hoH6w3xkfAuaoono8SJU9BUzAU/Ftxg7xbWF6fF4FlQrb5EalMj6tQ o2KetM5Citv7HEgPAFmQWav05Sd4nWiXLJlaXXwVaNc66HFUAos8k3dbaGfYxh5OvmNI 87eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bn+PVy6W7Nv18CN0s5biFIGr/CMEpjF+eIxWYVbyfZg=; b=RJqo2mbTDkWQ9jJ0quIsWqsqwjL9G/VPvddnlKWONPnj3XP6VbNXk8S8wdEBUNWKyB NxujE0KgpKs2NLSgZQOIQezN01rmXe99GZv6i3rUGrLCWIxXRq/73uO5tlXbssBLtk8f GgoVGLcwMfozRt72f9dpQBQlZl97ZCf32XoPZ52ayhJJZfKUindPrQS5t945iJTSbkvV pHAqu9Y+xOGKQSFF7ZfWwLC5XMvZChPFM5dtadjSlzwaAgXUuI10c6McnfXqvnGJCnom CKbSBorZ0ISP0xbLmRgMLhJyx9LpbE7i3ZvHzdwe+TNGBvtjc6uYeYqd3dztkYpvk3GG vOLQ== X-Gm-Message-State: AOAM531pGaiFYTT9OerJ+HYZ+Lo+pXYgs8a0kPMlmvfXG6yuKa2lB8RZ XFSszvKY2QRDlvofK2z65bIInC36foiVrFOp1+s= X-Google-Smtp-Source: ABdhPJxZsNcqnm2HIjKio0Q3cWFcFEwh4OSBjemHfeEOZGJwY/PU4WkUTnk8J2nelxe8dwG9i52OArN6BHVGWnDZYHA= X-Received: by 2002:a92:2907:: with SMTP id l7mr19494011ilg.48.1590983860040; Sun, 31 May 2020 20:57:40 -0700 (PDT) In-Reply-To: <11340.1590942081@jinx.noi.kre.to> Received-SPF: pass client-ip=2607:f8b0:4864:20::135; envelope-from=john.a.passaro@gmail.com; helo=mail-il1-x135.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: <87tuzzh34x.fsf@hobgoblin.ariadne.com> <11340.1590942081@jinx.noi.kre.to> Xref: csiph.com gnu.bash.bug:16333 I think the underlying question here is not exactly "how do I gather this from the docs" as much as it is "how was I supposed to know about this and act on it before I had to debug it?" The bash manual is always "adequate" in the sense that almost any question can be answered by carefully consulting it -- but that doesn't help the person who either is unpracticed at the occasionally arcane art of *reading* the bash manual, or who doesn't even know they need to ask a question (let alone how to articulate it). I've been consulting the bash manual for nearly a decade but I still find myself in this position every now and then. That's why I want to plug linting your shell scripts, preferably in your text editor. You'll catch a lot of problems before they happen and just get better at shell scripting. My preferred tool, ShellCheck ( https://github.com/koalaman/shellcheck), alerted me to this problem a couple of years ago, and lots, lots, lots more. It incorporates into Vim easily via the plugin "Syntastic"; I'm sure it's easy to incorporate for other text editors as well. On Sun, May 31, 2020 at 12:37 PM Robert Elz wrote: > Date: Sun, 31 May 2020 10:29:27 +0100 > From: Laurent Picquet > Message-ID: 0wg33X5paJpEg@mail.gmail.com> > > | This behaviour is not fully documented > > Nothing is ever "fully" documented, as it is always possible to > write even more text about anything at all - and if that were done > then it is clear that what existed before was not "full". > > So, instead of "fully documented" let's use "adequately documented" > and for that it is. > > But you do need to understand how things fit together to follow. > > First, the exit status is only ever set as the result of executing > a command - and only a command in the current execution environment. > > ? Expands to the exit status of the most recently executed > foreground pipeline. > > [elsewhere it is noted that a simple command is a degenerate pipeline, > so is a compound command for that matter.] > > "local" is such a command, and like all such commands, its exit status > is documented... > > The return status is 0 unless local is used outside a > function, an invalid name is supplied, or name is a readonly > variable. > > (that text has been previously quoted in this thread). > > Command substitutions execute in a different shell execution environment > (nothing that happens in one has any effect upon the shell that contains > them - except that stdout from the command substitution is inserted into > the current command line (and then potentially subject to field splitting, > pathname expansion, ...) -- it becomes a part of some other command. > > There is one exception to the case that only commands in the current > execution environment ever set the exit status, which is documented in > bash(1) as ... > > If there is a command name left after expansion, execution proceeds > as > described below. Otherwise, the command exits. If one of the > expansions contained a command substitution, the exit status of the > command is the exit status of the last command substitution > performed. > If there were no command substitutions, the command exits with a > status > of zero. > > None that neither redirects nor variable assignments are commands (but > almost everything else that you would write in a sh script is, including > "local"). The "as described below" involves locating the command, running > it, and obtaining its exit status - and is what is done when there is a > command. > > When there isn't - which is what happens when all there was was > variable assignments &/or redirects - then, and only then, does the: > > If one of the expansions contained a command substitution, the > exit status of the command is the exit status of the last command > substitution performed. > > This is the only way that the exit status of a command substitution can > ever be observed in the parent shell. But you have to read the entire > man page to observe that nowhere else is the status of a command > substitution > ever reported. > > So, the doc is all there, and it is possible to work out what happens. > > As above, it is always possible to write more - but write too much, and > instead of a manual page, what would be left would be a tutorial, or > perhaps > even a book (but there's already one, perhaps more than one, of those). > > There is certainly nothing special about the local command in this context, > any command where there happens to be a command substitution on the command > line somewhere works exactly the same way, so it would be wrong to make any > special note of this in the doc for "local" without also putting the same > extra info in the descriptions of every other command. > > kre > > >