Bash 3.1 fails to build on OS/X 10.1
Uname: Darwin mac.bandsman.co.uk 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc CC: 2.95.2 ./configure worked fine. Make gives: ... rm -f libreadline.5.1.dylib cc -dynamic -arch_only `/usr/bin/arch` -install_name /usr/local/lib/libreadline.5.1.dylib -current_version 5.1 -compatibility_version 5 -v -o libreadline.5.1.dylib readline.so vi_mode.so funmap.so keymaps.so parens.so search.so rltty.so complete.so bind.so isearch.so display.so signals.so util.so kill.so undo.so macro.so input.so callback.so terminal.so text.so nls.so misc.so xmalloc.so history.so histexpand.so histfile.so histsearch.so shell.so mbutil.so tilde.so compat.so -lncurses Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs cc: unrecognized option `-arch_only' Apple Computer, Inc. version gcc-934.3, based on gcc version 2.95.2 19991024 (release) /usr/bin/ld -arch ppc -o libreadline.5.1.dylib -dynamic -lcrt1.o readline.so vi_mode.so funmap.so keymaps.so parens.so search.so rltty.so complete.so bind.so isearch.so display.so signals.so util.so kill.so undo.so macro.so input.so callback.so terminal.so text.so nls.so misc.so xmalloc.so history.so histexpand.so histfile.so histsearch.so shell.so mbutil.so tilde.so compat.so -lncurses -lcc_dynamic -lSystem /usr/bin/ld: can't locate file for: -lncurses make[1]: *** [libreadline.5.1.dylib] Error 1 make: [shared] Error 2 (ignored) -Nigel Horne ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
introducing BASHRC env var
Greetings
Attached is a little hack which allows you to define an alternative to
~/.bashrc by setting the BASHRC environment variable.
This was useful to me since I am unable to modify ~/.bashrc on a customer site
to my taste without incurring the wrath of other folks using the same user
login. Yes, I now you can specify an alternate bashrc with the --rcfile
parameter, but then subsequent instances of bash invoked by screen, for
instance, do not know about the alternate location of bashrc.
cheers
mark
---8<---
--- shell.c.save2006-03-16 10:56:45.374615000 +1100
+++ shell.c 2006-03-16 10:56:50.342055000 +1100
@@ -423,6 +423,10 @@
set_shell_name (argv[0]);
shell_start_time = NOW; /* NOW now defined in general.h */
+ /* ~/.bashrc might be somewhere else */
+ if (getenv ("BASHRC"))
+ bashrc_file = getenv ("BASHRC");
+
/* Parse argument flags from the input line. */
/* Find full word arguments first. */
->8-
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
RE: Keybinding "yank 0th arg", "delete backward argument"
> > (1) yank 0th arg, similar to yank-last-arg, but copies the > command part > > of the previous line > > into the current buffer. Example: The previous line was > > > > /usr/local/bin/perl myprog.pl > > > > then yank-0th-arg should insert /usr/local/bin/perl into the buffer. > > M-0 M-. (digit-argument yank-last-arg) > > > (2) delete-backward-argument, similar to delete-backward-word, but > > should delete everything > > to the left until the first white space. > > C-w (unix-word-rubout) Exactly what I was looking for Thank you very much! ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
exit status when setting local variables
not sure if this is a bug or feature ... take this little snippet:
testit() {
local foo=$(false) ; echo $?
foo=$(false) ; echo $?
}
when we run the code, the output is:
0
1
rather than intuitive:
1
1
-mike
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash 3.1 fails to build on AIX
Nigel Horne wrote: > Nigel Horne wrote: >>> Since compilation failed bashbug hasn't been installed, so I am having >>> to >>> guess what is wanted. Let me know if you need any more help. >> Does isinf appear in libc on AIX 5.1? How about isnan? > > There are man pages for both isinf and isnan, but they seem to be > macros in math.h, rather than functions in libc. That's odd, because presumably the autoconf test for isinf would not have succeeded. The only place isnan gets used is in lib/sh/snprintf.c, and it's guarded by the same isinf autoconf test. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo "enhancement" leads to confused legacy script tools...
Henrik Nordstrom wrote: Note: As far as I can tell the echo tests in the configure script generated by autoconf-2.59 tests for quite many things but not \digit as far as I can tell. I have not yet looked into the CVS version. Regards Henrik --- Sorry, haven't been involved too much on this discussion, I'm going to have limited time to look at this in the next day or so. I'm willing to try the CVS versions of autoconf later on, but can't promise when I'll get to it. I can confirm, though, that the bug I'm running into only happened when I rebuilt bash and specified the --enable_xpg_default option. Personally, I don't believe allowing "\o[o[o]]" as an allowed octal sequence is wise when xpg_default is enabled. When "-e" is required, it's not so problematic -- a use can't "accidentally" get an octal sequence unless they have used "-e" -- and then they are (or should be) aware that the string will be interpreted with "\" having special meaning. However, when extended interpretation is the default, the requirement of having a "0" after a "\" reduces the number of "special" strings making it less likely that some application will accidentally enter "octal interpretation mode". It may seem a trivial difference, but the change means that the number of "reserved" 2-byte sequences has doubled: from: 9 2-byte sequences (\a \b \c \f \n \r \t \v \\) and 8 3-byte sequences (\00 \01 .. \07) to: 17 2-byte sequences (original + \0 \1 .. \7) or 18 if you count the addition of "x" for hex Design thoughts: If I wanted to provide maximum compatibility with existing applications, it would be optimal to minimize the number of "reserved" 2-byte sequences by requiring the leading "0 before an octal lead-in. Even better, IMO, would be keeping with existing numeric constant interpretation from most unix source code examples and require \0 as the prefix for octal and \0xHH for hex. That way "\xabsent" (for example) wouldn't cause a surprise conversion to hex, while \0xabsent would seem to stand out more as an indicator of a special embedded numeric (hex) constant. It might be "late" to change the requirement to "\0" is required as the leading for all numeric constants, but as has been stated here, no application should be relying on "\1" being interpreted as "^A" if it is desired that it be portable. While it may seem somewhat "asymmetric", I'd be comfortable requiring the "0" only in the case where the default was extended interpretation (i.e. where "-e" isn't required). As mentioned before, if a user explicitly uses "-e", they they already need to be aware of special "\" processing, so there would be less likelihood of "user surprise". Linda ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo "enhancement" leads to confused legacy script tools...
Hello everybody, * Linda W wrote on Mon, Mar 20, 2006 at 10:16:44PM CET: > Henrik Nordstrom wrote: > >Note: As far as I can tell the echo tests in the configure script > >generated by autoconf-2.59 tests for quite many things but not \digit as > >far as I can tell. I have not yet looked into the CVS version. Confirmed with - bash-3.0 configured as configure --enable_xpg_default - squid CVS (as described by Paul), configured as CONFIG_SHELL=xpgbash; export CONFIG_SHELL $CONFIG_SHELL ../squid/configure -C --enable_xpg_default \ CONFIG_SHELL=$CONFIG_SHELL - both the autotools versions used in the CVS version, as well as CVS Autoconf. The issue is not in Autoconf, but in the macro AC_CREATE_PREFIX_CONFIG_H (taken from the autoconf archive?). Inside the squid source tree, the macro resides in lib/cppunit-1.10.0/config/ac_create_prefix_config_h.m4 as part of the cppunit subpackage. The macro is now deemed obsolete at http://autoconf-archive.cryp.to/macros-by-category.html the successor is AX_PREFIX_CONFIG_H. Which itself uses printf to work around these issues. It has other issues with recent Autoconf, though, so it needs changed as well. I will look into that, and post an update. FWIW, are there _any_ other shells that do not output \1 with echo "\\1" except for bash-3.0-with-xpg-echo? Cheers, Ralf ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Backquote Mystery
"Com MN PG P E B Consultant 3" <[EMAIL PROTECTED]> writes: > Wenn you now do echo $e, you should get the following output: Try echo "$e". Then read about Word Splitting in the Bash 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: echo "enhancement" leads to confused legacy script tools...
Andreas Schwab <[EMAIL PROTECTED]> writes: >> There's a little history here. POSIX 1003.2-1992 said that echo has >> implementation-defined behavior if given any options, or if any > > Are you sure about "any option"? The current spec only talks about -n. Yes, I have the printed copy of POSIX 1003.2-1992, and it has different wording in this area. Quite a zoo, huh? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: $* and $@ broken on some (64 bit?) platforms in bash 3.1
Hi again,
I've done some more testing -- but still I don't get the whole figure.
here are some more mosaic pieces for the jigsaw puzzle, maybe you know
what's going wrong here ?!
I've done some more compile tests mostly on HP-UX 11.11 (and 11.22).
my default build (which is broken) was with gcc used MULTIBYTE support.
trying to compile with system "cc" breaks because of broken wchar.h,
I need the following small patch
---
--- orig/bash-3.1/config-bot.h 2004-03-19 23:56:23.0 +0100
+++ bash-3.1/config-bot.h 2006-03-27 15:18:33.0 +0200
@@ -139,6 +139,17 @@
# endif
#endif
+/* HAK: wchar.h is broken on HP-UX */
+#if defined (HAVE_WCHAR_H) && defined(__hpux__)
+#include
+size_t mbrlen(const char *s, size_t n, mbstate_t *ps);
+size_t wcsrtombs(char *dst, const wchar_t **src, size_t len, mbstate_t *ps);
+size_t wcrtomb(char *s, wchar_t wc, mbstate_t *ps);
+size_t mbrtowc(wchar_t *pwc, const char *s, size_t n, mbstate_t *ps);
+size_t mbsrtowcs(wchar_t *dst, const char **src, size_t len, mbstate_t *ps);
+#endif
+
+
/* If we don't want multibyte chars even on a system that supports them, let
the configuring user turn multibyte support off. */
#if defined (NO_MULTIBYTE_SUPPORT)
---
but again this binary still is broken.
next I compiled with
#undef HANDLE_MULTIBYTE
at the end of config-bot.h. using system cc, the binary still shows the same
problems, but the "gcc" binary seems to be ok!!
using "#undef HANDLE_MULTIBYTE" on Mac OS X removes those problems too.
I've looked into the errors in output of "tests/run-test" using,
it's not the test itself which fails but argument passing
to the shell function:
./bash -c ' t() { test "$@"; echo -n "$@ $? "; } ; t -a noex ; test -a
noex2 ; echo $? '
correct output (cc no-MB):
-a noex 1 1
bad output:
-aÏÏnoex 0 1
^^
there are two 0xCF charaters after "-a" instead of the space.
or on Mac OS X with non-working HANDLE_MULTIBYTE :
-a-anoex 0 1
I don't really like the idea to disable HANDLE_MULTIBYTE on platforms
like HP-UX 11.11/22 or even Mac OS X -- there must be another solution ?!?!?
Harald Koenig
--
"I hope to die ___ _
before I *have* to use Microsoft Word.", 0--,|/OOO\
Donald E. Knuth, 02-Oct-2001 in Tuebingen.<_/ / /OOO\
\ \/OOO\
\ O|//
Harald Koenig \/\/\/\/\/\/\/\/\/
science+computing ag// / \\ \
[EMAIL PROTECTED]^ ^
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: exit status when setting local variables
Mike Frysinger wrote:
> not sure if this is a bug or feature ... take this little snippet:
> testit() {
> local foo=$(false) ; echo $?
> foo=$(false) ; echo $?
> }
>
> when we run the code, the output is:
> 0
> 1
>
> rather than intuitive:
> 1
> 1
It's intentional.
`local' returns success if the variable is correctly assigned a value
(for instance, the variable is not read-only). The assignment statement
returns failure because that's how POSIX says assignment statements
behave. (export and readonly behave the same way as local.)
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live Strong. No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash 3.1 fails to build on OS/X 10.1
Nigel Horne wrote: > Uname: > Darwin mac.bandsman.co.uk 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 > PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc > CC: 2.95.2 > > ./configure worked fine. Apple moved some things around in 10.2. In 10.2 and later, you need to link with -lncurses, whereas in 10.1 the termcap functions were in -lSystem with everything else. Just take the -lncurses spec out. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Line numbering in error messages
Hi folks, I wonder if there is a thorough documentation on line numbering in bash's error messages? I find it often quite misleading and would like to know what I am counting wrong. Any hint or help is appreciated. Dirk ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
