Re: How to detect bash?
On 10/10/06, mwoehlke [EMAIL PROTECTED] wrote:
Anyone have any clever, VERY reliable tricks for detecting if the
current shell is bash?
Well, I don't know if it's clever, but how about:
$ if [ ${SHELL//*/bash} = bash ]; then echo y; fi
But better to use the hash-bang and make SURE the shell is Bash.
Dave
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to detect bash?
On Tue, Oct 10, 2006 at 05:12:07PM -0500, mwoehlke wrote:
Dave Rutherford wrote:
On 10/10/06, mwoehlke [EMAIL PROTECTED] wrote:
Anyone have any clever, VERY reliable tricks for detecting if the
current shell is bash?
Well, I don't know if it's clever, but how about:
Oh, my... Where do I *start*?
$ if [ ${SHELL//*/bash} = bash ]; then echo y; fi
$ echo $SHELL
/bin/sh
$ echo $BASH
/bin/bash
$ foo
bash: foo: command not found
There is *ABSOLUTELY* no guarantee that $SHELL correctly points to bash,
or that $SHELL is even remotely correct for that matter. This is /worse/
than relying on $BASH.
But it does bring up an interesting possibility:
[ `/dev/null 21` = bash: /dev/null: Permission denied ]
[...]
You quest looks a bit pointless to me. What prevents the user to
edit a copy of your script to remove the check anyway?
$ zsh -c 'echo `/dev/null 21`' bash
bash: /dev/null: Permission denied
$ zsh
$ ARGV0=bash ash -c 'echo `/dev/null 21`; echo $BASH'
bash: /dev/null: Permission denied
$ echo '/dev/null(){echo bash: /dev/null: Permission denied}' \
~/.zshenv
$ zsh -c 'echo `/dev/null 21`'
bash: /dev/null: Permission denied
And whatever check you do can be worked around in a way or
another.
--
Stéphane
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to detect bash?
Stephane Chazelas wrote:
On Tue, Oct 10, 2006 at 05:12:07PM -0500, mwoehlke wrote:
Dave Rutherford wrote:
On 10/10/06, mwoehlke [EMAIL PROTECTED] wrote:
Anyone have any clever, VERY reliable tricks for detecting if the
current shell is bash?
Well, I don't know if it's clever, but how about:
Oh, my... Where do I *start*?
$ if [ ${SHELL//*/bash} = bash ]; then echo y; fi
$ echo $SHELL
/bin/sh
$ echo $BASH
/bin/bash
$ foo
bash: foo: command not found
There is *ABSOLUTELY* no guarantee that $SHELL correctly points to bash,
or that $SHELL is even remotely correct for that matter. This is /worse/
than relying on $BASH.
But it does bring up an interesting possibility:
[ `/dev/null 21` = bash: /dev/null: Permission denied ]
[...]
You quest looks a bit pointless to me. What prevents the user to
edit a copy of your script to remove the check anyway?
$ zsh -c 'echo `/dev/null 21`' bash
bash: /dev/null: Permission denied
$ zsh
$ ARGV0=bash ash -c 'echo `/dev/null 21`; echo $BASH'
bash: /dev/null: Permission denied
Eh? I get:
$ zsh -c 'echo `/dev/null 21`' bash
zsh:1: permission denied: /dev/null
$ ARGV0=bash ash -c 'echo `/dev/null 21`; echo $BASH'
/dev/null: permission denied
So neither of your counter-examples is working for me (although both
look like they *should*; go figure). But since you didn't counter
BASH_SUBSHELL (and since I'm too lazy to change it now) I guess I'll
stick with that. :-)
Clearly the exact output depends on the version/flavor of the shell,
meaning that relying on verbatim output like this might not work (I
didn't test against any 2.x bash's). Whereas BASH_SUBSHELL ought to be
safer w.r.t. false negatives.
This is a fascinating discussion though; thanks (to Dave R., also) for
the input!
$ echo '/dev/null(){echo bash: /dev/null: Permission denied}' \
~/.zshenv
$ zsh -c 'echo `/dev/null 21`'
bash: /dev/null: Permission denied
And whatever check you do can be worked around in a way or
another.
True, but the main point of the exercise is to go with a check that's
unlikely to be worked around by accident. If someone intentionally
circumvents the check (and you're right, editing the script would be
easy), well then they deserve whatever happens. But I *am* paranoid
enough to not trust that $BASH is never set - other than by bash - for
some reason. Or that it hasn't been *unset* (since that seems to kill it
forever), because we have 'clean environment' scripts that would do this
sort of thing.
--
Matthew
KDE: Desktop Excellence
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to detect bash?
On 10/10/06, mwoehlke [EMAIL PROTECTED] wrote: Completely non-workable. That only works if the bash I want is in /bin/bash Well, no. It works as long as the last thing in the path is 'bash'. It could be /usr/bin/bash, /home/bin/bash, or yes, /bin/bash. But why the heck don't you know, if these systems are under your control? And why the heck do you think this is is *bug* in *bash*? Dave ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to detect bash?
Dave Rutherford wrote: On 10/10/06, mwoehlke [EMAIL PROTECTED] wrote: Completely non-workable. That only works if the bash I want is in /bin/bash Well, no. It works as long as the last thing in the path is 'bash'. It could be /usr/bin/bash, /home/bin/bash, or yes, /bin/bash. But why the heck don't you know, if these systems are under your control? I have root access, but they aren't my systems; rampantly changing them would Not Be Appreciated. And since when does '#! /bin/bash' mean use whatever 'bash' you find in $PATH? Silly me, I thought it meant use '/bin/bash'. I *probably* want '/home/install/gnu/arch/bin/bash' (note the *non-constant* in that path), but not on my desktop. Plus, part of the goal is for *other* people - who like me also may not have /home/install (and whose computers I don't have /any/ access to) - to be able to run the script. The point is that about the only shebang you can rely on is /bin/sh, which rarely gets you what you actually *want*. There is almost always *some* shell at /bin/sh. It is often not the optimal one. Over here, we have *long* known that shebangs do not make for portable scripts. Instead I use the current shell, but come up with this little trick to make sure it's bash. And why the heck do you think this is is *bug* in *bash*? Um, did I say I did? I didn't see a not-bugs list, and I'm not the first one to ask a 'How do I...' question here. -- Matthew KDE: Desktop Excellence ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
exec 10- does not close fd 10
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-redhat-linux-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
uname output: Linux doe 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:48:20 EST 2006
x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 3.1
Patch Level: 7
Release Status: release
Description:
While the exec command can be used with the special redirection
expression to close any of file descriptors 0-9, it does not work with
file descriptors of two or more digits. Other redirection syntax
*does* work with these, so it seems unlikely this is intentional.
Repeat-By:
lsof-self() { lsof -p $$ || ls -l /proc/self/fd; }
exec 9/dev/null 10/tmp/bash-exec-fd-bug
lsof-self # to see that fd 9 and 10 are open
exec 9- 10-
lsof-self # to see that fd 9 is now closed, but 10 is still open
# at this point, a bash-3.0 shell has (correctly) closed fds 9 10
# but a bash-3.1 shell has only close fd 9; but other redirection with
# double-digit-descriptors does work with bash-3.1, as shown below:
exec 1110-
lsof-self # to see that fd 10 (/tmp file) has moved to fd 11
exec 911-
lsof-self # to see that fd 11 (/tmp file) has moved to fd 9
exec 9- # now we can close the fd!
Fix:
I don't have a fix for this, but I do have a workaround, which is to
use the file descriptor move operation to move the fd to a single-digit
descriptor number, and then close that, as shown at the end. The only
catch is that *moving* an already closed fd is an error, while closing
an already closed fd is not, so I have to make sure it is open (using
/proc/self/fd/) first.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Tilde expansion not performed during variable evaluation
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: darwin8.7.1 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='darwin8.7.1' -DCONF_MACHTYPE='i386-apple-darwin8.7.1' -DCONF_VENDOR='apple' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include -I./lib -I./lib/intl -I/Users/ether/Desktop/bash-3.1/lib/intl -g -O2 uname output: Darwin hostname-obfuscated 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 Machine Type: i386-apple-darwin8.7.1 Bash Version: 3.1.17 Patch Level: 0 Release Status: release Description: Tilde expansion is not being performed when variables are being evaluated. Repeat-By: mkdir -p testdir/a/gooddir mkdir -p \~/testdir/a/baddir export TEST_VARIABLE=~/testdir/a ls $TEST_VARIABLE expected output: gooddir actual output:baddir (Note that if TEST_VARIABLE is assigned without surrounding quotes, tilde expansion will be done at assignment time, e.g. the variable will be assigned /home/userid/testdir/a rather than ~/testdir/a.) -- Discovery consists of looking at the same thing as everyone else does and thinking something different. - Albert Szent-Gyorgyi, 1937 Nobel Prize Winner . ... . Karen Etheridge, [EMAIL PROTECTED] GCS C+++$ USL+++$ P+++$ w--- M++ http://etheridge.ca/ PS++ PE-- b++ DI e++ h(-) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to detect bash?
mwoehlke wrote:
Anyone have any clever, VERY reliable tricks for detecting if the
current shell is bash? The obvious way is '[ -n $BASH ]', but in the
I would probably avoid the clever and go with the simple to understand
and unlikely to be accidentally invoked method.
test ${BASH_VERSION+set} = set echo yes || echo no
Sure someone could work around it but they are unlikely to do so. And
if they want to work around it as has been noted then they could
always edit the script.
And I agree with you that pattern matching against $SHELL does not
work. It is often not the shell that is currently running.
SHELL=/bin/csh bash -c 'printenv SHELL'
/bin/csh
And why the heck do you think this is is *bug* in *bash*?
Um, did I say I did? I didn't see a not-bugs list, and I'm not the first
one to ask a 'How do I...' question here.
Your question was specific to bash and so I think it is perfectly good
and on topic here. I specifically mention because I called another
poster about that just recently.
Bob
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to detect bash?
mwoehlke [EMAIL PROTECTED] wrote: And since when does '#! /bin/bash' mean use whatever 'bash' you find in $PATH? Silly me, I thought it meant use '/bin/bash'. Dave did say hash-bang, but he didn't say #! /bin/bash. Possibly he's thinking of #!/usr/bin/env bash, which should do what you want. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Tilde expansion not performed during variable evaluation
Karen Etheridge [EMAIL PROTECTED] wrote: Tilde expansion is not being performed when variables are being evaluated. That's normal, documented behavior. man bash, EXPANSION: The order of expansions is: brace expansion, tilde expansion, parameter, variable and arithmetic expansion and command substitution (done in a left-to-right fashion), word splitting, and pathname expansion. So after parameter expansion, it's too late for tilde expansion. If you know that tilde is the only special character in your variable, you could use eval to pass it through a second round of expansion. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
