Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Robert Elz Newsgroups: gnu.bash.bug Subject: Re: An xtrace variant Date: Mon, 29 Jun 2020 16:40:24 +0700 Lines: 66 Approved: bug-bash@gnu.org Message-ID: References: <87h7uv0zi8.fsf@hobgoblin.ariadne.com> <19208.1593423624@jinx.noi.kre.to> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: usenet.stanford.edu 1593423651 2454 209.51.188.17 (29 Jun 2020 09:40:51 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: worley@alum.mit.edu (Dale R. Worley) Envelope-to: bug-bash@gnu.org In-Reply-To: <87h7uv0zi8.fsf@hobgoblin.ariadne.com> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:3c8:9009:181::2 (deferred) Received-SPF: permerror client-ip=2001:3c8:9009:181::2; envelope-from=kre@munnari.OZ.AU; helo=munnari.OZ.AU X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01 autolearn=_AUTOLEARN X-Spam_action: no action 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: <19208.1593423624@jinx.noi.kre.to> X-Mailman-Original-References: <87h7uv0zi8.fsf@hobgoblin.ariadne.com> Xref: csiph.com gnu.bash.bug:16478 Date: Sun, 28 Jun 2020 15:19:27 -0400 From: worley@alum.mit.edu (Dale R. Worley) Message-ID: <87h7uv0zi8.fsf@hobgoblin.ariadne.com> | For a long time, I've wanted a variant of -x that only echoed the simple | commands after bash is done executing the startup files. The NetBSD sh has a -q option (probably all ash derived shells do) which inhibits -x (and -v) during processing of startup files. eschwartz@archlinux.org said: | Why not just run bash -x script-name without the bash -l option and without | $BASH_ENV set? That creates a different environment, and isn't (always) useful for debugging scripts. Sometimes it works, other times it doeesn't. Dale again: | I finally did a test implementation, naming a new switch "-X". The NetBSD sh (this time alone I believe) also has a -X (not that part, I think one or two other shells also have unrelated -X options) which acts just like -X, except it locks the output to stderr as it is at the time the -X option is enabled (until -X is unset). It also enables -x (after which -x can be enabled/disabled as neede). The idea is that it is possible to do set -X 2>/tmp/trace-file and all the -x output then goes to that file, regardless of furtre stderr redirections (-X can be used on the command line as well of course, causing the shell's startup stderr to be used). This is actually a much more useful option than -q, as in practice, inserting "set -x / set +x" into the script at relevant points tends to be more useful for anything non-trivial than simply running the whole thing with -x set - but being able to see the commands run when stderr is redirected can be very useful. | I named the new option "-X" as a mnemonic variant of "-x". That's why I picked it for mine as well... | Its long name is "Xtrace", because I couldn't think of anything better. Same here, for the same reason - but there were complaints about having names that differed only in char case, so I eventually changes it to xlock (NetBSD 8 still has Xtrace though). | The code changes are quite simple really. The ones for our -X as well, mostly mechanical, though a little more complexity in the file descriptor management area. The overall change set got bigger, as I also make the -x output show redirections, and give some info about some compound commands (there's still less about case statements than I'd like). | Is this a useful idea? Is there a better way to get an effect like | this? I suspect that the ash shell's -q is a slightly better way, as that option can be enabled by default - it simply does nothing if the shell is not run with -x (or -v) on the command line, but works any time those are. But overall, an option worth having I believe. kre