Re: !* goofs here-strings
[EMAIL PROTECTED] wrote: Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=nocona -O3 -pipe -fomit-frame-pointer uname output: Linux vino 2.6.17-gentoo #1 SMP PREEMPT Mon Jun 26 17:27:49 EDT 2006 x86_64 Intel(R) Xeon(TM) CPU 3.20GHz GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: !* goofs here-strings Repeat-By: $ cat << I thought the syntax was only two '<'s? This WFM: $ cat << foo > foo $ cat !* -- Matthew ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: !* goofs here-strings
Paul Jarc wrote: mwoehlke <[EMAIL PROTECTED]> wrote: I thought the syntax was only two '<'s? "<<" gives you a here-document. "<<<" gives you a here-string. Check the man page for details. Ah, ok, never noticed that feature before. Huh, and probably something I would have liked to use a number of times if I'd known about it. :) Confirming it broken on 3.0 as well. -- Matthew Ok, so the quotes aren't entirely original. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: null command and parameter expansion for "Display error if null or unset"
Poor Yorick wrote:
The following line does not perform the "echo" command.
: ${FAKEVAR?} || echo hello
This seems inconsistent, since the return status is set to one,
not to mention that the null command is documented to return a
zero exit code. It would be a convenient and concise syntax for
acting on unset variables.
'man bash'. The behavior is exactly as documented, particularly the part
"... and the shell ... exits". This is consistent because 'exits' means
'don't finish what you were doing' (in this case, '|| echo hello').
What you probably want is:
[ "$FAKEVAR" ] || echo hello
--
Matthew
DOS Attack: See America Online -- my college room mate
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Link Error bash-3.1, AIX 5.2, xlC version 8
Perry Smith wrote: This may be a dup but the subject pretty much says it all. Compiled bash-3.1 fresh out of the box with just a configure command. The only error was this: ld: 0711-317 ERROR: Undefined symbol: .isnan I fixed it by adding -lm to the LOCAL_LIBS in the Makefile. Not sure if that is how to really fix it or not. I think it is (adding -lm anyway, the 'where' is still debatable). LOCAL_LIBS = -lm This is on a fresh AIX 5.2 install. Seems like I had the same problem on a fresh AIX 5.3 install but I honestly can't say for sure. I hope this helps someone somewhere. It did. Same exact problem, same exact solution. Thanks for sharing! :-) ...except I have AIX 5.1, cc version 6, so it's generic to AIX. I think a patch may be in order? -- Matthew Do not expose to hippos. Doing so may void your warranty. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bug with 'test' built-in.
John Wenker wrote: Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H -D_GNU_SOURCE -I. -I. -I./include -I./lib -O2 -march=i386 -mcpu=i686 uname output: Linux ragtop 2.4.18-3 #1 Thu Apr 18 07:32:41 EDT 2002 i686 unknown Machine Type: i686-pc-linux-gnu Bash Version: 2.05a And despite this version being ancient, I'll point out that I can reproduce (assuming this isn't a case of wrong syntax) on "3.00.15(1)-release" (whatever that is; came with FC4) and 3.1.17 built from sources. To venture a guess, it seems like '-a' is being parsed as 'and' in this case, rather than the test for file existence. Patch Level: 0 Release Status: release Description: There is a problem using '!' (boolean negation) with the -a flag of the 'test' built-in command. The following construct _always_ evaluates true, regardless of whether the file exists or not. if [ ! -a file ]; then echo "This line always prints no matter what." else echo "This line never prints." fi Using -a w/o the negation works fine. -- Matthew vIMprove your life! Now on version 7! ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bug with 'test' built-in.
Paul Jarc wrote: John Wenker <[EMAIL PROTECTED]> wrote: The following construct _always_ evaluates true, regardless of whether the file exists or not. if [ ! -a file ]; then echo "This line always prints no matter what." else echo "This line never prints." fi -a can act as a prefix unary operator, or an infix binary "and" operator. When it appears as the second of three arguments (not counting "]") in a test, it's treated as a binary operator, even if the first argument is "!". So in this case, "!" is test, and as a single string it's only tested for non-emptiness, and so is considered true. Likewise for "file". Since both subtests are true, the combined "and" test is also true. There are a few different ways to get the behavior you want. You could use "[ ! \( -a file \) ]" or "! [ -a file ]", although those are not portable to some other shells. (The behavior of a test is generally more predictable when there are fewer arguments, so I'd go with the second of those two, since it pulls the "!" outside the test and leaves only two arguments for the test to examine.) You could also remove "!" and switch your "then" and "else" clauses, which works with any shell. I *know* '! [ -a file ]' is not portable. I tried to use it in some script, somewhere, at some time, and it was sometimes treated as history expansion. Switching clauses may be the only safe way. -- Matthew vIMprove your life! Now on version 7! ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bug with 'test' built-in.
Paul Jarc wrote: mwoehlke <[EMAIL PROTECTED]> wrote: I *know* '! [ -a file ]' is not portable. I tried to use it in some script, somewhere, at some time, and it was sometimes treated as history expansion. Quoting the "!" would take care of that particular problem, but there are some older shells, like Solaris /bin/sh, where the "!" command doesn't exist at all, so if this script will have to run in anything but bash, it'd still be good to use one of the other methods. Hehe, yeah, I have to maintain scripts that run under "/bin/sh" on... oh, about nine different platforms. :-) That's always a frustrating exercise in portability, and not just w.r.t. the shell. For instance, there is one script that breaks with certain non-GNU versions of 'awk' and 'tail', and there have been plenty of times I've put in conditional code. Heck, I've even done conditional code based on the version of bash! :-) -- Matthew vIMprove your life! Now on version 7! ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Espace characters need -e, wrong behaviour
Nico Schottelius wrote: Bash needs -e to react on escape characters. No other shell (afaik) does that (confirmed with dash, ksh and zsh), nor does posix specify that behaviour: http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html Another big problem is that people tend to use -e, which will be printed by other shells and brakes the output. Repeat-By: echo '\a' Fix: Please remove the need for -e and ignore -e for a some time, until it vanished from user programs. 'echo' is known to be non-portable. If you are looking for portability, you should be using 'printf'. Interestingly, this does seem to be inconsistent with many 'sh' implementations (I tried on a few old and exotic OS's), although it conforms to GNU 'echo' (the command, not the built-in). -- Matthew If you can't use a real OS, at least use Cygwin to fake one! ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
...Limitation?
Not really a bug, but this seems to be the only bash list gname knows
about, so...
I am trying to figure out how to run a command and pipe the output
through tee, and then check the status of the original command. Normally
I am a very competent shell programmer, but this one has me stumped!
I have tried all of the following with no success (except of course the
last one):
my_false() { false || ret=3; }
ret=0
{ false || exit 1; } | tee none
{ false || ret=2; } | tee none ; [ $ret -eq 0 ] || exit $ret
my_false | tee none ; [ $ret -eq 0 ] || exit $ret
false | tee none || exit 4
false || exit 5
Please, someone tell me I'm just doing it wrong, and this is not a
limititation in bash!
--
Matthew
Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: ...Limitation?
Paul Jarc wrote:
mwoehlke <[EMAIL PROTECTED]> wrote:
I am trying to figure out how to run a command and pipe the output
through tee, and then check the status of the original command.
This uses a bash-specific feature:
cmd > >(tee file); status=$?
Thanks Paul and Stephen for the replies. I am using bash, so the above
solution is fine, and is working.
This should work on any sh:
exec 3>&1 && status=`exec 4>&1 && { cmd; echo $? >&4; } | tee file >&3`
Or, if you don't want to clobber any descriptors, in case they might
be in use for something else:
: > file &&
{ tail -f file & } &&
pid=$! &&
{ cmd > file; status=$?; } &&
sleep 1 && # give tail a chance to print the last bits that were just written
kill "$pid"
--
Matthew
Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Fatal bug with redirection
Yang wrote:
On my FC5 box, when I try certain things in bash 3.1.7(1)-release
involving redirection, such as the following, bash crashes
(immediately exits):
{ echo a >&3 ; } 3> >( echo b )
That toasts "3.00.15(1)-release" (FC4 IIRC), but not 3.1.17. I would
apply patches 8-17 and try again.
I've only tried this from an interactive shell. Unfortunately I don't
have bashbug or bashversion, as I'm using the FC5 RPM version, but
here is some info:
[snip]
What's 'bashversion'? Are you familiar with 'echo $BASH_VERSION'?
--
Matthew
This message will self destruct in five millennia.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Curly braces expansion not always works as expected.
Stephane Chazelas wrote:
On Thu, Oct 05, 2006 at 12:23:41AM +0200, Reuti wrote:
[...]
Curly braces expansion only works with at least one comma
(,). This also works, if the appears at least once
inside some apostrophes and has no function.
Repeat-By:
[EMAIL PROTECTED]:~> bash --version
GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.0)
Copyright (C) 2002 Free Software Foundation, Inc.
[EMAIL PROTECTED]:~> echo {"x x"} # No {} in output expected.
{x x}
[EMAIL PROTECTED]:~> echo {"xx"} # No {} in output expected.
{xx}
[EMAIL PROTECTED]:~> echo {"xx","yy"} # Works fine.
xx yy
[EMAIL PROTECTED]:~> echo {"x,x"} # Add a comma to get it
working, i.e. remove the {}.
x,x
[EMAIL PROTECTED]:~>
Also this seems to be strange:
[EMAIL PROTECTED]:~> echo {"klklkl"} {1,2,3} # Only second {}
works correctly.
{klklkl} 1 2 3
[EMAIL PROTECTED]:~> echo {"klklkl"}{1,2,3} # Completely messed up.
{klklkl}{1,2,3}
Only that one is a bug, it should output {klklkl}1 {klklkl}2
{klklkl}3
The other ones work as documented.
From info -f bash -n 'Brace Expansion'
| A correctly-formed brace expansion must contain unquoted
| opening and closing braces, and at least one unquoted comma
| or a valid sequence expression. Any incorrectly formed brace
| expansion is left unchanged.
...but doesn't that mean that '{"x,x"}' should expand as '{x,x}', not
'x,x'? Note *unquoted* in the sentence above.
--
Matthew
"What's Cygwin?" you ask.
'Tis mostly absurd software
Concerning hippos.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Curly braces expansion not always works as expected.
Andreas Schwab wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
...but doesn't that mean that '{"x,x"}' should expand as '{x,x}'
It does.
Huh?
$ echo {"x,x"} # expected result: '{x,x}'
x,x
$ echo $BASH_VERSION
3.1.17(3)-release
That doesn't look like '{x,x}' to me... it looks like 'x,x', which by my
reading is wrong.
If I had to guess, I'd say bash sees the {}'s, and incorrectly decides
to do brace expansion based on the *quoted* comma... but when it
actually does expansion, it gets the (correct) result 'x,x', except that
now the {}'s have been incorrectly removed.
--
Matthew
"What's Cygwin?" you ask.
'Tis mostly absurd software
Concerning hippos.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Curly braces expansion not always works as expected.
Andreas Schwab wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
Andreas Schwab wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
...but doesn't that mean that '{"x,x"}' should expand as '{x,x}'
It does.
Huh?
In the forthcoming 3.2 release anyway, so this bug has apparently already
been fixed.
Ah, ok, why didn't you say so the first time! ;-)
Thanks for the update...
--
Matthew
"What's Cygwin?" you ask.
'Tis mostly absurd software
Concerning hippos.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
How to detect bash?
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...) -- 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?
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 2>&1`" = "bash: /dev/null: Permission denied" ]
This is probably even more reliable than my first attempt, and also
catches bash running as /bin/sh as 'not bash'. Since I blithely (but
reasonably) assume that /dev/null is the bit-bucket, it's a pretty safe
bet that it can't be executed.
But better to use the hash-bang and make SURE the shell is Bash.
Completely non-workable. That only works if the bash I want is in
/bin/bash. Although I *could* make that correct (I need this to work on
any of a dozen or so computers running about as many OS/hardware
combinations), it defeats the point of my NFS toolchain in which the
bash I want is in /home/install/gnu//bin/bash, which can't be put
into a shebang because it isn't constant. And of course would break
things if we were still in bash, but that particular bash wasn't available.
--
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?
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 2>&1`" = "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 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
$ ARGV0=bash ash -c 'echo "`/dev/null 2>&1`"; 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 2>&1`"'
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?
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//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
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
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
