Re: Problems when RANDOM without $ is used as an array index

2010-01-12 Thread Stephane CHAZELAS 
2010-01-11, 17:42(-05), Chet Ramey:
>> > Think of it as
>> >
>> > x = $(( RANDOM%6+1 + RANDOM%6+1 ))
>> > y = dice[x]
>> > dice[RANDOM%6+1 + RANDOM%6+1] = y + 1
>> > return y
>> [...]
>> 
>> I would still consider that a bug.
>
> OK.  But everyone does it the same way.

Except for pdksh, mksh, posh, perl, C.

I think by "everyone", you mean "AT&T ksh" and "zsh" or do you
know any other shell or language that behaves like that?

-- 
Stéphane

Re: [bash-4.0 executes command without newline]

2010-01-12 Thread Arindam Sarkar - Sun Microsystems 

Hi Chet,
  My apologies for the delay in replying to your email.

Chet Ramey wrote:

On 12/16/09 7:59 AM, Arindam Sarkar - Sun Microsystems wrote:
  

Configuration Information [Automatically generated, do not change]:
Machine: sparc
OS: solaris2.11
Compiler: /ws/onnv-tools/SUNWspro/SS12/bin/c99
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
-DCONF_OSTYPE='solaris2.11' -DCONF_MACHTYPE='sparc-sun-solaris2.11'
-DCONF_VENDOR='sun' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -Xc
-features=extinl,extensions -xprefetch=auto -xbuiltin=%none -xnorunpath
-xcsi -xinline=%auto -xustr=ascii_utf16_ushort -xF=%none
-xthreadvar=%all -xspace -xldscope=symbolic -KPIC -mt -D_REENTRANT
-D__EXTENSIONS__=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_XOPEN_SOURCE=600 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC
-D_STRICT_STDC__ -D_STDC_C99 -D_ISOC99_SOURCE -D__C99FEATURES__
-DSOLARIS -m32 -xvis=yes -xmemalign=8i -xregs=appl -xtarget=ultra2
-xarch=sparcvis -xchip=ultra2 -xO4 -s -DSHELL -DHAVE_CONFIG_H
-DSOLARIS   -I.  -I. -I./include -I./lib  -DTEXT_DOMAIN= 
-I/net/train/builds/arindam/6811876/sfwnv/proto/root_sparc/usr/include 
-I/net/train/builds/arindam/6811876/sfwnv/proto/root_sparc/usr/sfw/include 
-I/net/train/b!

uilds/arindam/6811876/sfwnv/proto/root_sparc/usr/include-Xc
-features=extinl,extensions -xprefetch=auto -xbuiltin=%none -xnorunpath
-xcsi -xinline=%auto -xustr=ascii_utf16_ushort -xF=%none
-xthreadvar=%all -xspace -xldscope=symbolic -KPIC -mt -D_REENTRANT
-D__EXTENSIONS__=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_XOPEN_SOURCE=600 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC
-D_STRICT_STDC__ -D_STDC_C99 -D_ISOC99_SOURCE -D__C99FEATURES__
-DSOLARIS -m32 -xvis=yes -xmemalign=8i -xregs=appl -xtarget=ultra2
-xarch=sparcvis -xchip=ultra2 -xO4 -s
uname output: SunOS train 5.11 snv_125 sun4u sparc SUNW,Sun-Fire-V890
Machine Type: sparc-sun-solaris2.11

Bash Version: 4.0
Patch Level: 28
Release Status: release

Description:
   bash executes command without newline
   This bug was assumed to be fixed with the intregation
   of bash-4.0, but it is still reproducible.



This is not a bug.  Shells dating back to v7 have interpreted EOF as a
token delimiter equivalent to newline.  Posix standardizes this behavior.
  
 I had gone through the standard and found this: 


There is one place in the "Token Recognition" section in the "Shell
Command Language" says:

-
If the end of input is recognized, the current token shall be delimited. 
If there is no current token, the end-of-input indicator shall be 
returned as the token.

-

So, the EOF is a delimitor and the token probably can be processed.
However, we are being hung up. There is another section in the
General Terminal interface says:

-
Modem Disconnect

If a modem disconnect is detected by the terminal interface for a 
controlling terminal, and if CLOCAL is not set in the c_cflag field for 
the terminal (see Control Modes ), the SIGHUP signal shall be sent to 
the controlling process for which the terminal is the controlling 
terminal. Unless other arrangements have been made, this shall cause the 
controlling process to terminate (see exit()). Any subsequent read from 
the terminal device shall return the value of zero, indicating 
end-of-file; see read(). Thus, processes that read a terminal file and 
test for end-of-file can terminate appropriately after a disconnect. If 
the EIO condition as specified in read() also exists, it is unspecified 
whether on EOF condition or [EIO] is returned. Any subsequent write() to 
the terminal device shall return -1, with errno set to [EIO], until the 
device is closed.

--

So the controlling process would be able to be terminated by SIGHUP.
Since EOF would be the consequence of a disconnect, I'd rather feel
that it would be okay to discard the pending characters. In fact,
if shell is reading terminal in ICANON mode, the pending characters
are discarded in the terminal driver when disconnected (ie read(2)
wouldn't read the pending characters but read(2) returns 0).

Could you  let me know the rationale on the 'standardized' behavior that
you pointed and which exist in Posix ?


thanks
-Arindam

Chet

Brokenness in bash-3.2 Makefile

2010-01-12 Thread Philip A. Prindeville 
I'm trying to cross-build bash-3.2 with certain cross-compilation flags (like 
LDFLAGS="--sysroot=$(STAGING_DIR)/usr") but since LDFLAGS_FOR_BUILD is set to 
$(LDFLAGS), this isn't working.

It would be nice to be able to set the two orthogonally.

Anyone have a patch I could test?

Thanks,

-Philip

Re: Brokenness in bash-3.2 Makefile

2010-01-12 Thread Chet Ramey 
> I'm trying to cross-build bash-3.2 with certain cross-compilation flags (like 
> LDFLAGS="--sysroot=$(STAGING_DIR)/usr") but since LDFLAGS_FOR_BUILD is set to 
> $(LDFLAGS), this isn't working.
> 
> It would be nice to be able to set the two orthogonally.

Why not just specify the appropriate value for LDFLAGS_FOR_BUILD on the
command line?

-- 
``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: Brokenness in bash-3.2 Makefile

2010-01-12 Thread Mike Frysinger 
On Monday 11 January 2010 22:31:15 Philip A. Prindeville wrote:
> I'm trying to cross-build bash-3.2 with certain cross-compilation flags
>  (like LDFLAGS="--sysroot=$(STAGING_DIR)/usr") but since LDFLAGS_FOR_BUILD
>  is set to $(LDFLAGS), this isn't working.
> 
> It would be nice to be able to set the two orthogonally.
> 
> Anyone have a patch I could test?

bash-4.1 is already fixed
-mike


signature.asc
Description: This is a digitally signed message part.

Re: Problems when RANDOM without $ is used as an array index

2010-01-12 Thread Chet Ramey 
On 1/12/10 5:16 AM, Stephane CHAZELAS wrote:
> 2010-01-11, 17:42(-05), Chet Ramey:
 Think of it as

 x = $(( RANDOM%6+1 + RANDOM%6+1 ))
 y = dice[x]
 dice[RANDOM%6+1 + RANDOM%6+1] = y + 1
 return y
>>> [...]
>>>
>>> I would still consider that a bug.
>>
>> OK.  But everyone does it the same way.
> 
> Except for pdksh, mksh, posh, perl, C.

The three shells in your list are all variants of the same base.  It's
like using three different releases of bash.  The other two aren't
shells.  C is a reasonable comparison, but there are other differences
in how the languages are parsed and executed.

> I think by "everyone", you mean "AT&T ksh" and "zsh" or do you
> know any other shell or language that behaves like that?

I haven't done an extensive investigation.  It's not really a significant
issue.  It's important enough that bash, ksh, and zsh agree.  We don't
need more incompatibilities between the major shells.

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/