Re: How to detect bash?
On Tue, Oct 10, 2006 at 06:14:22PM -0500, mwoehlke wrote: [...] > >$ zsh -c 'echo "`/dev/null 2>&1`"' bash > >bash: /dev/null: Permission denied > > > >$ zsh > >$ ARGV0=bash ash -c 'echo "`/dev/null 2>&1`"; echo $BASH' > >bash: /dev/null: Permission denied > > Eh? I get: > > $ zsh -c 'echo "`/dev/null 2>&1`"' bash > zsh:1: permission denied: /dev/null Well, I do get what I said with zsh 4.3.2 > $ ARGV0=bash ash -c 'echo "`/dev/null 2>&1`"; echo $BASH' > /dev/null: permission denied (note that this command must be run from zsh which uses ARGV0=... to set ash's argv[0]). You must have an older /ash/ than I have mine is one of the OpenBSD based sh ones (found on debian). > > So neither of your counter-examples is working for me (although both > look like they *should*; go figure). Though I'd bet the third one with .zshenv worked. > 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. :-) BASH_SUBSHELL is a relatively recent addition to bash. Most systems still don't have a bash3. $ bash -c 'echo "$BASH_VERSION, <$BASH_SUBSHELL>"' 2.05b.0(2)-release, <> [...] > 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. [...] Then I'd go with $BASH_VERSION as someone else suggested which is in every bash version. -- Stéphane ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bug-bash Digest, Vol 47, Issue 9
[EMAIL PROTECTED] wrote:
---
Message: 1
Date: Tue, 10 Oct 2006 16:08:05 -0500
From: mwoehlke <[EMAIL PROTECTED]>
Subject: How to detect bash?
To: bug-bash@gnu.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Anyone have any clever, VERY reliable tricks for detecting if the
current shell is bash? The obvious way is '[ -n "$BASH" ]', but in the
interest of catching idiots that set BASH to get around such a check, I
came up with:
[ "`BASH_SUBSHELL=975 ; ( echo $BASH_SUBSHELL )`" -eq 976 ]
(975 is of course an arbitrary number.)
Anyone think they know a better way (or a reason the above might not
work)? I'm guessing it can still be circumvented*, but one would have to
be specifically making an effort to do so.
(* Actually, I'm not 100% certain it can; you have to be able to run a
script upon sub-shell startup. I'm assuming that can be done, but maybe
I'm wrong...)
I have this. I don't like it, but I don't know any better.
getshelltype ()
{
#
# unfortunately, using set -o options doesn't work here
#
if typeset -Z a 2> /dev/null; then
echo ksh
else
echo bash
fi
}
___
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]> writes: > Tilde expansion is not being performed when variables are being evaluated. This is how it is supposed to be. Tilde expansion is performed before parameter expansion, as described in the manual. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to detect bash?
On Wed, 2006-10-11 at 02:38, mwoehlke wrote: > Anyone have any clever, VERY reliable tricks for detecting if the > current shell is bash? Hope, i think you can get from `/proc/$$/exe' ? -- Ramprasad B ___ 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 06:14:22PM -0500, mwoehlke wrote: [...] $ zsh -c 'echo "`/dev/null 2>&1`"' bash bash: /dev/null: Permission denied $ zsh $ ARGV0=bash ash -c 'echo "`/dev/null 2>&1`"; echo $BASH' bash: /dev/null: Permission denied Eh? I get: $ zsh -c 'echo "`/dev/null 2>&1`"' bash zsh:1: permission denied: /dev/null Well, I do get what I said with zsh 4.3.2 $ ARGV0=bash ash -c 'echo "`/dev/null 2>&1`"; echo $BASH' /dev/null: permission denied (note that this command must be run from zsh which uses ARGV0=... to set ash's argv[0]). You must have an older /ash/ than I have mine is one of the OpenBSD based sh ones (found on debian). Maybe, I never use ash or zsh (intentionally, anyway; IIRC Cygwin uses ash under the covers some time, but I never use either interactively), so I just got whatever versions came with the system (FC4). I don't doubt that you can make these work, I'm just noting that ability/method of circumventing the aforementioned test is inconsistent. :-) So neither of your counter-examples is working for me (although both look like they *should*; go figure). Though I'd bet the third one with .zshenv worked. 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. :-) BASH_SUBSHELL is a relatively recent addition to bash. Most systems still don't have a bash3. $ bash -c 'echo "$BASH_VERSION, <$BASH_SUBSHELL>"' 2.05b.0(2)-release, <> Ah, well, I have 3.1.17 builds available for 9 of 10 systems these scripts may need to run on (plus two others) and the tenth has 3.1.0. I'm not particularly concerned if I'm only catching 3.0+ versions, since that will also insulate me from anything else that is 3.0+-specific (i.e. it's OK if I use new features because I've ensured that I have them). Thanks for pointing this out, though. -- Matthew Will your shell have salvation? Only if it's Bourne Again. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to detect bash?
Paul Jarc wrote: 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. Ah! See, I've never seen that trick. :-) Thanks. Although it still relies on /usr/bin/env, which is *more* likely to be there than any permutation of bash, but I'd still be a little paranoid counting on it, at least until I've verified it. :-) Actually, I must admit there is a laziness aspect; to shebang, I would have to change about a dozen scripts, whereas the current test is in one file that all others source. :-) -- Matthew Will your shell have salvation? Only if it's Bourne Again. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to detect bash?
(Sorry for the double-post, I saw your CC and replied privately before I noticed that you did in fact send to the list also.) Ramprasad wrote: On Wed, 2006-10-11 at 02:38, mwoehlke wrote: Anyone have any clever, VERY reliable tricks for detecting if the current shell is bash? Hope, i think you can get from `/proc/$$/exe' ? That would only work on systems that have /proc/$$/exe. Some of the systems I'm running on (HP-UX, for example) don't even have /proc. (As a general comment to the replies I've seen:) I guess I am looking for a test that only uses shell built-ins. Anything else makes assumptions about the environment and system that can't always be counted on. -- Matthew Will your shell have salvation? Only if it's Bourne Again. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
builtin time
GNU bash, version 3.1.17(1)-release (x86_64-pc-linux-gnu) # builtin time bash: builtin: time: not a shell builtin ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
PIPESTATUS within assignment statements.
a=$(COMMAND1 | COMMAND2 | COMMAND3)
How can I get return status from COMMAND2?
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2
uname output: Linux pepinux 2.6.18-1-686 #1 SMP Mon Sep 25 00:42:11 UTC 2006
i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 3.1
Patch Level: 17
Release Status: release
Description:
host$ a=$(COMMAND1 | COMMAND2 | COMMAND3)
host$ echo ${PIPESTATUS[1]}
returnstatus_command2
host$
Repeat-By:
host$ a=$(COMMAND1 | COMMAND2 | COMMAND3)
host$ echo ${PIPESTATUS[1]}
Fix:
host$ set -o pipefail or anything similar
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: builtin time
Gabor Mayer wrote: GNU bash, version 3.1.17(1)-release (x86_64-pc-linux-gnu) # builtin time bash: builtin: time: not a shell builtin $ type time time is a shell keyword I don't think this is a bug, even though it feels like one. :-) 'time' is a keyword like 'if', 'for', 'do', 'function', etc. (see RESERVED KEYWORDS in the manpage). Why do you need to invoke it with 'builtin', anyway? -- Matthew Will your shell have salvation? Only if it's Bourne Again. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: PIPESTATUS within assignment statements.
> a=$(COMMAND1 | COMMAND2 | COMMAND3)
>
> How can I get return status from COMMAND2?
a=$(COMMAND1 | COMMAND2 | COMMAND3 ; exit ${PIPESTATUS[1]} )
c2exit=$?
This will get you what you want in the majority of cases.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
bash 3.2 match operator problem
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include\ -I./lib -O2 -march=i586
-mtune=i686
uname output: Linux zappaman.cs.buu.ac.th 2.6.16.29 #1 Sat Sep 16 13:10:25
ICT 2006 i686 pentium3 i386 GNU/Linux
Machine Type: i586-pc-linux-gnu
Bash Version: 3.2
Patch Level: 0
Release Status: release
Description:
I just upgraded to bash 3.2 and my scripts quit working for matching.
The test case below will say 'Life is good' in bash 3.1.17, but on bash
3.2 I get 'Upgrade of doom returns 2 from match' instead.
The bash.info manual does not include examples for regex. The man
page they refer to does not include examples for regex. I am
aware perhaps my regex is imperfect, but hopefully this testcase
can show you easily what I expected, and it did work for bash 3.1.17.
I am willing to recode the script, but I need help to know how
the '=~' behaves in the new bash 3.2 version, and how to modify
this script to populate BASH_REMATCH with element 1 as
jbig2dec, element 2 as 0.9, element 3 as i586, and element 4
as 001, just as it worked well with bash 3.1.17
Repeat-By:
#!/bin/bash
set -u
echo "testcase running under ${BASH_VERSION}"
OLDCANDIDATE="/tmp/jbig2dec-0.9-i586-001.tgz"
OLDCANDIDATE="${OLDCANDIDATE##*/}" # remove leading path
[[ "${OLDCANDIDATE}" =~ "([^-]+)-([^-]+)-([^-]+)-0*([1-9][0-9]*)\.tgz" ]]
REZ=$?
case ${REZ} in
0) STEM="${BASH_REMATCH[1]}"
;;
1) STEM="Unknown"
;;
*) echo "Upgrade of doom returns ${REZ} from match"
exit 1
esac
if [[ "${STEM}" == "jbig2dec" ]]
then
echo "Life is good"
else
echo "Upgrade of doom cannot process my regex"
fi
exit 0
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
