Path: csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Greg Wooledge Newsgroups: gnu.bash.bug Subject: Re: foo | tee /dev/stderr | bar # << thanks! Date: Tue, 7 Jul 2020 07:47:32 -0400 Lines: 30 Approved: bug-bash@gnu.org Message-ID: References: <202007041842.064Ig08v3769297@epjdn.zq3q.org> <87k0zgxfl4.fsf@hobgoblin.ariadne.com> <20200707114151.GE22833@eeg.ccf.org> <20200707114732.GG22833@eeg.ccf.org> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: usenet.stanford.edu 1594122458 30547 209.51.188.17 (7 Jul 2020 11:47:38 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org Mail-Followup-To: bug-bash@gnu.org Content-Disposition: inline In-Reply-To: <20200707114151.GE22833@eeg.ccf.org> User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: none client-ip=139.137.100.1; envelope-from=wooledg@eeg.ccf.org; helo=mail.eeg.ccf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/07 07:41:52 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=1, SPF_HELO_NONE=0.001, SPF_NONE=0.001 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: <20200707114732.GG22833@eeg.ccf.org> X-Mailman-Original-References: <202007041842.064Ig08v3769297@epjdn.zq3q.org> <87k0zgxfl4.fsf@hobgoblin.ariadne.com> <20200707114151.GE22833@eeg.ccf.org> Xref: csiph.com gnu.bash.bug:16549 On Tue, Jul 07, 2020 at 07:41:51AM -0400, Greg Wooledge wrote: > On Mon, Jul 06, 2020 at 09:45:59PM -0400, Dale R. Worley wrote: > > bug-bash@trodman.com writes: > > > foo | tee >(cat >&2) | bar > > > > I do wonder how portable >( ... ) is in practice, versus the portability > > of /dev/stderr. Maybe I worry about the former because I'm not > > practiced in named-FIFO programming and so think of it as non-universal. > > On Linux and BSD systems, >( ) will use a /dev/fd/ entry. On most > commercial Unix systems, where /dev/fd/ does not exist, it will use a > named pipe in /var/tmp. On a hypothetical system where neither one is > available (Microsoft Windows?), I believe it may use a temp file. That > decision is made at bash's compile time. > > The semantics of /dev/fd/* and named pipes are not quite identical, so > if you're relying on some very *special* mechanisms, then there could > indeed be portability issues. For most scripts, however, it shouldn't > matter. Oh, the other thing I forgot to mention is that the semantics of /dev/fd/* differ between Linux and BSD. I don't have a reference available off the top of my head, but at some time in the past few years, it came up on one of the bug-bash or help-bash mailing lists -- someone's script acted differently on BSD than it did on Linux because of the different implementation of /dev/fd/ as used by a process substitution. People do *weird* shit with bash. The really surprising part is that they don't *think* it's weird.