Re: + vs. [^/]* - Regular Expression bug?
On Tue, Feb 09, 2010 at 09:18:47PM -0800, DennisW wrote:
* means zero or more characters. It found zero and stopped. You could
do:
[[ '/home/' =~ /([^/]*) ]]; echo ${BASH_REMATCH[1]}
Oh, is he trying to get the first non-null component of a /-delimited
pathname? I can never tell any more
IFS=/ read -a tmp '/home/'; echo ${tmp[1]}
Using regular expressions to split a string into fields is so unnatural
to me. ${tmp[1]} is the second element of the array. If you need to
search through it for the first non-null element, you can write a loop
for that.
Circulate matches in command completion?
Suppose I file 'a1.txt' and 'a2.txt' in my current directory. When I type 'cat a' then TAB, it will show me 'a1.txt' and 'a2.txt'. If I type TAB repeatedly, it will always show me the same thing. However, a better response might be 1. complete the command to 'cat a1.txt' at the 2nd TAB, 2. complete the command to 'cat a2.txt' at the 3rd TAB, 3. return to the original 'cat a' at the 4th TAB, 4. complete the command to 'cat a1.txt' again at the 5th TAB. I'm wondering if there is a way to configure bash this way.
Re: Circulate matches in command completion?
On 2/11/10 10:54 AM, Peng Yu wrote: Suppose I file 'a1.txt' and 'a2.txt' in my current directory. When I type 'cat a' then TAB, it will show me 'a1.txt' and 'a2.txt'. If I type TAB repeatedly, it will always show me the same thing. However, a better response might be 1. complete the command to 'cat a1.txt' at the 2nd TAB, 2. complete the command to 'cat a2.txt' at the 3rd TAB, 3. return to the original 'cat a' at the 4th TAB, 4. complete the command to 'cat a1.txt' again at the 5th TAB. I'm wondering if there is a way to configure bash this way. bind 'TAB:menu-complete' -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Circulate matches in command completion?
On Thu, Feb 11, 2010 at 9:58 AM, Chet Ramey chet.ra...@case.edu wrote: On 2/11/10 10:54 AM, Peng Yu wrote: Suppose I file 'a1.txt' and 'a2.txt' in my current directory. When I type 'cat a' then TAB, it will show me 'a1.txt' and 'a2.txt'. If I type TAB repeatedly, it will always show me the same thing. However, a better response might be 1. complete the command to 'cat a1.txt' at the 2nd TAB, 2. complete the command to 'cat a2.txt' at the 3rd TAB, 3. return to the original 'cat a' at the 4th TAB, 4. complete the command to 'cat a1.txt' again at the 5th TAB. I'm wondering if there is a way to configure bash this way. bind 'TAB:menu-complete' This is helpful. But it is not exactly what I'm looking for. I still want to show 'a1.txt' and 'a2.txt' at the 1st TAB. The above bind command gives me 'cat a1.txt' directly at the 1st TAB.
Re: Circulate matches in command completion?
On 2/11/10 11:05 AM, Peng Yu wrote: On Thu, Feb 11, 2010 at 9:58 AM, Chet Ramey chet.ra...@case.edu wrote: On 2/11/10 10:54 AM, Peng Yu wrote: Suppose I file 'a1.txt' and 'a2.txt' in my current directory. When I type 'cat a' then TAB, it will show me 'a1.txt' and 'a2.txt'. If I type TAB repeatedly, it will always show me the same thing. However, a better response might be 1. complete the command to 'cat a1.txt' at the 2nd TAB, 2. complete the command to 'cat a2.txt' at the 3rd TAB, 3. return to the original 'cat a' at the 4th TAB, 4. complete the command to 'cat a1.txt' again at the 5th TAB. I'm wondering if there is a way to configure bash this way. bind 'TAB:menu-complete' This is helpful. But it is not exactly what I'm looking for. I still want to show 'a1.txt' and 'a2.txt' at the 1st TAB. The above bind command gives me 'cat a1.txt' directly at the 1st TAB. Look at the 'show-all-if-ambiguous' option. The combination may do what you want. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Circulate matches in command completion?
On Thu, Feb 11, 2010 at 10:36 AM, Chet Ramey chet.ra...@case.edu wrote: On 2/11/10 11:05 AM, Peng Yu wrote: On Thu, Feb 11, 2010 at 9:58 AM, Chet Ramey chet.ra...@case.edu wrote: On 2/11/10 10:54 AM, Peng Yu wrote: Suppose I file 'a1.txt' and 'a2.txt' in my current directory. When I type 'cat a' then TAB, it will show me 'a1.txt' and 'a2.txt'. If I type TAB repeatedly, it will always show me the same thing. However, a better response might be 1. complete the command to 'cat a1.txt' at the 2nd TAB, 2. complete the command to 'cat a2.txt' at the 3rd TAB, 3. return to the original 'cat a' at the 4th TAB, 4. complete the command to 'cat a1.txt' again at the 5th TAB. I'm wondering if there is a way to configure bash this way. bind 'TAB:menu-complete' This is helpful. But it is not exactly what I'm looking for. I still want to show 'a1.txt' and 'a2.txt' at the 1st TAB. The above bind command gives me 'cat a1.txt' directly at the 1st TAB. Look at the 'show-all-if-ambiguous' option. The combination may do what you want. set show-all-if-ambiguous On bind 'TAB:menu-complete' I typed in the above two commands. It seems that command completion is the same as if I only typed in the second command. Do you know why?
Re: [^/]+ vs. [^/]* - Regular Expression bug?
Hi again,
Oh, right, that makes sense. And like I feared, I was indeed wasting
your time.
Thanks for the info, sorry about the time.
Morten
Andreas Schwab wrote:
Morten Lauritsen Khodabocus mlauri...@gmail.com writes:
Two regular expressions should match the same thing, but for some reason
do not:
[[ '/home/' =~ [^/]+ ]]; echo ${bash_remat...@]}
and
[[ '/home/' =~ [^/]* ]]; echo ${bash_remat...@]}
the first matches 'home', the second matches nothing. The only difference
is * vs. + AFAICT, both expressions should match 'home'.
[^/]* matches the null string at the start of '/home/', and there is
no reason for the matcher to try another match.
Andreas.
undefined reference to `__strtoll'
Configuration Information [Automatically generated, do not change]: Machine: hppa2.0w OS: hpux11.00 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='hppa2.0w' -DCONF_OSTYPE=' hpux11.00' -DCONF_MACHTYPE='hppa2.0w-hp-hpux11.00' -DCONF_VENDOR='hp' -DLOCALEDI R='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DHPUX -I . -I. -I./include -I./lib -g -O2 uname output: HP-UX halflife B.11.00 U 9000/785 2012264887 unlimited-user licens e Machine Type: hppa2.0w-hp-hpux11.00 Bash Version: 4.1 Patch Level: 0 Release Status: release Description: I'm having trouble compiling bash on HP-UX 4.1. I can't figure out how to work around it. Basically, the version of HP-UX I'm running on doesn't have strtoll. So when I'm building, I see these errors: gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/malloc -L./lib/sh-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 assoc.o braces.o bracecomp.o bashhist.o bashline.o siglist.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh -lreadline -lhistory -lcurses -ltilde -lmalloc -lintl -ldl collect2: ld terminated with signal 11 [Segmentation fault], core dumped general.o(.text+0x334): In function `legal_number': /home/dmoore/gnu/bash-4.1/general.c:175: undefined reference to `__strtoll' braces.o(.text+0xae4): In function `brace_expand': /home/dmoore/gnu/bash-4.1/braces.c:395: undefined reference to `__strtoll' ./builtins/libbuiltins.a(printf.o)(.text+0xe6c): In function `getintmax': ./printf.def:998: undefined reference to `__strtoll' make: *** [bash] Error 1 My version of GCC is gcc -v Using built-in specs. Target: hppa64-hp-hpux11.00 Configured with: ../src/configure --enable-languages=c,c++ --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls --host=hppa64-hp-hpux11.00 Thread model: single gcc version 4.0.0 Any help appreciated, -dave
Re: Circulate matches in command completion?
On Feb 11, 11:33 am, Peng Yu pengyu...@gmail.com wrote: On Thu, Feb 11, 2010 at 10:36 AM, Chet Ramey chet.ra...@case.edu wrote: On 2/11/10 11:05 AM, Peng Yu wrote: On Thu, Feb 11, 2010 at 9:58 AM, Chet Ramey chet.ra...@case.edu wrote: On 2/11/10 10:54 AM, Peng Yu wrote: Suppose I file 'a1.txt' and 'a2.txt' in my current directory. When I type 'cat a' then TAB, it will show me 'a1.txt' and 'a2.txt'. If I type TAB repeatedly, it will always show me the same thing. However, a better response might be 1. complete the command to 'cat a1.txt' at the 2nd TAB, 2. complete the command to 'cat a2.txt' at the 3rd TAB, 3. return to the original 'cat a' at the 4th TAB, 4. complete the command to 'cat a1.txt' again at the 5th TAB. I'm wondering if there is a way to configure bash this way. bind 'TAB:menu-complete' This is helpful. But it is not exactly what I'm looking for. I still want to show 'a1.txt' and 'a2.txt' at the 1st TAB. The above bind command gives me 'cat a1.txt' directly at the 1st TAB. Look at the 'show-all-if-ambiguous' option. The combination may do what you want. set show-all-if-ambiguous On bind 'TAB:menu-complete' I typed in the above two commands. It seems that command completion is the same as if I only typed in the second command. Do you know why? The first command should be: bind 'set show-all-if-ambiguous On'
Re: process substitution and trailing file descriptors
On Thu, Feb 11, 2010 at 03:04:30AM -0800, Ian wrote: The manual suggests I could move and close file descriptors with [n]digit- but I would need the equivalent of command1 (...)- Digit might very well mean (just a) digit but here the process substitution, of course, is replaced with /dev/fd/63, say, certainly not a digit. Some older versions of bash had issues with FDs higher than 9, but those bugs have certainly been fixed by at least version 4.0. If you aren't stuck supporting old bashes, then exec 63- should work fine, if you happen to know that 63 is the correct FD number. Also bear in mind that not all platforms implement () using /dev/fd/*. On some systems it's done with a FIFO. But I think these are minor details which don't bear directly on your real question. Basically, by mixing IO redirection and process substitution I'm left with a trailing file descriptor which can cause scripts to hang around despite any subsequent redirection of stdout/stderr best practices. There's no mechanism to discover these new file descriptors and they are not closed on exec. Is there any hope for me? When the shortcuts are too short, you need to fall back to the original tools. In this case, () is really just a shortcut for create a FIFO, and open it. Doing so by hand should give you the manual control you need. At the very least, you can tell bash which FD number to use when you open the FIFO.
Re: undefined reference to `__strtoll'
On Thu, Feb 11, 2010 at 12:58:46PM -0500, Dave Moore wrote:
Machine: hppa2.0w
OS: hpux11.00
Compiler: gcc
Bash Version: 4.1
Patch Level: 0
I don't have an HP-UX 11.00 machine to test on, but:
I'm having trouble compiling bash on HP-UX 4.1. I can't figure out how to
work around it. Basically, the version of HP-UX I'm running on doesn't have
strtoll.
It's not supposed to, as far as I'm aware. __strtoll is an internal
libc thing.
bash-3.2# uname -sr
HP-UX B.11.11
bash-3.2# cd /usr/include
bash-3.2# find . -name '*.h' -exec grep strtoll /dev/null {} +
./inttypes.h:extern intmax_t __strtoll (const char *, char**, int);
./inttypes.h:extern intmax_t __strtoll ();
./inttypes.h:#define strtoimax(__a, __b, __c) __strtoll(__a, __b, __c)
There's no man page for strtoll on HP-UX 11.11 either.
So when I'm building, I see these errors:
gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob
-L./lib/tilde -L./lib/malloc -L./lib/sh-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 assoc.o braces.o bracecomp.o
bashhist.o bashline.o siglist.o list.o stringlib.o locale.o findcmd.o
redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh
-lreadline -lhistory -lcurses -ltilde -lmalloc -lintl -ldl
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
If your linker is dumping core, you've got a problem with something more
fundamental than bash.
general.o(.text+0x334): In function `legal_number':
/home/dmoore/gnu/bash-4.1/general.c:175: undefined reference to `__strtoll'
braces.o(.text+0xae4): In function `brace_expand':
/home/dmoore/gnu/bash-4.1/braces.c:395: undefined reference to `__strtoll'
./builtins/libbuiltins.a(printf.o)(.text+0xe6c): In function `getintmax':
./printf.def:998: undefined reference to `__strtoll'
make: *** [bash] Error 1
This also points to a problem with your toolchain. Broken header files,
broken linker, who knows
My version of GCC is
gcc -v
Using built-in specs.
Target: hppa64-hp-hpux11.00
Configured with: ../src/configure --enable-languages=c,c++
--prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64
--with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld
--with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls
--host=hppa64-hp-hpux11.00
Thread model: single
gcc version 4.0.0
I'm using:
bash-3.2# gcc -v
Reading specs from /usr/local/lib/gcc/hppa1.1-hp-hpux11.11/3.4.6/specs
Configured with: ../gcc-3.4.6/configure --with-gnu-as
--with-as=/usr/local/bin/as
Thread model: single
gcc version 3.4.6
(Yeah, I know, an hppa1.1 machine...! That was not easy to get gcc
bootstrapped onto.)
I don't know if there's a specific problem with gcc 4.0.0 on HP-UX 11.00.
That's an awful lot of zeros, though. Things with dot zero on the end
of them tend to scare me a bit.
I see you're using GNU ld, which shouldn't be required on this platform.
And also that ld is dumping core. You might try upgrading your GNU
binutils if you want to continue using GNU ld (or even just rebuilding
your current version); or you might try configuring gcc to use the
system's linker.
In any case, I'm pretty sure it's not a bash bug that you're running into.
(If/when you run into a problem with vsnprintf, *that* is a bash bug,
fixed in one of the 4.1 patches. You might grab the bash patches before
your next attempt, after you get your toolchain working.)
Re: undefined reference to `__strtoll'
Greg Wooledge wrote: Dave Moore wrote: Machine: hppa2.0w OS: hpux11.00 Compiler: gcc ... My version of GCC is gcc -v Using built-in specs. Target: hppa64-hp-hpux11.00 Configured with: ../src/configure --enable-languages=c,c++ --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls --host=hppa64-hp-hpux11.00 Thread model: single gcc version 4.0.0 Are you trying to compile a 32-bit executable or a 64-bit executable? A 32-bit compile should work okay. But a 64-bit compile /may/ have problems. You may be better off trying to compile a 32-bit executable. I don't have an HP-UX 11.00 machine to test on, but: I don't at this time either. I used to though. There is a known problem on HP-UX concerning 64-bit compiles. If the gcc installation is trying to use the system header files then this would probably trickle through. The default compilation mode is 32-bit and 32-bit builds compile okay. But a define in inttypes.h is upside-down and is broken in 64-bit mode. From coreutils notes I have the following patch to the HP-UX system files (use at your own risk) to fix the problem. --- /usr/include/inttypes.h.origThu May 30 01:00:00 1996 +++ /usr/include/inttypes.h Sun Mar 23 00:20:36 2003 @@ -489 +489 @@ -#ifndef __STDC_32_MODE__ +#ifndef __LP64__ As I recall in 64-bit mode all of the strtoull et al routines are broken without this fix. It might have eventually gotten fixed upstream in some later 11.x release by this late date but I don't know. But the problem as reported seems like it may be related. Bob
Re: Circulate matches in command completion?
On Fri, Feb 12, 2010 at 1:36 PM, DennisW dennistwilliam...@gmail.com wrote: On Feb 11, 11:33 am, Peng Yu pengyu...@gmail.com wrote: On Thu, Feb 11, 2010 at 10:36 AM, Chet Ramey chet.ra...@case.edu wrote: On 2/11/10 11:05 AM, Peng Yu wrote: On Thu, Feb 11, 2010 at 9:58 AM, Chet Ramey chet.ra...@case.edu wrote: On 2/11/10 10:54 AM, Peng Yu wrote: Suppose I file 'a1.txt' and 'a2.txt' in my current directory. When I type 'cat a' then TAB, it will show me 'a1.txt' and 'a2.txt'. If I type TAB repeatedly, it will always show me the same thing. However, a better response might be 1. complete the command to 'cat a1.txt' at the 2nd TAB, 2. complete the command to 'cat a2.txt' at the 3rd TAB, 3. return to the original 'cat a' at the 4th TAB, 4. complete the command to 'cat a1.txt' again at the 5th TAB. I'm wondering if there is a way to configure bash this way. bind 'TAB:menu-complete' This is helpful. But it is not exactly what I'm looking for. I still want to show 'a1.txt' and 'a2.txt' at the 1st TAB. The above bind command gives me 'cat a1.txt' directly at the 1st TAB. Look at the 'show-all-if-ambiguous' option. The combination may do what you want. set show-all-if-ambiguous On bind 'TAB:menu-complete' I typed in the above two commands. It seems that command completion is the same as if I only typed in the second command. Do you know why? The first command should be: bind 'set show-all-if-ambiguous On' bind 'set show-all-if-ambiguous On' bind 'TAB:menu-complete' I typed the above commands in the command line, but I still don't see the print out of all matches. Would you please let me know how to debug what is wrong?
Is there a special variable for the directory where the script is in?
$0 gives the file name of the script. I could use several shell command to get the directory where the script is in. But I'm wondering if there is an easy-to-use variable that refers to the directory where the script is in?
Re: Is there a special variable for the directory where the script is in?
On Fri, 12 Feb 2010, Peng Yu wrote:
$0 gives the file name of the script. I could use several shell
command to get the directory where the script is in. But I'm wondering
if there is an easy-to-use variable that refers to the directory where
the script is in?
$0 normally gives the full path to the file, so: ${0%/*}
--
Chris F.A. Johnson http://cfajohnson.com
===
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Re: Is there a special variable for the directory where the script is in?
Peng Yu wrote: $0 gives the file name of the script. I could use several shell command to get the directory where the script is in. But I'm wondering if there is an easy-to-use variable that refers to the directory where the script is in? See this page: http://mywiki.wooledge.org/BashFAQ/028
Re: Is there a special variable for the directory where the script is in?
According to Chris F.A. Johnson on 2/11/2010 4:23 PM:
On Fri, 12 Feb 2010, Peng Yu wrote:
$0 gives the file name of the script. I could use several shell
command to get the directory where the script is in. But I'm wondering
if there is an easy-to-use variable that refers to the directory where
the script is in?
$0 normally gives the full path to the file, so: ${0%/*}
No, $0 normally gives the argv[0], which matches how the file was invoked.
If it was invoked by absolute path (or even an anchored invocation, such
as ./script), then you can compute it yourself. Otherwise, you have to
recreate the PATH walk in your script to determine where the script was
eventually located, and hope that the script was not invoked in such a way
that argv[0] does not match the name of the script being run.
Look at any configure script generated by autoconf for a sample of how
complex it can be to portably locate $myself.
--
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
signature.asc
Description: OpenPGP digital signature
Re: Is there a special variable for the directory where the script is in?
On Thu, 11 Feb 2010, Eric Blake wrote:
According to Chris F.A. Johnson on 2/11/2010 4:23 PM:
On Fri, 12 Feb 2010, Peng Yu wrote:
$0 gives the file name of the script. I could use several shell
command to get the directory where the script is in. But I'm wondering
if there is an easy-to-use variable that refers to the directory where
the script is in?
$0 normally gives the full path to the file, so: ${0%/*}
No, $0 normally gives the argv[0], which matches how the file was invoked.
Or, if it was found in $PATH, the full path to the file.
That is how scripts are normally executed.
If it was invoked by absolute path (or even an anchored invocation, such
as ./script), then you can compute it yourself.
Otherwise, you have to
recreate the PATH walk in your script to determine where the script was
eventually located, and hope that the script was not invoked in such a way
that argv[0] does not match the name of the script being run.
Look at any configure script generated by autoconf for a sample of how
complex it can be to portably locate $myself.
And, of course, there is rarely a good reason to need to know the
location.
--
Chris F.A. Johnson http://cfajohnson.com
===
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
