set -e, but test return not honoured _conditionally_
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: darwin10.0
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='darwin10.0' -DCONF_MACHTYPE='i386-apple-darwin10.0'
-DCONF_VENDOR='apple' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -DMACOSX -I. -I/SourceCache/bash/bash-80/bash
-I/SourceCache/bash/bash-80/bash/include -I/SourceCache/bash/bash-80/bash/lib
-I/SourceCache/bash/bash-80/bash/lib/intl -I/var/tmp/bash/bash-80~440/lib/intl
-arch x86_64 -arch i386 -g -Os -pipe -no-cpp-precomp -mdynamic-no-pic -DM_UNIX
-DSSH_SOURCE_BASHRC
uname output: Darwin sherwood.local 10.6.0 Darwin Kernel Version 10.6.0: Wed
Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386
Machine Type: i386-apple-darwin10.0
Bash Version: 3.2
Patch Level: 48
Release Status: release
Description:
I am not a sophisticated shell programmer, but i really think this
time it's a shell fault.
You may invoke the code snippet via 'script test1 test3' or so.
#!/bin/sh
set -e
_t() {
echo "Entry _t for $CURR"
test "$PARAMS" != "${PARAMS/$CURR/}" && { return; }
# Uncomment the next line and the script won't fail!
#echo "Exit _t for $CURR"
}
PARAMS="$@"
CURR='test1' _t
CURR='test2' _t
CURR='test3' _t
Question. Autocomplete paths starting with %.
Hi, I'm not subscribed to this list so please make sure to CC me if you want me to receive the reply. I'd like to hack some solution based on: http://www.huyng.com/bashmarks-directory-bookmarks-for-the-shell/ but to be able to use saved bookmarks in other commands (explanation below). So if I have a bookmark: webdir=/home/dpc/www I could do: $ cp xfile %webd and that autocomplete to: $ cp xffile /home/dpc/www The % signed would be similar to what bash already does for @, ~ and $. Only this one would be for bookmarks. I can script in Bash quite well, but I've never did anything that fancy with completion and I don't know how to plug my function to handle this. I understand that I should register something (function named like _bookmarkcomp) to handle filename completion for things beginning with %. If you help me with this one I promise to post my solution for benefit of other bash users. Regards, Dawid -- http://dpc.ucore.info
Strange bug in arithmetic function
In a bash script I use: $[`date --date='this week' +'%V'`%2] to see if the week number is even. Only in week 08 the error is: bash: 08: value too great for base (error token is "08") the same in week 09, all others are Ok... GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. Running Ubutu 2.6.24-28 server -- Regards, Marcel de Reuver mailto:mar...@de.reuver.org
Re: Strange bug in arithmetic function
On Monday 21 Feb 2011 09:13:54 Marcel de Reuver wrote: > In a bash script I use: $[`date --date='this week' +'%V'`%2] to see if > the week number is even. > Only in week 08 the error is: bash: 08: value too great for base > (error token is "08") the same in week 09, all others are Ok... It's not a bug. First, you shouldn't use the ancient and deprecated $[ .. ] syntax for arithmetic evaluation; use $(( .. )). Second, bash interprets numbers with leading zeros as octal, thus "08" isn't a valid octal number. You can force it to be interpreted as decimal by prepending the base, eg see $ echo $(( 08 + 2 )) -su: 08: value too great for base (error token is "08") $ echo $(( 10#08 + 2 )) 10 -- D.
Re: set -e, but test return not honoured _conditionally_
On Fri, Feb 18, 2011 at 04:36:06PM +0100, Steffen Daode Nurpmeso wrote:
> I am not a sophisticated shell programmer, but i really think this
> time it's a shell fault.
You think *what* is the shell's fault?
> You may invoke the code snippet via 'script test1 test3' or so.
>
> #!/bin/sh
> set -e
>
> _t() {
> echo "Entry _t for $CURR"
> test "$PARAMS" != "${PARAMS/$CURR/}" && { return; }
> # Uncomment the next line and the script won't fail!
> #echo "Exit _t for $CURR"
> }
>
> PARAMS="$@"
>
> CURR='test1' _t
> CURR='test2' _t
> CURR='test3' _t
Setting aside for the moment what you are attmepting to do here (which
looks rather unorthodox), I don't see what your complaint is. You
asked for "set -e", meaning for the shell to exit any time a simple
command fails. Then you called three simple commands in a row, each
one named "_t". If any of them fails, the shell is supposed to exit.
And it does so, yes? Is that what you are complaining about?
Are you confused about what your function is doing? It is returning
success or failure based on what's in the variables PARAMS and CURR.
When it fails, the exit status tells bash to abort, because you asked
bash to do so.
http://mywiki.wooledge.org/BashFAQ/035 - How can I handle command-line
arguments (options) to my script easily?
http://mywiki.wooledge.org/BashFAQ/105 -- Why doesn't set -e (set -o
errexit) do what I expected?
Re: set -e, but test return not honoured _conditionally_
On Fri, Feb 18, 2011 at 5:36 PM, Steffen Daode Nurpmeso <
sdao...@googlemail.com> wrote:
>
> Configuration Information [Automatically generated, do not change]:
> Machine: i386
> OS: darwin10.0
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
> -DCONF_OSTYPE='darwin10.0' -DCONF_MACHTYPE='i386-apple-darwin10.0'
> -DCONF_VENDOR='apple' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I/SourceCache/bash/bash-80/bash
> -I/SourceCache/bash/bash-80/bash/include
> -I/SourceCache/bash/bash-80/bash/lib
> -I/SourceCache/bash/bash-80/bash/lib/intl
> -I/var/tmp/bash/bash-80~440/lib/intl -arch x86_64 -arch i386 -g -Os -pipe
> -no-cpp-precomp -mdynamic-no-pic -DM_UNIX -DSSH_SOURCE_BASHRC
> uname output: Darwin sherwood.local 10.6.0 Darwin Kernel Version 10.6.0:
> Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386
> Machine Type: i386-apple-darwin10.0
>
> Bash Version: 3.2
> Patch Level: 48
> Release Status: release
>
> Description:
> I am not a sophisticated shell programmer, but i really think this
> time it's a shell fault.
> You may invoke the code snippet via 'script test1 test3' or so.
>
>#!/bin/sh
>set -e
>
>_t() {
>echo "Entry _t for $CURR"
>test "$PARAMS" != "${PARAMS/$CURR/}" && { return; }
># Uncomment the next line and the script won't fail!
>#echo "Exit _t for $CURR"
>}
>
>PARAMS="$@"
>
>CURR='test1' _t
>CURR='test2' _t
>CURR='test3' _t
set -e only exits the shell when simple commands exit with errors, and not
for commands with && for instance.
Re: Strange bug in arithmetic function
On Mon, Feb 21, 2011 at 11:13 AM, Marcel de Reuver wrote: > In a bash script I use: $[`date --date='this week' +'%V'`%2] to see if > the week number is even. > Only in week 08 the error is: bash: 08: value too great for base > (error token is "08") the same in week 09, all others are Ok... > > GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) > Copyright (C) 2007 Free Software Foundation, Inc. > > Running Ubutu 2.6.24-28 server > > This is a feature, numbers with a leading 0 are interpreted as octal. also $[ ] is deprecated, prefer $(( ))
Re: set -e, but test return not honoured _conditionally_
On Tue, Feb 22, 2011 at 3:46 PM, Greg Wooledge wrote:
> On Fri, Feb 18, 2011 at 04:36:06PM +0100, Steffen Daode Nurpmeso wrote:
> > I am not a sophisticated shell programmer, but i really think this
> > time it's a shell fault.
>
> You think *what* is the shell's fault?
>
> > You may invoke the code snippet via 'script test1 test3' or so.
> >
> > #!/bin/sh
> > set -e
> >
> > _t() {
> > echo "Entry _t for $CURR"
> > test "$PARAMS" != "${PARAMS/$CURR/}" && { return; }
> > # Uncomment the next line and the script won't fail!
> > #echo "Exit _t for $CURR"
> > }
> >
> > PARAMS="$@"
> >
> > CURR='test1' _t
> > CURR='test2' _t
> > CURR='test3' _t
>
> Setting aside for the moment what you are attmepting to do here (which
> looks rather unorthodox), I don't see what your complaint is. You
> asked for "set -e", meaning for the shell to exit any time a simple
> command fails. Then you called three simple commands in a row, each
> one named "_t". If any of them fails, the shell is supposed to exit.
> And it does so, yes? Is that what you are complaining about?
>
> Are you confused about what your function is doing? It is returning
> success or failure based on what's in the variables PARAMS and CURR.
> When it fails, the exit status tells bash to abort, because you asked
> bash to do so.
>
> http://mywiki.wooledge.org/BashFAQ/035 - How can I handle command-line
> arguments (options) to my script easily?
>
> http://mywiki.wooledge.org/BashFAQ/105 -- Why doesn't set -e (set -o
> errexit) do what I expected?
>
>
More explanations on your example.
This line:
test "$PARAMS" != "${PARAMS/$CURR/}" && { return; }
Never cause the shell to exit because it's complex command
However it causes the shell function to exit with non 0 if the test fails.
So your call to _t returns with 1 and the shell exits because _t is a simple
command
When you add echo, it is executed because the complex command doesn't cause
the shell to exit and since echo succeeds,
it causes the function to return 0 and your call to _t doesn't exit the
shell anymore.
PS: maybe you wanted "|| return" so that it always return 0?
Re: Strange bug in arithmetic function
On 02/21/2011 02:13 AM, Marcel de Reuver wrote: > In a bash script I use: $[`date --date='this week' +'%V'`%2] to see if > the week number is even. > Only in week 08 the error is: bash: 08: value too great for base > (error token is "08") the same in week 09, all others are Ok... 08 is an invalid octal number. Try forcing decimal instead: $[$(date --date='this week' +'10#%V')%2] -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: no way to give 'select' a default value
On Mon, Feb 21, 2011 at 04:05:34PM +0800, jida...@jidanni.org wrote: > There is no way to give the 'select' command a default value, so all the > user does is need to hit return. > $ help select > ... If the line is empty, WORDS and the prompt are redisplayed. `select' is extremely limited. If you need any kind of flexibility that it doesn't offer, just scrap it and write your own while/read/test loop.
Re: no way to give 'select' a default value
On Tue, Feb 22, 2011 at 9:53 PM, Greg Wooledge wrote: > On Mon, Feb 21, 2011 at 04:05:34PM +0800, jida...@jidanni.org wrote: > > There is no way to give the 'select' command a default value, so all the > > user does is need to hit return. > > $ help select > > ... If the line is empty, WORDS and the prompt are redisplayed. > > `select' is extremely limited. If you need any kind of flexibility that > it doesn't offer, just scrap it and write your own while/read/test loop. > > Agree. I've never used `select' in my scripts. -- Clark J. Wang
Re: Patterns of dynamic scoping and nested routines.
On 2/21/11 11:11 PM, Steven W. Orr wrote: > It has been an exciting weekend for me. I studied the dynamic vs static > scoping rules and I think I have a better handle on things, but I have a > few questions. > > It seems that there's no reason why we are not allowed to write nested > functions. Nested functions would not be visible to other functions, and > might be a way of providing capabilities to users to specify *when* they > want to have static scoping. You already can write nested functions, and those functions are not declared until their `containing' function is called. They just have global scope, since there's no mechanism to declare a local function. Any extension to restrict functions to local scope would have to be backwards compatible with that. Chet -- ``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: Strange bug in arithmetic function
On Mon, Feb 21, 2011 at 04:13:54AM EST, Marcel de Reuver wrote: > In a bash script I use: $[`date --date='this week' +'%V'`%2] to see if > the week number is even. > Only in week 08 the error is: bash: 08: value too great for base > (error token is "08") the same in week 09, all others are ok... Due to the prepended zero, bash thinks you are using octal (base 8) numbers. Compare: $ a=$((7+8)) $ echo $a 15 $ a=$((7+08)) $ bash: 08: value too great for base (error token is "08") cj
document factors influencing select's number of columns
The 'select' documentation should also document the perhaps complex way $LINES $COLUMNS the number of items the length of the longest item interact to determine if the items will be displayed in rows/columns, etc.
Re: Strange bug in arithmetic function
On Mon, 21 Feb 2011 10:13:54 +0100, Marcel de Reuver wrote: > In a bash script I use: $[`date --date='this week' +'%V'`%2] to see if > the week number is even. > Only in week 08 the error is: bash: 08: value too great for base (error > token is "08") the same in week 09, all others are Ok... > > GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) > 2007 Free Software Foundation, Inc. > > Running Ubutu 2.6.24-28 server >From the bash manpage uhder ARITHMETIC EVALUATION "Constants with a leading 0 are interpreted as octal numbers." The digits 8 and 9 are invalid. Octal digits are 1,2,3,4,5,6,7,0 You can force base 10 by putting 10# before your numbers.
Patch: Corrupt display for history search in vi-mode, 256-color prompt
This bug affects both readline and bash (however, it is expected that
this bug is far more likely to affect bash than other typical
readline-using applications). It was experienced on bash 4.1-2ubuntu4
(on Ubuntu 10.10, "Maverick Meercat"), but I checked the sources for
readline 6.2 and bash 4.2, and the relevant code is unchanged.
The original report is on Ubuntu's "Malone" bugtracker (on Launchpad):
https://bugs.launchpad.net/debian/+source/bash/+bug/721982
Following is a copy-paste from that bugtracker, with slight
modifications to make it slightly more appropriate for this forum.
-
I use bash with a prompt that is derived from the current backgrounded
jobs (the script I use to do this is at
http://micah.cowan.name/hg/promptjobs/ - you just source the file and it
does everything). I've customized the colors used, to take advantage of
256-color support in gnome-terminal. An instance of the prompt that
might be produced is:
PS1="\[\033[m\017\033[38;5;103m\]micah-acer\[\033[1m\033[38;5;19m\](\[\033[m\017\033[38;5;83m\]\061\[\033[m\017\033[38;5;189m\]wtitle\[\033[1m\033[38;5;19m\])\[\033[m\017\033[m\017\033[38;5;103m\]$
\[\033[m\017\]"
(This prompt will only display correctly in xterm-compatible terminals;
the term I use is gnome-terminal. PLEASE remove all newlines that appear
due to wrapping by my MUA.)
With a prompt like this, and in vi-mode ("set -o vi" in bash),
attempting to initiate a search in the history, results in display
glitches (specifically, the history line bash/readline jumps to is
displayed far over to the right, and with a couple garbage characters
before it).
Steps to reproduce:
1. Be in vi-mode ("set -o vi" in bash): in particular, readline's
"non-incremental-reverse-search-history" MUST be bound to the "/" key,
as this has significant effects on how bash/readline choose to prompt
for a history search string (even though, for me at least, the "bind"
command doesn't seem to reflect this). If you're running these steps, it
would be advisible for you to be sufficiently familiar with vi-style
bindings to know how to enter commands.
2. Set PS1 as described above.
3. Invoke the non-incremental-reverse-search-history function by
pressing ESC (to escape vi's insert-mode) and "/" (to prompt for reverse
history).
4. At this point, the "/" you just typed may not be showing up properly:
this is the first symptom that something's wrong.
5. Type in some string that should be present in your recent bash
history (so that bash will jump to a different line), and hit enter.
Result:
The history line bash jumps to will be drawn in the wrong location (far
right of the prompt), and with garbage characters; typing "k" or "j" (or
the cursor keys) to move up or down in history continues to draw these
lines in the wrong location.
Expected Result:
The jumped-to line ought to be drawn immediately to the right of the
prompt, and without garbage characters before it.
Cause of bug:
This bug is from readline, and is also found in bash's own built-in
readline code. The bug lies in the function rl_message in display.c,
which is called by _rl_nsearch_init, which is called from noninc_search.
rl_message is primarily intended for writing a "message" on the current
line, which doesn't normally include "invisible" characters (escape
sequences, like the one I'm using in my prompt to set advanced colors),
but in this case is being (ab)used to include the prompt. It uses a
buffer of only 128 characters, which in the case of the above
prompt/PS1, is overrun. As long as the system library provides
vsnprintf, this does not lead to a potential buffer overflow, but the
results are truncated, and this is the source of the graphical display
glitch, because (a) the prompt is truncated in the middle of a sequence
of "invisible" characters, and (b) I think the readline code may have
other bugs that cause character-counting not to work properly if the
prompt itself is not completely present at the beginning of a buffer
whose value is derived from the result of rl_message.
Solution:
rl_message ought to use a dynamically-allocated buffer instead, so it
can adjust the size as needed. Patch provided; see link below.
Workaround:
The statically-allocated buffer is only used to store the final line in
a multi-line prompt (including any invisible characters, and the special
codes used by readline to mark the start and end of invisible-character
sequences). Thus, if you add a newline in the prompt just before the "\$
", the static buffer should have plenty of room. Similar methods might
include not using 256 color support, or any other means to shorten the
total size of the [final line of the] prompt string below 127.
A patch that fixes this issue for me may be found at the Ubuntu
bugtracker link given above (here it is again):
https://bugs.launchpad.net/debian/+source/bash/+bug/721982
--
Micah J. Cowan
http://micah.cowan.name/
Re: Patch: Corrupt display for history search in vi-mode, 256-color prompt
2011/2/22 Micah Cowan :
> This bug affects both readline and bash (however, it is expected that
> this bug is far more likely to affect bash than other typical
> readline-using applications). It was experienced on bash 4.1-2ubuntu4
> (on Ubuntu 10.10, "Maverick Meercat"), but I checked the sources for
> readline 6.2 and bash 4.2, and the relevant code is unchanged.
>
> The original report is on Ubuntu's "Malone" bugtracker (on Launchpad):
> https://bugs.launchpad.net/debian/+source/bash/+bug/721982
>
> Following is a copy-paste from that bugtracker, with slight
> modifications to make it slightly more appropriate for this forum.
> -
>
> I use bash with a prompt that is derived from the current backgrounded
> jobs (the script I use to do this is at
> http://micah.cowan.name/hg/promptjobs/ - you just source the file and it
> does everything). I've customized the colors used, to take advantage of
> 256-color support in gnome-terminal. An instance of the prompt that
> might be produced is:
>
> PS1="\[\033[m\017\033[38;5;103m\]micah-acer\[\033[1m\033[38;5;19m\](\[\033[m\017\033[38;5;83m\]\061\[\033[m\017\033[38;5;189m\]wtitle\[\033[1m\033[38;5;19m\])\[\033[m\017\033[m\017\033[38;5;103m\]$
> \[\033[m\017\]"
>
> (This prompt will only display correctly in xterm-compatible terminals;
> the term I use is gnome-terminal. PLEASE remove all newlines that appear
> due to wrapping by my MUA.)
>
> With a prompt like this, and in vi-mode ("set -o vi" in bash),
> attempting to initiate a search in the history, results in display
> glitches (specifically, the history line bash/readline jumps to is
> displayed far over to the right, and with a couple garbage characters
> before it).
>
> Steps to reproduce:
>
> 1. Be in vi-mode ("set -o vi" in bash): in particular, readline's
> "non-incremental-reverse-search-history" MUST be bound to the "/" key,
> as this has significant effects on how bash/readline choose to prompt
> for a history search string (even though, for me at least, the "bind"
> command doesn't seem to reflect this). If you're running these steps, it
> would be advisible for you to be sufficiently familiar with vi-style
> bindings to know how to enter commands.
> 2. Set PS1 as described above.
> 3. Invoke the non-incremental-reverse-search-history function by
> pressing ESC (to escape vi's insert-mode) and "/" (to prompt for reverse
> history).
> 4. At this point, the "/" you just typed may not be showing up properly:
> this is the first symptom that something's wrong.
> 5. Type in some string that should be present in your recent bash
> history (so that bash will jump to a different line), and hit enter.
>
> Result:
> The history line bash jumps to will be drawn in the wrong location (far
> right of the prompt), and with garbage characters; typing "k" or "j" (or
> the cursor keys) to move up or down in history continues to draw these
> lines in the wrong location.
>
> Expected Result:
> The jumped-to line ought to be drawn immediately to the right of the
> prompt, and without garbage characters before it.
>
> Cause of bug:
> This bug is from readline, and is also found in bash's own built-in
> readline code. The bug lies in the function rl_message in display.c,
> which is called by _rl_nsearch_init, which is called from noninc_search.
> rl_message is primarily intended for writing a "message" on the current
> line, which doesn't normally include "invisible" characters (escape
> sequences, like the one I'm using in my prompt to set advanced colors),
> but in this case is being (ab)used to include the prompt. It uses a
> buffer of only 128 characters, which in the case of the above
> prompt/PS1, is overrun. As long as the system library provides
> vsnprintf, this does not lead to a potential buffer overflow, but the
> results are truncated, and this is the source of the graphical display
> glitch, because (a) the prompt is truncated in the middle of a sequence
> of "invisible" characters, and (b) I think the readline code may have
> other bugs that cause character-counting not to work properly if the
> prompt itself is not completely present at the beginning of a buffer
> whose value is derived from the result of rl_message.
>
> Solution:
> rl_message ought to use a dynamically-allocated buffer instead, so it
> can adjust the size as needed. Patch provided; see link below.
>
> Workaround:
> The statically-allocated buffer is only used to store the final line in
> a multi-line prompt (including any invisible characters, and the special
> codes used by readline to mark the start and end of invisible-character
> sequences). Thus, if you add a newline in the prompt just before the "\$
> ", the static buffer should have plenty of room. Similar methods might
> include not using 256 color support, or any other means to shorten the
> total size of the [final line of the] prompt string below 127.
>
> A patch that fixes this issue for me may be found at the Ubuntu
> bugtracker link given above (here it is again):
>
>
How to match pattern in bash?
Suppose that I have a variable $x, I want to test if the content of $x match the pattern 'abc*'. If yes, then do something. (The operator == doesn't match patterns, if I understand it correctly.) Is there such a build-in feature in bash? Or I have to rely on some external program such as perl to test the pattern matching? -- Regards, Peng
Re: How to match pattern in bash?
On Wed, Feb 23, 2011 at 11:24 AM, Peng Yu wrote: > Suppose that I have a variable $x, I want to test if the content of $x > match the pattern 'abc*'. If yes, then do something. (The operator == > doesn't match patterns, if I understand it correctly.) > > Reread the bash manual about [[ == ]]. > Is there such a build-in feature in bash? Or I have to rely on some > external program such as perl to test the pattern matching? > > -- > Regards, > Peng > > -- Clark J. Wang
Re: How to match pattern in bash?
On 02/22/2011 08:24 PM, Peng Yu wrote: > Suppose that I have a variable $x, I want to test if the content of $x > match the pattern 'abc*'. If yes, then do something. (The operator == > doesn't match patterns, if I understand it correctly.) > > Is there such a build-in feature in bash? Or I have to rely on some > external program such as perl to test the pattern matching? case $x in abc*) ... ;; esac -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How to match pattern in bash?
On 02/22/2011 07:24 PM, Peng Yu wrote:
> Suppose that I have a variable $x, I want to test if the content of $x
> match the pattern 'abc*'. If yes, then do something. (The operator ==
> doesn't match patterns, if I understand it correctly.)
>
> Is there such a build-in feature in bash? Or I have to rely on some
> external program such as perl to test the pattern matching?
Bash provides a few ways to do this that I can think of.
One portable way (the one I generally use), is to take advantage of the
fact that you can strip prefixes or suffixes from variables if they
match some specified pattern. This is portable to all POSIX-compliant sh
implementations. (Edit just before send-off: so is Eric Blake's.)
If the wildcard matches as a prefix of the variable, then it will no
longer compare equal to the variable (and will, otherwise).
test "x${var}" != "x${var##abc*}"
(Of course, for examples like yours where they just end in a *, the * is
unnecessary for the pattern, and you can just check for a prefix of
"x${var##abc}").
Bash's special builtin [[ ]] syntax also provides both wildcards, and
(much more powerful) extended regexes (roughly similar to Perl regexes;
they're what egrep uses).
Wildcards:
[[ $var == abc* ]]
Regex:
[[ $var =~ ^abc.* ]]
--
HTH,
Micah J. Cowan
http://micah.cowan.name/
Re: Question. Autocomplete paths starting with %.
On Sat, Feb 19, 2011 at 9:20 PM, d...@ucore.info wrote:
>
> I can script in Bash quite well, but I've never did anything that
> fancy with completion and I don't know how to plug my function to
> handle this. I understand that I should register something (function
> named like _bookmarkcomp) to handle filename completion for things
> beginning with %.
>
> If you help me with this one I promise to post my solution for benefit
> of other bash users.
>
> Regards,
> Dawid
> --
> http://dpc.ucore.info
>
>
I can give you an example here:
bash# vi compgen-example.sh
_compgen_foo()
{
local cmd=$1 cur=$2 pre=$3
if [[ $cur = % ]]; then
COMPREPLY[0]='it-works'
fi
}
complete -F _compgen_foo foo
bash# source compgen-example.sh
bash# foo %<-- Press TAB here
bash# foo it-works<-- `%' will be expanded like this
--
Clark J. Wang
