Re: nullglob option breaks complex parameter expansion/deletion

[Michael Wardle]

Hi Chet

Thanks for your very prompt reply.

I understand that globbing is happening, but I don't understand why
deleting a parameter should occur with nullglob set if the parameter
matches but the word to delete doesn't.  The bash behavior seems to make
this construct useful only for file name deletion if nullglob is set,
when it seems to be useful for any substring deletion if nullglob is
unset.

I also noticed in the POSIX standard that quoting the word part should
cause it to be literal and prevent globbing.  If I try this in bash, I
get the same result as in my original message, that is:

$ shopt -s nullglob
$ connectioninfo='${HOST%%".*"} ${USER}'
$ echo $connectioninfo
${USER}

I think $connectioninfo should remain unchanged due to the word being
quoted, and wonder if bash supports this quoting syntax.




___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: nullglob option breaks complex parameter expansion/deletion

[Michael Wardle]

> I also noticed in the POSIX standard that quoting the word part should
> cause it to be literal and prevent globbing.  If I try this in bash, I
> get the same result as in my original message, that is:
> 
> $ shopt -s nullglob
> $ connectioninfo='${HOST%%".*"} ${USER}'
> $ echo $connectioninfo
> ${USER}

Actually, this seems similar to the following:

$ shopt -s nullglob
$ echo $USER
michael
$ var='${USER}".*"'
$ typeset -p var
declare -- var="\${USER}\".*\""
$ echo $var

$ echo "$var"
${USER}".*"
$ eval echo "$var"
michael.*

It looks like a bare $var is being expanded multiple times in a way that
I don't understand, but perhaps that is just the nature of shell.




___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Inconsistent handling of arrays.

[Aaron Marks]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='lin$uname output: Linux crx 2.6.12 #4 Thu Jun 30
12:33:41 EST 2005 i686 unknown unk$Machine Type: i686-pc-linux-gnu

Bash Version: 3.0
Patch Level: 0
Release Status: release

Description:
The array handling is inconsistent across global variables and
local variables. See the Repeat-By for more information.

While this behaviour can be avoided by using 'local -a ...', it
is inconsistent and a cause for confusion. Local's (and declare'd
variables) should at least act like their global undeclared
counterparts without any options specified.

Repeat-By:
--BEGIN SCRIPT--

#!/bin/bash
somefunc() {
echo "ARRAY BEHAVIOUR WITH GLOBAL:"
# proper handling with global
globvar1=($(ls /))
#   echo "Contents of globvar1: [EMAIL PROTECTED]"
echo "Length of globvar1: ${#globvar1}"
echo "Contents of globvar1[0]: ${globvar1[0]}"

globvar2=(`ls /`)
#   echo "Contents of globvar2: [EMAIL PROTECTED]"
echo "Length of globvar2: ${#globvar2}"
echo "Contents of globvar2[0]: ${globvar2[0]}"

echo "INCONSISTENT BAHAVIOUR WITH LOCAL:"
# inconsistent bahaviour local
othervar1=($(ls /))
#   echo "Contents of othervar1: [EMAIL PROTECTED]"
echo "Length of othervar1: ${#othervar1}"
echo "Contents of othervar1[0]: ${othervar1[0]}"

local othervar2=($(ls /))
#   echo "Contents of othervar2: [EMAIL PROTECTED]"
echo "Length of othervar2: ${#othervar2}"
echo "Contents of othervar2[0]: ${othervar2[0]}"


echo "PROPER HANDLING, BUT SYNTAX INCONSISTENT WITH
GLOBAL VARS$# this handles it properly, but the -a
should not be required
# Local and global variables should at least seem to be treated
# the same.
local -a somevar1=(`ls /`)
#   echo "Contents of somevar1: [EMAIL PROTECTED]"
echo "Length of somevar1: ${#somevar1}"
echo "Contents of somevar1[0]: ${somevar1[0]}"

local -a somevar2=(`ls /`)
#   echo "Contents of somevar2: [EMAIL PROTECTED]"
echo "Length of somevar2: ${#somevar2}"
echo "Contents of somevar2[0]: ${somevar2[0]}"
}

somefunc

--END SCRIPT--


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Controlling terminal race condition

[Chet Ramey]

Paul Jarc wrote:
> Jeff Miller <[EMAIL PROTECTED]> wrote:
> 
>>It is possible on our test Solaris 8 system that the original
>>calling bash shell will set the controlling process of the terminal
>>to the pid that it originally forked to after the new process had
>>been created. In this case is not the new bash process. It happens
>>to do this after the new bash has done it's write but before it has
>>done it's read, this new process still assumes it is still the
>>controlling process.
> 
> 
> Chet, could the foreground process group be set by the forked child
> itself, before the exec, instead of by the parent?  That would at
> least eliminate the race condition so the results would be
> predictable, and I think it would prevent the problem in this case.

It is.  The terminal process group is set N+1 times in a N-stage
pipeline:  once by each child, and once by the parent.  This was
considered `best practice' by the POSIX people when I put it in.
I still think it's the best way to avoid problems.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live...Laugh...Love
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Feature-Request: Append command to history

[Chet Ramey]

Matthias Schniedermeyer wrote:

> Thank you for this great news. :-)
> 
> How do you plan to "fix" that bug?

Don't delete the last command from the history if it was pushed
with `history -s'.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live...Laugh...Love
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: nullglob option breaks complex parameter expansion/deletion

[Chet Ramey]

Michael Wardle wrote:
> Hi Chet
> 
> Thanks for your very prompt reply.
> 
> I understand that globbing is happening, but I don't understand why
> deleting a parameter should occur with nullglob set if the parameter
> matches but the word to delete doesn't.  The bash behavior seems to make
> this construct useful only for file name deletion if nullglob is set,
> when it seems to be useful for any substring deletion if nullglob is
> unset.

The word in question is *not* being parameter expanded.  It is the
result of a *different* parameter expansion:  the unquoted expansion
of $connectioninfo.

Since the results of the parameter expansion of $connectioninfo are
subject to filename expansion, the unquoted `*' in that word is run
through *normal filename expansion*.  Since that expansion looks only
for filenames and, since nullglob is set, deletes words containing
globbing operators that don't match filenames, the word ends up being
removed.

You might get a clearer picture of what's happening if you ran

echo "$connectioninfo"

and inhibited the filename expansion that normally takes place.

> I also noticed in the POSIX standard that quoting the word part should
> cause it to be literal and prevent globbing.  If I try this in bash, I
> get the same result as in my original message, that is:

You have misunderstood which expansion needs to be quoted.  It's the
expansion of $connectioninfo that needs quoting, as above.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live...Laugh...Love
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Inconsistent handling of arrays.

[Chet Ramey]

Aaron Marks wrote:

> Bash Version: 3.0
> Patch Level: 0
> Release Status: release
> 
> Description:
> The array handling is inconsistent across global variables and
> local variables. See the Repeat-By for more information.

This is the same problem, with the same fix, as the `declare' report I
responded to earlier this week.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live...Laugh...Love
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: nullglob option breaks complex parameter expansion/deletion

[Michael Wardle]

On Sat, 2005-07-02 at 12:24 -0400, Chet Ramey wrote:
> Michael Wardle wrote:
> > Hi Chet
> > 
> > Thanks for your very prompt reply.
> > 
> > I understand that globbing is happening, but I don't understand why
> > deleting a parameter should occur with nullglob set if the parameter
> > matches but the word to delete doesn't.  The bash behavior seems to make
> > this construct useful only for file name deletion if nullglob is set,
> > when it seems to be useful for any substring deletion if nullglob is
> > unset.
> 
> The word in question is *not* being parameter expanded.  It is the
> result of a *different* parameter expansion:  the unquoted expansion
> of $connectioninfo.

I wasn't saying that the right-hand side was being parameter expanded.
I was trying to use the wording in the POSIX standard, which states:
"The word shall be expanded to produce a pattern."  I think this is
supposed to refer to file name expansion (globbing), but I confess to
being confused by this wording myself.

> Since the results of the parameter expansion of $connectioninfo are
> subject to filename expansion, the unquoted `*' in that word is run
> through *normal filename expansion*.  Since that expansion looks only
> for filenames and, since nullglob is set, deletes words containing
> globbing operators that don't match filenames, the word ends up being
> removed.

I understand that normal file name expansion is occurring, but I can't
see any use for it in this construct.  I would be happy to learn of such
a use, but in the absence of one, I would advocate the parameter
deletions such as ${parameter%word} be a special case not subject to
nullglob.

> You might get a clearer picture of what's happening if you ran
> 
>   echo "$connectioninfo"
> 
> and inhibited the filename expansion that normally takes place.

I believe my followup exhibited this understanding.

> > I also noticed in the POSIX standard that quoting the word part should
> > cause it to be literal and prevent globbing.  If I try this in bash, I
> > get the same result as in my original message, that is:
> 
> You have misunderstood which expansion needs to be quoted.  It's the
> expansion of $connectioninfo that needs quoting, as above.

POSIX says this:
${x#"*"}
The literal asterisk is quoted and not special.

Which leads me to believe that quoting the asterisk should have the
desired result, and certainly at least a different result from that
which I am seeing.

Again, I don't understand why nullglob is useful inside ${parameter%%
word}, and it's certainly not obvious why quoting the right-hand side
should be necessary.




___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Expansions in arithmetic commands and subscripts

[Thorsten Dahlheimer]

Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: cygwin
Compiler: gcc
Compilation
CFLAGS:  -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='cygwin' 
-DCONF_MACHTYPE='i586-pc-cygwin' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/
locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS  -I.  -I/ho
me/xxx/bash/bash-3.0 -I/home/xxx/bash/bash-3.0/include -I/home/xxx/bash/bash
-3.0/lib   -O2
uname output: CYGWIN_98-4.10 pcdahl4201 1.5.18s(0.130/4/2) 20050611 15:29:08
i586 unknown unknown Cygwin
Machine Type: i586-pc-cygwin

Bash Version: 3.0
Patch Level: 16
Release Status: release

Description:
According to the documentation, bash should treat the expression inside
a (( ... )) command as if it were double-quoted, and it probably should
treat the expressions in an arithmetic "for" command in the same way for
consistency.
But actually it doesn't do so:  The expressions in arithmetic commands
and arithmetic "for" commands undergo brace expansion, tilde expansion,
and process substitution, and quote removal happens like in unquoted
strings.
The situation is similar with array subscripts, where brace expansion
and tilde expansion are suppressed but process substitution and quote
removal like in unquoted strings occur.  Although the manual doesn't
specify the behaviour in this regard, I think that array subscripts
should also be treated as if they were double-quoted for consistency.

Repeat-By:
$ (( {1+1, '@!#?'} )) && echo 'ok!?'
ok!?

$ # "user" is a valid user name on the system
$ for (( user=5; ~user; user-- )); do echo $user; done
bash: ((: /home/user: syntax error: operand expected (error token is
"/home/user")

$ (( 1<(2+3)*4 )) && echo 'math ok'
bash: ((: 1/proc/self/fd/63*4 : division by 0 (error token is "/self/fd/63*4
")

$ (( '1' + \1 + "1" == 3 )) && echo 'valid!?'
valid!?

$ a=(0 1 2 3)
$ echo ${a[1<(2+3)*4]}
bash: 1/proc/self/fd/63*4: division by 0 (error token is "/self/fd/63*4")
$ echo ${a['1'+\1+"1"]}
3


Regards,
Thorsten Dahlheimer



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

declare -f and for (( ... ))

[Thorsten Dahlheimer]

Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: cygwin
Compiler: gcc
Compilation
CFLAGS:  -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='cygwin' 
-DCONF_MACHTYPE='i586-pc-cygwin' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/
locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS  -I.  -I/ho
me/xxx/bash/bash-3.0 -I/home/xxx/bash/bash-3.0/include -I/home/xxx/bash/bash
-3.0/lib   -O2
uname output: CYGWIN_98-4.10 pcdahl4201 1.5.18s(0.130/4/2) 20050611 15:29:08
i586 unknown unknown Cygwin
Machine Type: i586-pc-cygwin

Bash Version: 3.0
Patch Level: 16
Release Status: release

Description:
When "declare -f" outputs a "for (( exp1; exp2; exp3 ))" command, it inserts
a space after exp1 and exp2.  When the output is re-fed into bash, these
extra
spaces become part of the new exp1 and exp2.  Repeating this process several
times leads to an accumulation of trailing spaces in exp1 and exp2.

Repeat-By:
$ f() { for (( i=0; i<$1; i++ )); do eval "$(declare -f f)"; done; }
$ declare -f f
f ()
{
for ((i=0 ; i<$1 ; i++ ))
do
eval "$(declare -f f)";
done
}
$ f 20
$ declare -f f
f ()
{
for ((i=0 ; i<$1 ; i++ ))
do
eval "$(declare -f f)";
done
}

Fix:
Either strip trailing whitespace in make_cmd.c:make_arith_for_command()
or print "; " instead of " ; " in print_cmd.c:print_arith_for_command().


Regards,
Thorsten Dahlheimer



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

(feature request) here-document, but from a file

[William Park]

Dear Chet,

It would be nice if I can read a file and process it as though it was
here-document text in the script.  Mainly, I want variable substitution,
without calling lots of 'sed'.

In Python, you would do
print "..." % ...

So, perhaps, you can use syntax like
cat <<+ file
cat  file

-- 
William Park <[EMAIL PROTECTED]>, Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
   http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
  http://freshmeat.net/projects/bashdiff/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: (feature request) here-document, but from a file

[Chris F.A. Johnson]

On Sat, 2 Jul 2005, William Park wrote:


Dear Chet,

It would be nice if I can read a file and process it as though it was
here-document text in the script.  Mainly, I want variable substitution,
without calling lots of 'sed'.

In Python, you would do
   print "..." % ...

So, perhaps, you can use syntax like
   cat <<+ file
   cat  file


Why can't you use:

cat < file

--
Chris F.A. Johnson 
==
Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: (feature request) here-document, but from a file

[Bob Proulx]

Chris F.A. Johnson wrote:
> William Park wrote:
> >It would be nice if I can read a file and process it as though it was
> >here-document text in the script.  Mainly, I want variable substitution,
> >without calling lots of 'sed'.
> >
> >In Python, you would do
> >   print "..." % ...
> >
> >So, perhaps, you can use syntax like
> >   cat <<+ file
> >   cat  file
> 
> Why can't you use:
> 
> cat < file

The original poster said that the behavior wanted was variable
substitution as in a here-document.  Using 'cat < file' would not
expand any variables.

However counter proposals are useful.  Will this work for you?

  eval echo $(http://lists.gnu.org/mailman/listinfo/bug-bash

Re: (feature request) here-document, but from a file

[Paul Jarc]

William Park <[EMAIL PROTECTED]> wrote:
> It would be nice if I can read a file and process it as though it was
> here-document text in the script.  Mainly, I want variable substitution,
> without calling lots of 'sed'.

eval "blah 

Re: (feature request) here-document, but from a file

[William Park]

On Sat, Jul 02, 2005 at 05:48:40PM -0600, Bob Proulx wrote:
> Chris F.A. Johnson wrote:
> > William Park wrote:
> > >It would be nice if I can read a file and process it as though it was
> > >here-document text in the script.  Mainly, I want variable substitution,
> > >without calling lots of 'sed'.
> > >
> > >In Python, you would do
> > >   print "..." % ...
> > >
> > >So, perhaps, you can use syntax like
> > >   cat <<+ file
> > >   cat  file
> > 
> > Why can't you use:
> > 
> > cat < file
> 
> The original poster said that the behavior wanted was variable
> substitution as in a here-document.  Using 'cat < file' would not
> expand any variables.
> 
> However counter proposals are useful.  Will this work for you?
> 
>   eval echo $( 
> That will expand variables from the file using existing standard syntax.

If the file contains '<' or '>' (like HTML), then it will do
redirection.  Probably, not good thing. :-)

-- 
William Park <[EMAIL PROTECTED]>, Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
   http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
  http://freshmeat.net/projects/bashdiff/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: (feature request) here-document, but from a file

[Chet Ramey]

Chris F.A. Johnson wrote:
> On Sat, 2 Jul 2005, William Park wrote:
> 
>> Dear Chet,
>>
>> It would be nice if I can read a file and process it as though it was
>> here-document text in the script.  Mainly, I want variable substitution,
>> without calling lots of 'sed'.
>>
>> In Python, you would do
>>print "..." % ...
>>
>> So, perhaps, you can use syntax like
>>cat <<+ file
>>cat  file
> 
> 
> Why can't you use:
> 
> cat < file

Because he wants variable substitution.  Something like

cat <<< "$(< file)"

might work.

Chet



-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live...Laugh...Love
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash