fc edit gets last command count wrong

[john . haxby]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE  -O2 -g -pipe 
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic
uname output: Linux sheep.uk.oracle.com 2.6.24.3-12.fc8 #1 SMP Tue Feb 26 
14:21:30 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 3.2
Patch Level: 33
Release Status: release

Description:
"fc -e echo" and "fc -e echo -1" should simply run the last command,
but the latter runs the last-but-one command.  Even worse,
"fc -e echo xxx" reports "bash: fc: history specification out of range"
when "xxx" is the last command run (provided that there is no other
"xxx" in the history.
[Detailed description of the problem, suggestion, or complaint.]

Repeat-By:
Run three commands to get them in the history, say, "aaa, "bbb" and
"ccc" (it doesn't matter that they aren't found).  Now "fc -e echo -1"
will run "bbb" instead of "ccc".   Similar, "fc -e echo ccc" will
report the history specification out of range error.

I have a small shell function that uses fc in this way:

please () {
fc -e 'sed -i "s/^/sudo /"' -1
}

It works fine without the "-1" but that argument was needed for
compatability with some other shell (which one is lost in the mists
of time) and the bug has been annoying me for some little while so
I decided to track it down

Fix:
The fix is simply to move the delete_last_history() call _after_ the
block that calculates histbeg and histend.  Patch follows:


diff -up bash-3.2/builtins/fc.def.fc bash-3.2/builtins/fc.def
--- bash-3.2/builtins/fc.def.fc 2006-07-28 02:44:09.0 +0100
+++ bash-3.2/builtins/fc.def2008-03-13 17:21:15.0 +
@@ -290,11 +290,6 @@ fc_builtin (list)
  line was actually added (HISTIGNORE may have caused it to not be),
  so we check hist_last_line_added. */
 
-  /* "When not  listing, he fc command that caused the editing shall not be
- entered into the history list." */
-  if (listing == 0 && hist_last_line_added)
-delete_last_history ();
-
   last_hist = i - 1 - hist_last_line_added;
 
   if (list)
@@ -322,6 +317,11 @@ fc_builtin (list)
histbeg = histend = last_hist;
 }
 
+  /* "When not  listing, he fc command that caused the editing shall not be
+ entered into the history list." */
+  if (listing == 0 && hist_last_line_added)
+delete_last_history ();
+
   /* We print error messages for line specifications out of range. */
   if ((histbeg < 0) || (histend < 0))
 {

Re: Fwd: Problem with bash completion

[Chris F.A. Johnson]

On 2008-03-13, Eric Blake wrote:
>
> This was originally reported on the cygwin lists; it is still present in
> stock bash 3.2.33.
>
> - -
>
> From: David Rothenberger
> Subject: Problem with bash completion
>
> Sometimes bash gets confused and starts adding a slash at the end of
> files when I do tab-completion. Here's a simple reproduction script:
>
> ~ > bash --noprofile --norc -i
> bash-3.2$ mkdir /tmp/bash-problem
> bash-3.2$ cd /tmp/bash-problem
> bash-3.2$ mkdir d
> bash-3.2$ touch x
> bash-3.2$ chmod 755 x
> bash-3.2$ ./x< tab after x completes correctly
> bash-3.2$ ./d/   < ditto with d
> bash: ./d/: is a directory
> bash-3.2$ "$(ls ./d/)"   < pressed tab after d
> bash: : command not found
> bash-3.2$ ./x/   < tab after x now adds slash
>
> Once the shell starts doing this, it keeps doing it. Restarting bash
> solves the problem.

   I don't see that problem, and I'm using the same version of
   bash.

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

problems with 'read'ing from a pipe

[John Smith]

Hi,


I was running into some unexpected behavior with bash and reading from
a pipeline, and am starting to wonder if im running into a bug or
whether im just doing something wrong.

For example, if I type the following :

echo foo | read VAR
echo $VAR

I would expect the the variable named VAR to contain the value foo.
Instead, the variable foo remains empty. Is this a bug or am I doing
something wrong ?




Sincerely,


John Smith

complete-into-braces incorrect when using localized sorting

[Torsten Nahm]

Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-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 -Wall
uname output: Linux stream 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 
UTC 2008 i686 GNU/Linux

Machine Type: i486-pc-linux-gnu

Bash Version: 3.2
Patch Level: 25
Release Status: release

Description:
Completion into braces does not work correctly in some instances 
where filenames start with the same string but with different 
capitalizations thereof and localized sorting is enabled


Repeat-By:
Use a localized bash and go into an empty directory.
create the files "ya, xYb and xyc
Type M-{
This expands to xy{a,b,c}, with the y incorrectly lowercase for xYb
Set LC_ALL=C
Type M-{
The expansion is now correct: x{Yb,y{a,c}}

Fix:
A quick look at the code suggests that gcd determination in 
really_munge_braces depends on the array being sorted in ascending 
(byte) order, as supplied if the locale is set to C. If the sorting is 
localized, lowercase and uppercase are usually treated equally, and the 
gcd determination gets confused. A fix would be to use byte value 
sorting for complete-into-braces

Re: problems with 'read'ing from a pipe

[Paul Jarc]

"John Smith" <[EMAIL PROTECTED]> wrote:
> echo foo | read VAR
> echo $VAR

See entry E4 in the bash FAQ:
http://tiswww.case.edu/php/chet/bash/FAQ


paul