home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!cis.ohio-state.edu!tct.COM!chip
- From: chip@tct.COM (Chip Salzenberg)
- Newsgroups: gnu.bash.bug
- Subject: Re: always execute .bashrc
- Date: 25 Jan 1993 20:23:33 -0500
- Organization: GNUs Not Usenet
- Lines: 31
- Sender: daemon@cis.ohio-state.edu
- Approved: bug-bash@prep.ai.mit.edu
- Distribution: gnu
- Message-ID: <m0nFx9F-0000XBC@animal.tct.com>
- References: <9301231334.AB08895@bears.ece.ucsb.edu>
-
- Quoting Brian Fox:
- > You are right, I do not see how that is a bug. Vis a vis rsh and
- > desireable interactive behaviour, you cannot have your cake and eat it
- > too.
-
- Of course! It _is_ impossible for bash to decide whether it is run
- from rsh or not.
-
- Therefore, I would suggest that rsh be configured or hacked to run
- something other than $SHELL -- $SHELL.rc perhaps. So /bin/bash.rc
- would use a new "please run the .bashrc file" option:
-
- #!/bin/sh
- SHELL=/bin/bash; export SHELL
- exec /bin/bash -rc ${1+"$@"}
-
- Failing the ability to hack rsh, I'd arrange for the above script to
- be the login `shell' of all bash users. Therefore, login shells and
- rsh shells would always get .bashrc and no others would.
-
- > > bsh -norc -c 'wc' < random.file
- >
- > Your example is the one instance where "-c" is specified, the input
- > stream is not a tty, and, for some unspecified reason, you do not wish
- > to run .bashrc.
-
- If consistency means nothing to you, then of course this inconsistency
- in your creation won't bother you. I'm just glad I have source code.
- --
- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <73717.366@compuserve.com>
-
-