Re: Detecting Redirection in Bash

[Carol Anne Ogdin]

Thanks for the hints, Paul; I think I can carry it from here.

--Carol Anne

Carol Anne Ogdin	http://www.net-working.com	530/295-3657
Deep Woods Technology, Inc.	http://www.deepwoods.com	CAOgdin@deepwoods.com
Leveraging technology to restore the soul of the organization

prj@po.cwru.edu (Paul Jarc) 03/11/2003 04:31 PM

To:        Carol Anne Ogdin <caogdin@deepwoods.com>         cc:        bug-bash@gnu.org         Subject:        Re: Detecting Redirection in Bash

Carol Anne Ogdin <caogdin@deepwoods.com> wrote:
> 1.  At http://mail.gnu.org/mailman/listinfo/bug-bash I read "User
> discussion of BASH also occurs here.."  If the policy has changed,
> you might want to have GNU.org change the information at that page.

I'm not a maintainer or list admin, so I could be wrong.  Regardless,
comp.unix.shell is at least one good place for help with writing
scripts.

> 2.  I understand that if I don't do any redirection at all,
> everything is sent to the system stdout (and stderr, which is
> nominally /dev/tty.  However, what I'm trying to accomplish is to
> send the output to a file (not a device), so I can process is for
> debugging information.

I understand what you want, and I'm telling you that you can do that
by not using any redirections at all.  Have you actually tried that?
If it doesn't work, then that's a bug.

There is no such concept as the "system" stdout/stderr.  Each process
has its own stdout/stderr, inherited from its parent.  If you redirect
stdout for bash, that new stdout will be inherited by any later
programs run by bash, unless you also do individual redirections for
them.

> Perhaps there's a way in bash to change the definition of stdout
> without redirection that could perform the function I need?  That
> could be risky, of course, because should the script abort, there'd
> be no automatic way to restore the stdout => /dev/tty definition.

There is indeed a way for a script to redirect its own file
descriptors.  (See `help exec`.)  It's not as dangerous as you think,
because this only affects the script and later programs run by it; the
interactive shell you started the script from is outside the script's
control.


paul