Why would the user set BASH_VERSION in the environment? That sounds like asking
for trouble!
If you're against someone who actively tries to fool you into thinking you're
in bash, then it'll be very hard.
One way that I think would work is to:
- try to unset BASHOPTS (did it work? then it's not
On Fri, Mar 27, 2015 at 11:36 AM, Christoph Anton Mitterer
cales...@scientia.net wrote:
Hey.
There are a lot of articles on the web about detecting the actually
running shell.
Unfortunately, just relying on $SHELL doesn't really work since when I
invoke e.g. csh from bash, it would be
On 3/26/15 8:28 PM, Christoph Anton Mitterer wrote:
So why not make a thrid mode like:
- if cmdhist=on lithist=not-in-file
which keeps:
if true; then\n
echo foo\n
fi
in the history
but writes the serialised if true; then echo foo ; fi to the history
file.
Because
On 03/27/2015 01:56 AM, Andreas Schwab wrote:
Christoph Anton Mitterer cales...@scientia.net writes:
There are a lot of articles on the web about detecting the actually
running shell.
Why do you need to know that?
As the autoconf world has proven, it's better to test for features (will
I just test for version strings. e.g. BASH_VERSION. It isn't ideal or
robust but gets the job done depending on your requirements. There is
no generally great solution.
There are scripts that make better guesses but there aren't any that
are meant for use in a library or that do fine-grained
On Fri, 2015-03-27 at 01:44 -0600, Eduardo A. Bustamante López wrote:
Why would the user set BASH_VERSION in the environment? That sounds like
asking
for trouble!
Murphy's law! :D
- try to unset BASHOPTS (did it work? then it's not bash)
- Now, store the value of BASHOPTS in a temp var
-
On Fri, Mar 27, 2015 at 2:37 PM, Christoph Anton Mitterer
cales...@scientia.net wrote:
On Fri, 2015-03-27 at 01:44 -0600, Eduardo A. Bustamante López wrote:
Why would the user set BASH_VERSION in the environment? That sounds like
asking
for trouble!
Murphy's law! :D
- try to unset BASHOPTS
On Fri, 2015-03-27 at 15:11 -0400, Greg Wooledge wrote:
OK, this is for some personal configuration management.
Well it's rather for some 1000 institute workstations,...
Not as part of
a product you're deploying, etc. As such, presumably you are not trying
to trick yourself into breaking
On Fri, 2015-03-27 at 08:56 +0100, Andreas Schwab wrote:
Why do you need to know that?
Well there are so many use cases... my particular one is, that many
shells share config files (e.g. .profile) and for other cases (e.g.
aliases definitions) it would be handy if one could set up a sourcable
On Fri, Mar 27, 2015 at 07:46:19PM +0100, Christoph Anton Mitterer wrote:
- keeping a complex test suite for many cases up-to-date is not so easy
- since .bashrc and friends are e.g. sourced everytime I start a new
xterm, I'd rather try to avoid having extensive tests there
... why are you
On Fri, 2015-03-27 at 14:56 -0400, Greg Wooledge wrote:
... why are you running test suites in your .bashrc??
As said, I'd find it nice to have one aliases file for all shells, and
that would in turn then be sourced from either .profile or
rather .bashrc... so while tests wouldn't run in
On Fri, Mar 27, 2015 at 08:05:29PM +0100, Christoph Anton Mitterer wrote:
On Fri, 2015-03-27 at 14:56 -0400, Greg Wooledge wrote:
... why are you running test suites in your .bashrc??
As said, I'd find it nice to have one aliases file for all shells, and
that would in turn then be sourced
Bash 4.3 with or without additional patches up to 033.
Compiler: gcc 4.8.3 and 4.9.2
hardware: ESXi5.5 i7-3930K
OS: linux LFS / CLFS / Ubuntu 14.04.2 LTS
Cross compiled from linux ix86 to run in linux x86_64
When configured with no configure overrides it uses defaults configure provides
when
13 matches
Mail list logo
