*meOW*talk about catty
Chet Ramey wrote:
On 7/22/13 9:07 AM, Chet Ramey wrote:
The issue is whether or not attributes that determine how the assignment
should be treated (-a/-A) or how the variable should be created (-g) are
handled specially and affect how the value is expanded. The que
Testing on amd64/Gentoo:
On Thursday, June 13, 2013 01:14:09 AM you wrote:
> Hello,
>
> Clearing out the remainder of my "maybe bugs" file, in no particular order.
>
> 1. Arithmetic assignment precedence / associativity.
fixed.
> 2. += environment assignments
>
> 2a. POSIX mode += w/ sp
On 7/22/13 9:07 AM, Chet Ramey wrote:
> The issue is whether or not attributes that determine how the assignment
> should be treated (-a/-A) or how the variable should be created (-g) are
> handled specially and affect how the value is expanded. The question
> is why -i should be omitted from tha
On 7/26/13 12:34 PM, David H. wrote:
> Bash Version: 4.2
> Patch Level: 45
> Release Status: release
>
> Description:
>
> When the read builtin is prefixed by an IFS setting, for field
> splitting, and the input involves an unquoted variable expanded inside
> a herestring, command substituti
On 7/27/13 1:32 PM, Andreas Schwab wrote:
> Chris Down writes:
>
>> Cannot reproduce.
>>
>> $ printf 01 | read -n3
>> $ echo $?
>> 1
>
> Try the same with input from the terminal.
You are reading one character at a time, so ICANON is not set and ^D is an
ordinary character. It's on
OK, that makes sense. Sorry for being confused. I thought that by this
level, ^D and EOF are equivalent. I should be able to check to see if
the character returned is ^D, then act accordingly.
Peter
On 07/27/2013 03:10 PM, Chet Ramey wrote:
On 7/27/13 1:32 PM, Andreas Schwab wrote:
Chris Dow
Chris Down writes:
> Cannot reproduce.
>
> $ printf 01 | read -n3
> $ echo $?
> 1
Try the same with input from the terminal.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely
On 27 July 2013 17:17, Pierre Gaston wrote:
> What is your test case?
> I don't seem to be able to reproduce your problems, read returns
> when it encouters EOF, and I get 1 if fewer bytes are read
It seems it is something like this:
$ read -n3
12^D$ echo $?
0
On Sat, Jul 27, 2013 at 8:11 PM, Peter Olson wrote:
> I was using ^D as an EOF. I guess I should have tried it in other ways. Is
> ^D not the same as EOF? Sorry if that is a noob question. I was able to
> reproduce all of your outputs. I am using xterm as my terminal emulator, if
> that matters.
>
On Sat, Jul 27, 2013 at 7:37 AM, Peter Olson wrote:
> According to "help read":
> Options:
> -n nchars return after reading NCHARS characters rather than
> waiting
> for a newline, but honor a delimiter if fewer than NCHARS
> characters are read befo
On 27 July 2013 19:32, Andreas Schwab wrote:
> Chris Down writes:
>> Cannot reproduce.
>>
>> $ printf 01 | read -n3
>> $ echo $?
>> 1
>
> Try the same with input from the terminal.
Hm, that's a whole other problem then. I can reproduce this by
following that path.
I was using ^D as an EOF. I guess I should have tried it in other ways.
Is ^D not the same as EOF? Sorry if that is a noob question. I was able
to reproduce all of your outputs. I am using xterm as my terminal
emulator, if that matters.
Peter
On 07/27/2013 10:35 AM, Chris Down wrote:
Hello,
Hello,
On 27 July 2013 06:37, Peter Olson wrote:
> If read is invoked with the -n or -N options, then given an EOF, it returns
> with a zero exit status.
Cannot reproduce.
$ echo $BASH_VERSION
4.2.45(2)-release
$ read -n1 In addition, if it is invoked with -n 3, for example, then g
According to "help read":
Options:
-n nchars return after reading NCHARS characters rather
than waiting
for a newline, but honor a delimiter if fewer than NCHARS
characters are read before the delimiter
Exit Status:
The return code is
On Tue, Jul 16, 2013 at 11:12 PM, Linus Torvalds
wrote:
> On Tue, Jul 16, 2013 at 1:31 PM, Lionel Cons wrote:
>>
>> Either your ulimit -i is greater than 63000 or we have a Linux bug. If
>> ulimit -i is reached then kill(1) should fail.
>
> Traditionally kill() has never returned errors for thing
15 matches
Mail list logo
