Re: [patch #7637] bash 4.1 return builtin violates posix in checking for options

2011-10-22 Thread Chet Ramey 
On 10/21/11 3:50 PM, Linda A. Walsh wrote:
> URL:
>   
> 
>  Summary: bash 4.1 return builtin violates posix in checking
> for options
>  Project: The GNU Bourne-Again SHell
> Submitted by: law
> Submitted on: Fri 21 Oct 2011 12:50:32 PM PDT
> Category: None
> Priority: 6
>   Status: None
>  Privacy: Public
>  Assigned to: None
> Originator Email: 
>  Open/Closed: Open
>  Discussion Lock: Any
> 
> ___
> 
> Details:
> 
> in bash 4.1, the return cmd now checks to see if it has
> options and parses them as 'illegal' (not very helpful and 
> certainly not a usability feature).  Posix says the return command takes no
> options.

This changed between bash-4.0-alpha and bash-4.0-beta.  You missed the
ensuing discussion by around three years.

The rationale at the time was that Posix specifies the argument to return
to be an `unsigned decimal integer', so negative numbers should not be
allowed.  The Bourne shell has never accepted them, for instance, and
other shells claiming Posix conformance (e.g., dash, mksh, FreeBSD 8 sh)
don't either.

The issue came up again recently, and the resultant discussion convinced
me that it would be a reasonable, if non-portable, extension to Posix.
No application should be passing anything but {0..255} in any case.
Accepting it as an argument doesn't mean the value isn't going to be
masked with 0xff, though.

The next version of bash will allow negative numbers as arguments to
return, which has the added benefit of rationalizing the values passed
to `return' and `exit'.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: [patch #7638] exit-code triggered error behavior changed in 4.1: incompat w/earlier versions of POSIX

2011-10-22 Thread Chet Ramey 
On 10/21/11 4:41 PM, Linda A. Walsh wrote:
> URL:
>   
> 
>  Summary: exit-code triggered error behavior changed in 4.1:
> incompat w/earlier versions of POSIX
>  Project: The GNU Bourne-Again SHell
> Submitted by: law
> Submitted on: Fri 21 Oct 2011 01:41:05 PM PDT
> Category: None
> Priority: 5 - Normal
>   Status: None
>  Privacy: Public
>  Assigned to: None
> Originator Email: 
>  Open/Closed: Open
>  Discussion Lock: Any
> 
> ___
> 
> Details:
> 
> The new version of bash in non-posix mode (this is likely changed in POSIX
> mode as well, but in non-posix mode it didn't need to be, pointlessly, made
> incompatible) has broken compatibility with the early POSIX specs in following
> the newer 'portable OS **[non]** interoperability Xchange' specification'. 

Really?


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: "history -s" within PROMPT_COMMAND deletes last history item.

2011-10-22 Thread Chet Ramey 
On 10/20/11 12:02 PM, les...@vmw-les.eng.vmware.com wrote:
> 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-unknown-linux-gnu' 
> -DCONF_VENDOR='unknown' -DLOCALEDIR='/home/lester/base/share/locale' 
> -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g 
> -O2
> uname output: Linux vmw-les.eng.vmware.com 2.6.40.6-0.fc15.x86_64 #1 SMP Tue 
> Oct 4 00:39:50 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-unknown-linux-gnu
> 
> Bash Version: 4.2
> Patch Level: 10
> Release Status: release
> 
> Description:
>   The "history -s" usually removes the last history item which
>   is usually the "history -s" command itself, but PROMPT_COMMAND
>   disables history and causes an unrelated command to be deleted.
> 
> Repeat-By:
>   $ history -s '# line 1' ; history -s '# line 2' ; history 2
>   X1 # line 1
>   X2 # line 2
>   $ PROMPT_COMMAND="history -s '# line 3' ; history -s '# line 4'"
>   $ history 5
>   X1 # old command
>   X2 # line 1
>   X3 # line 2
>   X4 # line 3
>   X5 # line 4
>   
>   Expect:
>   X1 # line 1
>   X2 # line 2
>   X3 PROMPT_COMMAND="history -s '# line 3' ; history -s '# line 4'"
>   X4 # line 3
>   X5 # line 4
>   
>   No new commands will enter history as they are replaced with $'# line 
> 3\n# line 4'

Thanks for the report.  This will be fixed in the next release of bash.
Here's a patch you can test for proper behavior.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.2-patched/builtins/history.def	2009-01-04 14:32:22.0 -0500
--- builtins/history.def	2011-10-22 22:43:11.0 -0400
***
*** 325,331 
   history, change #if 0 to #if 1 below. */
  #if 0
!   if (hist_last_line_pushed == 0 && hist_last_line_added && bash_delete_last_history () == 0)
  #else
!   if (hist_last_line_pushed == 0 &&
  	(hist_last_line_added ||
  	  (current_command_line_count > 0 && current_command_first_line_saved && command_oriented_history))
--- 325,332 
   history, change #if 0 to #if 1 below. */
  #if 0
!   if (remember_on_history && hist_last_line_pushed == 0 &&
! 	hist_last_line_added && bash_delete_last_history () == 0)
  #else
!   if (remember_on_history && hist_last_line_pushed == 0 &&
  	(hist_last_line_added ||
  	  (current_command_line_count > 0 && current_command_first_line_saved && command_oriented_history))