Re: [PATCH] : bash 4.2 history_search_anywhere using up-down keys

2011-05-25 Thread Niraj Kulkarni

Hi all,
Since I didn't get any replies to earlier message, can anybody 
please clarify me whether that was due to:

1. Poor documentation(feature description)
2. Unnecessary feature
3. Already implemented feature (it wasn't present in bash 4.2 by the 
time first mail was written)


Any reply to this mail is highly appreciated.

Niraj

On Tuesday 17 May 2011 10:33 PM, Niraj Kulkarni wrote:

Hi all,
I have created a simple patch to have history search with 
up-down arrow, to search anywhere within history string (unlike at 
begining in history-search-forward/backward). Please see if it is useful.


Bash version : 4.2

Here is my .inputrc

"\e[A": history-search-backward-new
"\e[B": history-search-forward-new


Niraj





Re: Document what's allowed in function names

2011-05-25 Thread Stephane CHAZELAS
2011-05-24 17:23:20 -0400, Chet Ramey:
[...]
> > Why would you put any restriction on the allowed name of a function?
[...]
> Because Posix does, and because unset without -f has to enforce the variable
> name restrictions.  (Though the language has been relaxed in the latest
> standard.)
[...]

POSIX puts restrictions on the name of functions used by
applications, but I can't see anywhere it restricting what the
shell allows.

'foo bar'() {
  baz
}

being not a valid POSIX syntax, I can't imaging POSIX forcing a
shell to do this (define a "foo bar" function) or that (return
an error message) upon reading it.

I may be wrong though, is there any specific section of the
standard you had in mind?

Note that all of pdksh, mksh, zsh (at least) allow
foo+bar() { w; } for instance
ksh93 allows foo.get() { w; }

I also find it unfortunate that bash doesn't allow

foo() bar

given that every other Bourne-like shell (including the Bourne
shell) supports it (again, it's not POSIX syntax, so bash
doesn't have to implement it, 

-- 
Stephane



Re: [PATCH] : bash 4.2 history_search_anywhere using up-down keys

2011-05-25 Thread Chet Ramey
> Hi all,
>  Since I didn't get any replies to earlier message, can anybody 
> please clarify me whether that was due to:

Speaking for myself, I have not looked at it yet due to a lack of time.

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: Document what's allowed in function names

2011-05-25 Thread Chet Ramey
> 2011-05-24 17:23:20 -0400, Chet Ramey:
> [...]
> > > Why would you put any restriction on the allowed name of a function?
> [...]
> > Because Posix does, and because unset without -f has to enforce the variable
> > name restrictions.  (Though the language has been relaxed in the latest
> > standard.)
> [...]
> 
> POSIX puts restrictions on the name of functions used by
> applications, but I can't see anywhere it restricting what the
> shell allows.

The `application shall ensure ...' language was added long after the first
version of the standard was released.  The original version from 1992
required that a function name be a `name' as the grammar defined it.
I don't know whether that was changed in the 2001 version of the standard,
but it was different by 2004, at least.

> Note that all of pdksh, mksh, zsh (at least) allow
> foo+bar() { w; } for instance
> ksh93 allows foo.get() { w; }

Bash allows all of these forms, as well as things like `!!', by default.
It continues to enforce the original Posix restrictions in Posix mode.

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/



Stumped on a question of scoping and unset.

2011-05-25 Thread Steven W. Orr

I picked up a cool routine called upvars from this location:

http://fvue.nl/wiki/Bash:_Passing_variables_by_reference

I've been using it a lot, but I just ran into a debugging nightmare that I do 
not understand. I'm using the upvars function described in the link above. In 
addition, I wrote (what I thought was pretty clever) a function called glob_array:


glob_array()
{
typeset arrayname
typeset pattern
typeset -a aval
typeset -i nullglob_status=0
typeset -r nullglob_reset=su# Set Unset
typeset -i nn=0

(( $# & 1 )) && die 'ERROR: glob_array takes an even number of args'
shopt -p nullglob > /dev/null
nullglob_status=$?
shopt -s nullglob

while (( $# ))
do
arrayname=$1
pattern="$2"
aval=( $pattern )
nn=${#aval[@]}
# This should never fail as long as $nn matches passing all of aval.
# Check anyways for extra credit.
upvars -a$nn $arrayname "${aval[@]}" || die "ERROR:upvars failed."
shift 2
done
shopt -${nullglob_reset:$nullglob_status:1} nullglob
}

Note that glob_array called upvars. Here's where the trouble happens:

#! /bin/bash

. upvar || die 'Failed to load upvar'
. globarray || die 'Failed to load globarray'

mk_versions()
{
typeset -a bebldsrc

glob_array bebldsrc '*.sh'
echo "bebldsrc:${bebldsrc[@]}"
}

typeset -a bebldsrc

glob_array bebldsrc '*.txt'
echo "main:bebldsrc:${bebldsrc[@]}"
mk_versions
echo "main2:bebldsrc:${bebldsrc[@]}"

When I run this program, the call to glob_array in mk_versions, stomps on the 
bebldsrc array at the global scope instead of just setting the local copy in 
mk_versions. Here's the output:


711 > ./foo.sh
main:bebldsrc:be-ESX-HOWTO-stage.txt be-FW-HOWTO-stage.txt be-HOWTO-stage.txt
bebldsrc:build_netiscsi_pkg.sh copy_hp_srpms.sh foo.sh sni-28.sh 
stage-net-iscsi.sh stage_be_fw.sh unpack-net-iscsi.sh update-be-tarballs.sh 
update-net-iscsi-pkg.sh
main2:bebldsrc:build_netiscsi_pkg.sh copy_hp_srpms.sh foo.sh sni-28.sh 
stage-net-iscsi.sh stage_be_fw.sh unpack-net-iscsi.sh update-be-tarballs.sh 
update-net-iscsi-pkg.sh


The problem seems to be in the definition of upvars. Am I not allowed to use 
glob_array in the same function as the variable that the variable is declared in?


The relevant code in upvars is (probably) this:
   # Error checking
   [[ ${1#-a} ]] || { echo "bash: ${FUNCNAME[0]}: \`$1': missing"\
"number specifier" 1>&2; return 1; }
   printf %d "${1#-a}" &> /dev/null || { echo "bash:"\
"${FUNCNAME[0]}: \`$1': invalid number specifier" 1>&2
return 1; }
   # Assign array of -aN elements
   [[ "$2" ]] && unset -v "$2" && eval $2=\(\"\${@:3:${1#-a}}\"\) &&
shift $((${1#-a} + 2)) || { echo "bash: ${FUNCNAME[0]}:"\
"\`$1${2+ }$2': missing argument(s)" 1>&2; return 1; }

* Why is it needed to use the unset?
* What does unset -v do extra for me?
* What bad things could happen if I don't do the unset?

Anyone have any ideas? :-(

--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net