new redirection operator seems broken
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' -DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=pentium4 -O2 -pipe uname output: Linux ice.filescope.com 2.6.25.10 #5 PREEMPT Thu Nov 27 16:10:07 EST 2008 i686 Intel(R) Pentium(R) 4 CPU 1400MHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 10 Release Status: release Description: My understanding is that the following two commands should behave the same: rm 2>&1 | grep --color op rm |& grep --color op Notice that they are behaving differently. Repeat-By: Watch the error stream not get passed through the pipe in the second command sequence.
backward-kill-word is not refreshing correctly
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' -DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=pentium4 -O2 -pipe uname output: Linux ice.filescope.com 2.6.25.10 #5 PREEMPT Thu Nov 27 16:10:07 EST 2008 i686 Intel(R) Pentium(R) 4 CPU 1400MHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 10 Release Status: release Description: When I type a long string of text and start pressing ctrl-W to backwards-kill words, bash deletes the words but doesn't visually refresh (the words still appear on the command line). This was not occurring for me in the 3.x series of Bash. Repeat-By: Write this text on the command line: "sample text sample text sample text sample text sample text". Start pressing ctrl-W and notice it takes a few kill-words before the words start disappearing. --Matt Zyzik
cat.sh issue
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' -DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=pentium4 -O2 -pipe uname output: Linux ice.filescope.com 2.6.25.10 #5 PREEMPT Thu Nov 27 16:10:07 EST 2008 i686 Intel(R) Pentium(R) 4 CPU 1400MHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 10 Release Status: release Description: This is a combination bug report and a question. The bug is in the examples/scripts/cat.sh demo script. There are cases where the script will break. The culprit line is: echo "$REPLY" It should instead be: printf %s\\n "$REPLY" In the current state of the script, lines like "-n" or "-e" won't get printed. The question I have is why couldn't echo have a -- flag? Is it for POSIX or some other kind of compatibility reasons? Is there any easier way to accomplish what I want other than printf %s\\n "$var"? --Matt
dir*/** behavior
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' -DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=pentium4 -O2 -pipe uname output: Linux ice.filescope.com 2.6.25.10 #5 PREEMPT Thu Nov 27 16:10:07 EST 2008 i686 Intel(R) Pentium(R) 4 CPU 1400MHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 10 Release Status: release Description: (Note: I am in the root directory of the bash source code) [~/desktop/bash-4.0]$ ls -adl exampl*/** ls: cannot access examples/examples: No such file or directory ls: cannot access examples/examples/complete: No such file or directory ls: cannot access examples/examples/complete/bashcc-1.0.1.tar.gz: No such file or directory ls: cannot access examples/examples/complete/bash_completion: No such file or directory [...] The above-mentioned "ls -adl exampl*/**" command should work the same as "ls -adl examples/**"; however, as shown above, the behavior of the former command is wrong. The commands work properly in both KornShell and Z shell. --Matt Zyzik
quote nesting bug
bug-bash,
I am noticing a behavior that appears to be a bug. Additionally, what I
am expecting to happen is the actual behavior in both Zsh and Ksh.
This is the command (ignore leading whitespace):
echo "${fpbnoinervzkjeh:-'good morning}"
This is the output in both Zsh and Ksh (ignore leading whitespace):
'good morning
In Bash, there is no output, only a prompt that appears. However, the
following command (ignore leading whitespace):
echo "${fpbnoinervzkjeh:-''good morning}"
produces the following output in all 3 shells (ignore leading whitespace):
''good morning
Can I request comment? Thank you.
--Matt Zyzik
Misspelling of "sequence" in reference manual
Hi,
In section 3.5.1 Brace Expansion of the Bash Reference Manual,
"sequence" is misspelled "seqeunce".
--
Matt Kraai
https://ftbfs.org/kraai
diff -C2 -r bash-4.2~/doc/bashref.texi bash-4.2/doc/bashref.texi
*** bash-4.2~/doc/bashref.texi 2011-04-04 20:30:51.0 -0700
--- bash-4.2/doc/bashref.texi 2011-04-04 20:31:36.0 -0700
***
*** 1555,1559
but the file names generated need not exist.
Patterns to be brace expanded take the form of an optional @var{preamble},
! followed by either a series of comma-separated strings or a seqeunce expression
between a pair of braces,
followed by an optional @var{postscript}.
--- 1555,1559
but the file names generated need not exist.
Patterns to be brace expanded take the form of an optional @var{preamble},
! followed by either a series of comma-separated strings or a sequence expression
between a pair of braces,
followed by an optional @var{postscript}.
Two problems: one in documentation, one philosophical
The first bug is in the bash(1) man page. In the SHELL GRAMMAR ->
Compound Commands -> [[ expression ]] section: "The return value is
0 if the string matches or does not match the pattern, respectively,
and 1 otherwise." This sentence is unclear. It is likely that
"respectively" maps "matches" and "does not match" to the operators ==
and !=, repectively. This should be better expressed in the man page.
The second bug is that {x..y} only makes sense if both x and y are
{numbers,lower-case letters,upper-case letters}. {a..A} should be
invalid and resolve to {a..A}, but instead it sequences backwards: "a
_ ^ ] [ Z Y ... A". This is allowed, I am supposing, by a
simplistic typing mechanism, in which there are just two types:
numbers and letters. However this is too simplistic and should be
changed.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
getcwd cannot determine the path of the current working directory
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: nto-qnx6.3.2 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='nto-qnx6.3.2' -DCONF_MACHTYPE='i386-pc-nto-qnx6.3.2' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -Dqnx -Dqnx6 -I. -I. -I./include -I./lib -I/usr/local/include -g -O2 uname output: QNX qnx18 6.3.2 2006/02/02-01:02:33EST x86pc x86 Machine Type: i386-pc-nto-qnx6.3.2 Bash Version: 3.2 Patch Level: 0 Release Status: release Description: getcwd cannot determine the path of the current working directory, which is /home/m_kraai. /home is a symbolic link to fs/hd0-qnx4-2, which is where the second partition is mounted. The problem is that ../.. from /home/m_kraai refers to the root directory, but there's no entry in the root directory (using lstat) whose device and inode are the same as /fs/hd0-qnx-2 (which is what .. refers to). Repeat-By: Logging in with bash as my shell generates warnings because getcwd fails. -- Matt http://ftbfs.org/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Quotes inserted into command
Hello, I've got a script that does the following: JAVA=/usr/bin/java JAVA_W_CLASSPATH="$JAVA -cp \"$classpath\" " $JAVA_W_CLASSPATH com.choicestream.foo echo $JAVA_W_CLASSPATH I've noticed that on different versions of bash, it behaves differently. Bash 3.0 will execute: /usr/bin/java -cp "/path/to/classes" com.choicestream.foo And display the same. But Bash 3.1 and 3.2 put single quotes around the double quotes when executing. /usr/bin/java -cp '"/path/to/classes"' com.choicestream.foo But it will display: /usr/bin/java -cp "/path/to/classes" com.choicestream.foo I don't understand the reason for the discrepancy, and searching for "bash quotes" gives me a lot of bash.org nonsense. Thanks! -- Matt Kane : [EMAIL PROTECTED] AIM: mkbatwerk ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
some variable level issues
bug-bash, I have a few issues to address, that I arrived at recently. None of them are necessarily bugs. 1. I noticed bash variables don't support null characters (0x00). This is unlike perl and other languages. Will this ever change? Have people requested or wanted this feature? 2. $(
Re: backward-kill-word is not refreshing correctly
> If, as seems likely, this is a problem with the calculation of the physical > cursor position, a good place to start would be your PS1 and PROMPT_COMMAND > (if any). The locale you're using would be good, too. > > Chet My PS1, which causes the issue, is: PS1='[\[\033[01;32m\]\u \[\033[01;31m\]- \[\033[01;34m\]\w\[\033[00m\]]$ ' --Matt
Re: backward-kill-word is not refreshing correctly
On Mon, Apr 13, 2009 at 05:50:52PM -0400, Chet Ramey wrote: > > > > My PS1, which causes the issue, is: > > > > PS1='[\[\033[01;32m\]\u \[\033[01;31m\]- \[\033[01;34m\]\w\[\033[00m\]]$ ' > > Sorry, I still can't reproduce it. Can you send a series of steps that > you use to reproduce the problem? A terminal session log (e.g., that > produced by `script') might also help. > > Chet Try to follow these exact instructions. First, set your PS1 to the above. It should result in a colored prompt. Second, type "asdf" so many times that it goes passed the width of the terminal and the words begin to appear on the next line. (Open xterm at its default width to do this.) At that point, keep hitting either Alt-Bksp or Ctrl-W until you see bash not refreshing properly. --Matt
Re: backward-kill-word is not refreshing correctly
On Tue, Apr 14, 2009 at 02:07:32PM -0400, Chet Ramey wrote: > Chet Ramey wrote: > > > OK, I figured out why I couldn't reproduce it. My locale is always set > > to en_US.UTF-8 (multibyte), and the problem only manifests itself when > > in non-multibyte mode. This is why I originally asked for your locale -- > > that was the missing piece. It should be pretty easy to fix. > > And it was easy to fix. Jay Freeman did a great job of identifying the > problem spot. Please try the attached patch; it works for me. > > I also need to add locale information to `bashbug'; I can tackle the > problem of making sure people actually use it to report bugs later. The patch fixed the issue for me. And yes, I wasn't using a multibyte locale. --Matt
Fails to build on HP-UX 10.20
Howdy, When I try to build bash 4.0 on HP-UX 10.20, it fails with the following error: cc -Ae -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/malloc -L./lib/sh-g -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o bashhist.o bashline.o siglist.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lsh -lreadline -lhistory -ltermcap -lglob -ltilde -lmalloc lib/intl/libintl.a /usr/ccs/bin/ld: Unsatisfied symbols: _ (code) *** Error exit code 1 Using nm, I found that _ was undefined in siglist.o. If I include bashintl.h in siglist.c, the problem is fixed. -- Matt http://ftbfs.org/
Re: Fails to build on HP-UX 10.20
On Tue, Apr 21, 2009 at 08:02:00AM -0400, Greg Wooledge wrote: > On Fri, Apr 17, 2009 at 08:52:16AM -0700, Matt Kraai wrote: > > Using nm, I found that _ was undefined in siglist.o. If I include > > bashintl.h in siglist.c, the problem is fixed. > > Yeah, I reported this exact problem a couple months ago, with the exact > same fix. Good luck getting it incorporated into an official patch. > > http://lists.gnu.org/archive/html/bug-bash/2009-02/msg00201.html Thanks for the pointer. I should have checked the mailing list archives before rereporting the problem. I'll do so next time. -- Matt http://ftbfs.org/
Re: dir*/** behavior
>> Description: >> (Note: I am in the root directory of the bash source code) >> >> [~/desktop/bash-4.0]$ ls -adl exampl*/** >> ls: cannot access examples/examples: No such file or directory >> ls: cannot access examples/examples/complete: No such file or directory >> ls: cannot access examples/examples/complete/bashcc-1.0.1.tar.gz: No such >> file >> or directory >> ls: cannot access examples/examples/complete/bash_completion: No such file >> or >> directory >> [...] >> >> The above-mentioned "ls -adl exampl*/**" command should work the >> same as "ls >> -adl examples/**"; however, as shown above, the behavior of the former >> command is wrong. The >> commands work properly in both KornShell and Z shell. >> >> --Matt Zyzik > > I get the same thing. Looks like a bug to me. > > - Ian Kelling I tried to fix this bug myself. I think the below patch is sufficient in fixing this issue: --- ../bash-4.0_orig/lib/glob/glob.c2009-01-04 14:32:30.0 -0500 +++ lib/glob/glob.c 2009-04-26 17:22:56.0 -0400 @@ -942,7 +942,7 @@ char **array; register unsigned int l; - array = glob_dir_to_array (directories[i], temp_results, flags); + array = glob_dir_to_array ((dflags & GX_ALLDIRS) ? "" : directories[i], temp_results, flags); l = 0; while (array[l] != NULL) ++l; That solves the problem and doesn't appear to introduce any other issues. Please accept this patch, or look at it. While we're on the globstar topic, I want to mention what looks to be another bug: $ ls -adl ** ls: cannot access : No such file or directory In the above expansion, it appears that an empty string is one of the expanded elements and gets passed as a parameter to 'ls'. --Matt Zyzik --- ../bash-4.0_orig/lib/glob/glob.c2009-01-04 14:32:30.0 -0500 +++ lib/glob/glob.c 2009-04-26 17:22:56.0 -0400 @@ -942,7 +942,7 @@ char **array; register unsigned int l; - array = glob_dir_to_array (directories[i], temp_results, flags); + array = glob_dir_to_array ((dflags & GX_ALLDIRS) ? "" : directories[i], temp_results, flags); l = 0; while (array[l] != NULL) ++l;
globstar broken again
All, Previously, the behavior of globstar mimicked that of ksh/zsh for such a command: "ls -adl **/*.cs". Now I've upgraded to Bash 4.0.24 from Bash 4.0.17 and the behavior is different (seemingly incorrect). Previously, the above-mentioned command would list all *.cs files in the current directory and all subdirectories. With the latest Bash, it only lists *.cs files in subdirectories. The *.cs files in the current working directory are ignored. I think this is a bug. Again, "ls -adl **/*.cs" is now _not_ picking up *.cs files in the current working directory. --Matt
Re: globstar broken again
On Mon, May 18, 2009 at 10:04:06PM -0400, Mike Frysinger wrote: > On Monday 18 May 2009 21:14:18 Matt Zyzik wrote: > > Previously, the behavior of globstar mimicked that of ksh/zsh for such a > > command: "ls -adl **/*.cs". > > > > Now I've upgraded to Bash 4.0.24 from Bash 4.0.17 and the behavior is > > different (seemingly incorrect). Previously, the above-mentioned command > > would list all *.cs files in the current directory and all > > subdirectories. With the latest Bash, it only lists *.cs files in > > subdirectories. The *.cs files in the current working directory are > > ignored. > > > > I think this is a bug. Again, "ls -adl **/*.cs" is now _not_ picking up > > *.cs files in the current working directory. > > going by the documentation, this sounds correct to me: > If set, the pattern ** used in a filename expansion context will match a > files > and zero or more directories and subdirectories. If the pattern is followed > by a /, only directories and subdirectories match. > > what's wrong with using `ls **.cs` ? It doesn't work. --Matt
Re: globstar broken again
On Fri, May 22, 2009 at 04:10:21PM -0400, Chet Ramey wrote: > OK. I finally had some time to look at this. > > The issue is that you can't always add a null placeholder for the current > directory (the original bash-4.0 code) or never add one (patch 24). You > have to add one in certain circumstances, when it gets handled later in > the process. > > Try the attached patch. It undoes portions of patch 24 and uses a > different scheme to figure out when to add the null placeholder. It > seems to work for all cases without any regressions. The patch solves the issue, and I couldn't find any regressions. --Matt
Re: Bash patches format
On 5/30/2018 02:04, Marty E. Plummer wrote:
> On Wed, May 30, 2018 at 10:42:27AM +0800, Clark Wang wrote:
>> On Wed, May 30, 2018 at 8:25 AM, Marty E. Plummer
>> wrote:
>>
>>>> If people are willing to do the conversion between patch formats for
>>> their
>>>> own purposes, more power to them. I don't see any compelling reason to
>>>> change the format I use.
>>>>
>>> Could I at least convince you to start doing -p1, if not unified?
>>>
>>
>> I think the cost is too high. All bash package maintainers on different
>> *nix systems will have to change accordingly.
>>
>> -clark
> Well how about this; we ask the downstreams. List taken from repology,
> hopefully these are still all active and accurate. So, to reiterate the
> original premise of this thread for the newly added, I suggest the
> following:
>
> 1. Change the official upstream bash patch format to be -p1 applicable,
> as a number of major linux distros either convert the patches in their
> own source repo to -p1 (debian and its children, fedora and its children),
> or have to take an explicit deviation from their default patch
> application method (gentoo) in order to apply -p0 patches.
>
> Optional:
> 2. Change the format of the patch from a context diff to a unified diff,
> for the following reasons:
> a. unified diffs are generally smaller than an equivalent context
> diff, while encoding the same information.
> *** a/lib/readline/history.c2015-12-28 13:50:31.0 -0500
> --- b/lib/readline/history.c2016-09-30 14:28:40.0 -0400
> ***
> *** 308,312
> {
> if (history_stifled && history_max_entries > 0)
> ! history_size = history_max_entries + 2;
> else
> history_size = DEFAULT_HISTORY_INITIAL_SIZE;
> --- 310,316
> {
> if (history_stifled && history_max_entries > 0)
> ! history_size = (history_max_entries >
> MAX_HISTORY_INITIAL_SIZE)
> ! ? MAX_HISTORY_INITIAL_SIZE
> ! : history_max_entries + 2;
> else
> history_size = DEFAULT_HISTORY_INITIAL_SIZE;
>
> --- a/lib/readline/history.c2015-12-28 13:50:31.0 -0500
> +++ b/lib/readline/history.c2016-09-30 14:28:40.0 -0400
> @@ -308,5 +310,7 @@
> {
> if (history_stifled && history_max_entries > 0)
> - history_size = history_max_entries + 2;
> + history_size = (history_max_entries >
> MAX_HISTORY_INITIAL_SIZE)
> + ? MAX_HISTORY_INITIAL_SIZE
> + : history_max_entries + 2;
> else
> history_size = DEFAULT_HISTORY_INITIAL_SIZE;
>
> b. unified diffs are easier to size up at a glance than
> context diffs.
>
> c. unified diffs are the
> standard for a host of foss projects, especially those using git as a
> vcs solution as it produces context diffs by default and you have to
> purposely change it to do otherwise.
>
> Maintainers, I'd really like to hear your thoughts on this matter. If
> the diffs are produced as -p1 unified diffs, then downstreams who do
> convert from -p0 context won't have to, and distros who work around it
> won't either.
>
> Regards,
>
> Marty
>
Greetings,
Speaking for the CRUX maintainers, we don't have a preference. Whatever
works best for upstream.
Regards,
Matt
pEpkey.asc
Description: application/pgp-keys
