Re: Why does a Bash shell script write prompts followed by reads and do it right?

On Tue, Sep 1, 2015 at 12:34 AM, John McKown wrote: > Not a bug, so likely the wrong forum. > > Have you tried doing a fflush() after the fputs()? I.e. something to tell > the Kernel to "write this out immediately!". In the case of write(), I > think you need to use the O_SYNC flag in the open()

Inconsistent arithmetic evaluation of parameters

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin14.5.0 Compiler: clang Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='darwin14.5.0' -DCONF_MACHTYPE='x86_64-apple-darwin14.5.0' -DCONF_VENDOR='apple' -DLOCALEDIR='/usr/loca

Re: Inconsistent arithmetic evaluation of parameters

On Tue, Sep 01, 2015 at 12:50:23AM -0400, Clint Hepner wrote: > Repeat-By: > > foo=bar > bar=5 > echo $(( foo ))# produces 5 > echo $(( foo++ )) # produces 5 > echo $foo # produces 6, not bar > echo $bar # produces 5, not 6 bar was never changed from

Re: Inconsistent arithmetic evaluation of parameters

On Tue, Sep 1, 2015 at 12:50 PM, Greg Wooledge wrote: > On Tue, Sep 01, 2015 at 12:50:23AM -0400, Clint Hepner wrote: > > Repeat-By: > > > > foo=bar > > bar=5 > > echo $(( foo ))# produces 5 > > echo $(( foo++ )) # produces 5 > > echo $foo # produces 6, not bar >

Re: Inconsistent arithmetic evaluation of parameters

On Tue, Sep 01, 2015 at 03:13:57PM -0500, Dennis Williamson wrote: > The version of dash I have handy (0.5.7) has math support which IMHO is > broken: > > $ foo=bar > $ bar=5 > $ echo $foo > bar > $ echo $((foo)) > dash: 4: Illegal number: bar > $ echo $(($foo)) > 5 > $ echo $((bar)) > 5 > $ echo

Re: Why does a Bash shell script write prompts followed by reads and do it right?

Robert Parker wrote: > Yet when I attempt the same in a C program, the system always writes 2 > prompts, then waits for a read. This isn't a C list. But if you don't show us the code then no one can give good help. If you write, read, write and then it *must* try the read before the second write

Re: Why does a Bash shell script write prompts followed by reads and do it right?

John McKown wrote: > Not a bug, so likely the wrong forum. Agreed. > Have you tried doing a fflush() after the fputs()? I.e. something to tell > the Kernel to "write this out immediately!". Almost. It is the C library libc that buffers output with fputs() not the kernel. The libc normally chec

Re: Inconsistent arithmetic evaluation of parameters

On Tue, Sep 1, 2015 at 3:23 PM, Greg Wooledge wrote: > On Tue, Sep 01, 2015 at 03:13:57PM -0500, Dennis Williamson wrote: > > The version of dash I have handy (0.5.7) has math support which IMHO is > > broken: > > > > $ foo=bar > > $ bar=5 > > $ echo $foo > > bar > > $ echo $((foo)) > > dash: 4:

Re: Inconsistent arithmetic evaluation of parameters

Dennis Williamson writes: > $ echo $((foo)) # expansion succeeds, indirection fails > dash: 4: Illegal number: bar The indirection didn't fail, it just didn't produce a number, so the expression is malformed. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6

Re: \c-handling in $'-strings

Am 31.08.2015, 15:17 Uhr,SCHRIEB Chet Ramey : Conversion to a control character is effected by ANDing with 0x1f, since the valid control character range is 0-0x1f. If you have something that's not a valid control character after being ANDed with 0x1f, you get undefined results. There is a t

Re: Inconsistent arithmetic evaluation of parameters

On Tue, Sep 1, 2015 at 4:24 PM, Andreas Schwab wrote: > Dennis Williamson writes: > > > $ echo $((foo)) # expansion succeeds, indirection fails > > dash: 4: Illegal number: bar > > The indirection didn't fail, it just didn't produce a number, so the > expression is malformed. > > Andreas. > > -