Re: definite way to determine the running shell
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 bash)
- Now, store the value of BASHOPTS in a temp var
- Set a shopt option that's not set already in BASHOPTS (or unset one from
BASHOPTS)
- Check if the value of BASHOPTS changed.
This would be one way to make sure you're really in bash, even when someone is
trying to fool you.
Another way would be to create a battery of tests of behavior that's unique to
bash, in stuff that's not specified by POSIX, or that its specification is a
bit ambiguous. One example of this is:
dualbus@yaqui ~ % for sh in bash mksh zsh ksh93 dash; do $sh -c
't=${KSH_VERSION+typeset}; f() { x=3; ${t:-local} x; echo $x; }; [ $(f) =
$(x=4 f) ]'; echo $sh $?; done
bash 1
mksh 0
zsh 0
ksh93 0
dash 0
That's a case where it'd be hard to fake that you're bash.
--
Eduardo Bustamante https://dualbus.me/
Re: definite way to determine the running shell
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 still $SHELL=bash and I guess I won't be able to convince all shell upstreams to overwrite $SHELL (which IMHO would be much better, and more like $TERM). Now I see basically two other ways to detect a shell: a) using ps or something similar... which is not really portable either and can be rather easily/accidentally fooled b) Using some env vars typically to the shell, e.g. BASH_VERSION for bash. AFAIU per default these are not declared'ed -x , so when I rund fooShell from bash it wouldn't be inherited. But the user could still manually mark it exportable. c) I've also thought about somehow using e.g. shopt, when it runs I could be sure, it was bash. But for that in turn I'd need to make sure whether it's a built-in command, which works in bash with the builtin built in command ;) ... but not portably as in POSIX shell command language (at least not that I'd know). Is there some better way to do this (at least to detect bash)? E.g. some VAR that bash sets and that it would neither take from its own environment when being started nor that it would pass on to processes? For bash I think you can just check $BASH_VERSION. Also see Sven Mascheck's whatshell: http://www.in-ulm.de/~mascheck/various/whatshell/ . -clark Thanks, Chris.
Re: feature-request: don't count history time comment lines when in HISTFILESIZE
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 there are a number of keywords and metacharacters that can be followed by a newline but not a semicolon (e.g. `while'). There's just not a one-for-one correspondence. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: definite way to determine the running shell
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 THIS action work?) than for versions (am I on shell XYZ version ABC?). Rather than figuring out is this script running under bash, focus on what can I test up front to learn if the rest of my script can rely on a certain feature being present, repeated for each feature that is not in common to all shells. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: definite way to determine the running shell
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 feature detection. Something like that is on my todo list for some day. https://www.mirbsd.org/cvs.cgi/contrib/code/Snippets/getshver?rev=HEAD http://www.in-ulm.de/~mascheck/various/whatshell/whatshell.sh.html http://stchaz.free.fr/which_interpreter -- Dan Douglas
Re: definite way to determine the running shell
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 - Set a shopt option that's not set already in BASHOPTS (or unset one from BASHOPTS) - Check if the value of BASHOPTS changed. that sounds like a nice idea. I just thought about another solution myself PATH= shopt then only a shell having shopt (hopefully that is just bash) should give $?=0 . Thanks, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: definite way to determine the running shell
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 (did it work? then it's not bash) - Now, store the value of BASHOPTS in a temp var - Set a shopt option that's not set already in BASHOPTS (or unset one from BASHOPTS) - Check if the value of BASHOPTS changed. that sounds like a nice idea. This might not be a great idea. Even if it works now it's not future-proof. Some shells have implemented BASH-prefixed variables for the sake of compatibility. I understand why they did it and don't think it was a bad idea, it just means you can't rely on their presence to mean you're using bash. ksh93's bash mode and mksh both have examples of this $ exec -a bash ksh -c 'typeset -p' | grep BASH BASH=bash BASH_EXECUTION_STRING='typeset -p' typeset -r -a BASH_VERSINFO=(4 2 0 0 ksh93 i386-unknown-linux) BASH_VERSION='4.2.0(0)-ksh93' typeset -n BASH_REMATCH='.sh.match[0]' typeset -n BASH_SOURCE=file typeset -n BASH_SUBSHELL=subshell $ mksh -c 'typeset -p' | grep BASH typeset -i -U BASHPID=1207 -- Dan Douglas
Re: definite way to determine the running shell
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 your own logins or shell startups. ... and you never really know what strange thins users accidentally do ;) So, just check for $BASH_VERSION and you should be all right. Sure,... I just wanted to as, whether there's maybe a much more obvious fool-proof solution :) Though, if it were me, I'd just simplify everything. Don't use so many different shells, don't use such complicated aliases that you have to have multiple versions of them I personally just use bash (except for sh where it's dash)... but see above :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: definite way to determine the running shell
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 script, which does the necessary stuff, automatically in the way for the current shell. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: definite way to determine the running shell
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 running test suites in your .bashrc??
Re: definite way to determine the running shell
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 .bashrc itself, they'd always be executed along. smime.p7s Description: S/MIME cryptographic signature
Re: definite way to determine the running shell
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 from either .profile or rather .bashrc... so while tests wouldn't run in .bashrc itself, they'd always be executed along. OK, this is for some personal configuration management. Not as part of a product you're deploying, etc. As such, presumably you are not trying to trick yourself into breaking your own logins or shell startups. So, just check for $BASH_VERSION and you should be all right. Though, if it were me, I'd just simplify everything. Don't use so many different shells, don't use such complicated aliases that you have to have multiple versions of them
bash 4.3 cross compile with default configure has broken [ in subshell
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 cross compile detected. The resulting executable has issues with the builtin [ when used in a subshell. It works the first time but then always returns 0 thereafter. E.g: # ./bash4.3.33 # ( [ -z 3 ] ;echo $? ) 1 # ( [ -z 3 ] ;echo $? ) 0 # ( [ -z 3 ] ;echo $? ) 0 # [ -z 3 ] ;echo $? 1 # [ -z 3 ] ;echo $? 1 # [ -z 3 ] ;echo $? 1 It works correctly when using the config.cache settings detailed here: http://clfs.org/view/git/ppc64/temp-system/bash.html Best regards Barry Davis
