Re: set -e vs. !
Dan Jacobson [EMAIL PROTECTED] writes: $ cat t.sh set -ex ! true #should stop here but doesn't!?! RTFM. `-e' Exit immediately if ..., unless ... the command's return status is being inverted using `!'. 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: set -e vs. !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dan Jacobson on 9/8/2006 5:42 AM: $ cat t.sh set -ex ! true #should stop here but doesn't!?! ! false true false : already quit $ bash t.sh + true + false + true + false $ pdksh t.sh + true Bash is right. This is a bug in pdksh; report it there. POSIX requires: - -e When this option is on, if a simple command fails for any of the reasons listed in Consequences of Shell Errors or returns an exit status value 0, and is not part of the compound list following a while, until, or if keyword, and is not a part of an AND or OR list, and is not a pipeline preceded by the ! reserved word, then the shell shall immediately exit. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAXn284KuGfSFAYARAujBAKDIgR93kgysy9YsxObpnPMOfD3ymQCcC0D+ tFUbB9z+6/vKCUNHe6X0uj4= =QlSt -END PGP SIGNATURE- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: read command and ascii null as delimiter
Nathan Coulter wrote:
Feature request: an option, maybe -0 to use ascii null as the delimiter for
the read command. It would make the following two commands produce the
same output:
[EMAIL PROTECTED]:~/tmp5$ printf 'hello\000there' | xargs -n1 -0 echo
hello
there
[EMAIL PROTECTED]:~/tmp5$ printf 'hello\000there' | { while read -0 ; do echo
$REPLY; done; }
read -d $'\0' will do most of what you want, with one limitation. The
read builtin accepts only one eol delimiter, so either you ensure that
the input ends with a NUL or you pick up the final portion of the input
in $REPLY after read returns status 1 upon encountering EOF.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
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: possibly a bash build problem?
George R Goffe wrote: Howdy, This result (see below) seems to be redily re-creatable. Could you take a peek at this and tell me if it is a bug or if I'm doing something wrong please? Regards and thanks for your time, George... rm -f bash gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/malloc -L./lib/sh -static -static -rdynamic -pg -g -O2 -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o braces.o bracecomp.o bashhist.o bashline.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lsh -lreadline -lhistory -lcurses -lglob -ltilde -lmalloc lib/intl/libintl.a /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libc.a(dcigettext.o)(.text+0x684): In function `_nl_find_msg': : multiple definition of `_nl_find_msg' lib/intl/libintl.a(dcigettext.o)(.text+0x568):/tools/bash/bash-3.1/lib/intl/dcigettext.c:740: first defined here /usr/bin/ld: Warning: size of symbol `_nl_find_msg' changed from 851 to 1361 in /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libc.a(dcigettext.o) collect2: ld returned 1 exit status make: *** [bash] Error 1 It seems like the autoconf macro (AM_GNU_GETTEXT) used to detect the availability of the gettext functions is deciding they're not available in libc and falling back to the included version of libintl. You could check config.log and config.status to see why. I wonder if it's due to the fact that you're trying to build a profiled version of bash that can be run against gprof. That usually links in a separate set of libraries. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer 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: incorrect brace expansion when using default values
Tatavarty Kalyan schrieb am 08.09.2006 um 11:44:47 (+0800):
It is because the string
a{b,c}
is outside of the quotes. So the brace expansion comes first and
duplicates
the arguments to the echo call.
Yes, as you said the brace expansion is outside the double quotes so
shouldn't it be more like:
$ foo() { echo ${1:-ab} ${1:-ac} ; }
Yes, of course. ;)
It so simple, just eval the braces and nothing else.
I did one step too much and discovered that ab is atomar and underlies no
further evaluation.
So my assumption is correct for this example only, but not for any possible
string replacing ab as yours.
Alexander
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: comint: long lines truncated
Ilya N. Golubev wrote: `comint.el' versions since revision 1.14 of 2006/05/25 02:49:47 -0 unconditionally add `TERM=dumb' to environment of all processes they start. Programs using readline, including bash 3.1 with their bundled readline libraries, with this setting incorrectly truncate long input lines. This may be reproduced with inserting long enough command in comint mode buffer and calling `comint-send-input'. For `echo' with single argument, string of 256 `.'s as arg bash process outputs part of them, and for the rest of them outputs bash: : command not found I cannot reproduce this pasting a long command line such as the above into bash running in xterm or MacOS X terminal. I don't use emacs (or xemacs), and can't reproduce it that way. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer 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: incorrect brace expansion when using default values
Chris F.A. Johnson wrote:
Quote them, and they do expand:
$ foo() { echo ${1:-a{b,c}} ; }
$ foo
ab ac
Brace expansion is essentially separate from the rest of the expansions:
in fact, it's designed to be part of a separate library if desired. As
such, it doesn't implement all of the shell's somewhat quirky quoting
semantics. It understands simple single- and double-quoted strings and
backslash escapes. The manual is perhaps not as clear about this as it
could be.
The quoted string, once the brace expansion code finishes, comes out like
this:
${1:-ab} ${1:-ac}
From there, the results observed should be understandable.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
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
