tables - $'\x7f' does not loaded properly
$ a=( $'\x7e' $'\x7f' $'\x80' ) $ hexdump -C <(echo -n [EMAIL PROTECTED] ) 7e 20 01 7f 20 80 |~ .. .| 0006 bash puts two characters (\x01 and \x7f) instead of only one \x7f but... $ a[1]=$'\x7f' $ hexdump -C <(echo -n [EMAIL PROTECTED] ) 7e 20 7f 20 80|~ . .| 0005 may be its a bug... thanks for your job bye
Re: running source twice wont use arguments
pgb schrieb: I have a bash script that I run using source because I want to be left in the environment that the script sets up after running the script. The script takes a few arguments and sets up an environment for me that includes library paths, classpaths, JAVA_HOME, appends to the PATH, creates and populates a local workspace etc. I call the script in the following manner source setup_env -o -w testdir The -o argument is to wipe out the workspace if it already exists (unconditionally) and the -w provides the name of the workspace to setup. The first time I run the script it runs just fine and all the arguments work as expected, the environment is all setup etc. However, if I immediately run the command again all the arguments are completely ignored source setup_env -o -w testdir The script runs but fails because it's not reading in the args for some reason. As a matter of fact, if I give an argument that doesn't even make sense (-garbage) , the script runs but again the arguments are ignored so it ultimately fails. I searched the forum but did not find a related post. If I don't source the script and run it from the command line, it works both times, but then my environment is not mantained after the script runs so that's not a good idea What in my environment, post-script-run is making the second source not "see" the command line arguments? You probably use getopts, which changes the variable OPTIND in the current environment. The value of this variable is not automatically reset if you start another getopts loop, you have to do it yourself: OPTIND=1 while getopts "ow:" opt do ... done Regards, Bernd -- Bernd Eggink http://sudrala.de
Re: running source twice wont use arguments
pgb wrote: > What in my environment, post-script-run is making the second source not > "see" the command line arguments? Bash doesn't behave as you observe: $ cat x1 cat > /tmp/x1 <<\EOF echo source: arguments: "$@" EOF . /tmp/x1 -o foo -x bar quux echo main arguments: "$@" . /tmp/x1 -o foo -x bar quux rm -f /tmp/x1 $ ../bash-3.2-patched/bash --version GNU bash, version 3.2.39(14)-release (i386-apple-darwin9.2.2) Copyright (C) 2007 Free Software Foundation, Inc. $ ../bash-3.2-patched/bash ./x1 abcd source: arguments: -o foo -x bar quux main arguments: abcd source: arguments: -o foo -x bar quux I suspect the difference is due to the use of getopts, as Bernd Eggink already posited. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: eval "{" has exit status 0
[EMAIL PROTECTED] wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
> -DCONF_VENDOR='unknown'
> -DLOCALEDIR='/nix/store/mm631h09mj964hm9q04l5fd8vw12j1mm-bash-3.2-p39/share/locale'
> -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib
> -g -O2
> uname output: Linux mail.desk 2.6.25.17-default #1 SMP Tue Oct 7
> 23:48:14 UTC 2008 x86_64 GNU/Linux
> Machine Type: x86_64-unknown-linux-gnu
>
> Bash Version: 3.2
> Patch Level: 39
> Release Status: release
>
> Description:
> I'd say eval "{" should have non zero exit status..
> Maybe it should behave like this function and return exit status 1 ?
Thanks for the report. This will be fixed in the next bash version. Note
that it's only a problem when evaluating strings in interactive shells.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: tables - $'\x7f' does not loaded properly
Antonio Macchi wrote: > $ a=( $'\x7e' $'\x7f' $'\x80' ) > > $ hexdump -C <(echo -n [EMAIL PROTECTED] ) > 7e 20 01 7f 20 80 |~ .. .| > 0006 > > > bash puts two characters (\x01 and \x7f) instead of only one \x7f Yes, it's a bug. Thanks for the report. It will be fixed in the next version of bash. It's only a problem in these exact circumstances -- ansi-c quoted strings in a compound array assignment. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: [Fwd: [PATCH] arithmetic -> logical shift]
Pádraig Brady wrote: > Original Message > Date: Tue, 07 Oct 2008 11:55:51 +0100 > From: Pádraig Brady <[EMAIL PROTECTED]> > To: Chet Ramey <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED] > > I was just discussing bit shifting with Tim Hockin using shell > arithmetic expansion, and he pointed out that bash and ksh > use arithmetic rather than logical shift for the >> operator. Actually, bash and ksh use whatever the native C compiler implements, since both just translate the >> and << into the same operators internally. I don't see a really compelling reason to change, since, as you say, the standard requires signed long ints. > I know the opengroup spec says to use signed ints, > but I think that is intended to disambiguate input and output, > rather than defining internal operations. You might send a message to the austin group asking for an opinion. That would give you a better sense of the standard's intent. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
