home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: gnu.bash.bug
- Path: sparky!uunet!cis.ohio-state.edu!fct.unl.PT!spa
- From: spa@fct.unl.PT (Salvador Pinto Abreu)
- Subject: odd `shift' behaviour with bash-1.12
- Message-ID: <SPA.92Aug27153635@khore-dump.fct.unl.pt>
- Sender: gnulists@ai.mit.edu
- Organization: Universidade Nova de Lisboa -- Lisbon, Portugal
- Distribution: gnu
- Date: Thu, 27 Aug 1992 14:36:50 GMT
- Approved: bug-bash@prep.ai.mit.edu
- Lines: 34
-
- The scope of the `shift' command seems to be the innermost loop. For
- example, the following code:
-
- MAX_PARALLEL=...
- MAX_PARALLEL_COUNT=$(echo -n $MAX_PARALLEL | wc -c)
-
- function bug {
- local PARALLEL
-
- while [ -n "$1" ]; do
- PARALLEL=$MAX_PARALLEL
- echo 1>&2 bug: entering parallel loop.
- while [ -n "$1" -a -n "$PARALLEL" ]; do
- ( echo bug: output of $1 & )
- PARALLEL=${PARALLEL#.}
- shift
- done | cat
- [ -z "$LOOP" ] && shift $MAX_PARALLEL_COUNT
- done
- }
-
- bug 1 2 3 4 5 6 7 8 # runs fine
- LOOP=on
- bug 1 2 3 4 5 6 7 8 # loops
-
- the second `shift' needs to be executed to shift the args to `bug',
- even though they were already (supposed to have been) kicked out by
- the `shift' in the inner loop.
-
- bug or feature?
-
- PS: tried on Ultrix 4.2, HP/UX A.B8.05 and NeXT Mach 2.2.
- --
-
-