nullglob option breaks complex parameter expansion/deletion
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2
uname output: Linux eagle.endbracket.net 2.6.7eagle-20040916 #1 Thu Sep 16
23:36:29 EST 2004 i686 GNU/Linux
Machine Type: i386-pc-linux-gnu
Bash Version: 3.0
Patch Level: 16
Release Status: release
Description:
I had been using ${HOSTNAME%%.*} in my prompt to show the local
host name portion of my full host name (e.g. localhost instead
of localhost.localdomain). After enabling the nullglob shell
option, this pattern is being replaced by a null string. I
don't think this behavior is desireable.
I don't fully understand the wording of the relevant portion of
the POSIX standard on this topic, but I would expect this
pattern to always function as it does without nullglob set:
- the /word/ to delete is a shell glob pattern to apply to the
result of expanding the /parameter/, regardless of whether the
word matches any file names in the current directory
- the deletion occurs regardless of whether the expansion of
/parameter/ is a file name
- the expansion of /parameter/ remains intact if the /word/ does
not match any portion of /parameter/
The standard also suggests that quoting /word/ shall cause it to
be regarded as literal rather than a pattern, but quoting /word/
exhibits the same problem.
Repeat-By:
$ shopt -u nullglob
$ connectioninfo='${HOST%%.*} ${USER}'
$ echo $connectioninfo
${HOST%%.*} ${USER}
$ shopt -s nullglob
$ echo $connectioninfo
${USER}
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: LF becomes BACKSLASH LF in 'declare -p'
William Park wrote: > > Description: > 'declare -p' adds backslash (\) in front of newline. When this > is fed back, the newline disappears. Should this happen? > > Repeat-By: > 0 node1:~$ a='11 > > 22' > 0 node1:~$ declare -p a > declare -- a="11\ > 22" > > 'declare -p' supposed to print stuffs that can be fed back. So, > when it is fed back, the newline disappears. > > 0 node1:~$ declare b="11\ > > 22" > 0 node1:~$ declare -p b > declare -- b="1122" That behavior is correct -- backslash-newline disappears unless it appears within single quotes. The problem is that the newline is being quoted in the declare output. I will take a look. 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
[EMAIL PROTECTED] wrote:
> Bash Version: 3.0
> Patch Level: 16
> Release Status: release
>
> Description:
> I had been using ${HOSTNAME%%.*} in my prompt to show the local
> host name portion of my full host name (e.g. localhost instead
> of localhost.localdomain). After enabling the nullglob shell
> option, this pattern is being replaced by a null string. I
> don't think this behavior is desireable.
Perhaps not desirable, but, in the example you supplied, functioning as
designed.
>
> I don't fully understand the wording of the relevant portion of
> the POSIX standard on this topic, but I would expect this
> pattern to always function as it does without nullglob set:
That part of the POSIX standard isn't relevant for two reasons. First,
POSIX doesn't standardize `nullglob'. Second, the expansion described
is not happening.
What happens in the example you show is that a word that looks like a
parameter expansion is part of the expanded value of $connectioninfo,
but that word is not being expanded as a parameter. It's subject to
the normal glob expansion that the unquoted results of any parameter
expansion would be, and, since it doesn't match any filenames, is
removed when `nullglob' is enabled.
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: Controlling terminal race condition
Jeff Miller wrote: > Configuration Information [Automatically generated, do not change]: > Machine: sparc > OS: solaris2.8 > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc' > -DCONF_OSTYPE='sol > aris2.8' -DCONF_MACHTYPE='sparc-sun-solaris2.8' -DCONF_VENDOR='sun' > -DLOCALEDIR= > '/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. > -I. -I. > /include -I./lib -I./lib/intl -I/big/homea/test/bash-3.0/lib/intl -g -O2 > uname output: SunOS test 5.8 Generic_108528-13 sun4u spar > c SUNW,Ultra-250 > Machine Type: sparc-sun-solaris2.8 > > Bash Version: 3.0 > Patch Level: 0 > Release Status: release > > Description: >After forking and running the executed command bash sets the terminal > controlling process id to the id of the process of the fork. In the > following case the process created does another fork and execs off > another bash shell for the new process. This new shell sets the process > for the controlling terminal to itself and does a write and a read. 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. My opinion is that bash is doing the right thing to ensure that the terminal always belongs to the correct foreground process group, but that it's always possible to fool the shell by changing the terminal's process group behind its back. 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
Matthias Schniedermeyer wrote: > Hi > > > Version: > From Debian SID > >> bash --version > GNU bash, version 3.00.16(1)-release (i386-pc-linux-gnu) > > > As it seems it is not possible to append multiple command to the > "history", only replace the last command. I'd classify this as a bug rather than a feature request, and it will be fixed for the next version. 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: Controlling terminal race condition
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. paul ___ 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 wrote: Matthias Schniedermeyer wrote: Hi Version: From Debian SID bash --version GNU bash, version 3.00.16(1)-release (i386-pc-linux-gnu) As it seems it is not possible to append multiple command to the "history", only replace the last command. I'd classify this as a bug rather than a feature request, and it will be fixed for the next version. Thank you for this great news. :-) How do you plan to "fix" that bug? - Only replace last command if called from commandline(iow: replace history command with data from the history command) and appending when called from non commandline? - New Parameter for "append to history"? - Something else? Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
