On Fri, Jan 18, 2013 at 1:48 PM, Pierre Gaston wrote:
> On Fri, Jan 18, 2013 at 2:44 PM, Linus Swälas wrote:
>> On Fri, Jan 18, 2013 at 12:56 PM, Pierre Gaston
>> wrote:
>>> On Fri, Jan 18, 2013 at 1:38 PM, Linus Swälas
>>> wrote:
On Fri, Jan 18, 2013 at 6:57 AM, Pierre Gaston
wro
On Fri, Jan 18, 2013 at 1:38 PM, Linus Swälas wrote:
> On Fri, Jan 18, 2013 at 6:57 AM, Pierre Gaston
> wrote:
>>
>> On Thu, Jan 17, 2013 at 4:24 PM, Linus Swälas
>> wrote:
>>>
>>> I have a similar problem to report as Fiedler Roman regarding read and
>>> also
>>> another problem regarding whil
On Fri, Jan 18, 2013 at 6:57 AM, Pierre Gaston wrote:
>
> On Thu, Jan 17, 2013 at 4:24 PM, Linus Swälas
> wrote:
>>
>> I have a similar problem to report as Fiedler Roman regarding read and
>> also
>> another problem regarding while. Maybe the while case is intended behavior
>> though. =)
>> # w
On Thu, Jan 17, 2013 at 4:24 PM, Linus Swälas wrote:
> I have a similar problem to report as Fiedler Roman regarding read and also
> another problem regarding while. Maybe the while case is intended behavior
> though. =)
> # It the below also a bug?
>
# while can't handle nulls, this doesn't work:
I have a similar problem to report as Fiedler Roman regarding read and also
another problem regarding while. Maybe the while case is intended behavior
though. =)
See comments in the script below.
bash --version
GNU bash, version 4.2.39(1)-release (x86_64-redhat-linux-gnu)
Example script starts
On 12/20/12 6:21 AM, Fiedler Roman wrote:
> OK, so if I understand correctly, following should be true:
>
> Referring to my e-mail from Mo 17.12.2012 09:35, it seems that you get the
> "hypothetical output", which is correct, while the script on my side produces
> different output.
>
> Hence t
> -Ursprüngliche Nachricht-
> Von: Chet Ramey [mailto:chet.ra...@case.edu]
> Gesendet: Mittwoch, 19. Dezember 2012 22:50
> An: Fiedler Roman
> Cc: chet.ra...@case.edu; bug-bash@gnu.org
> Betreff: Re: AW: Questions to bash "read" builtin functionality
>
On Wed, Dec 19, 2012 at 04:49:32PM -0500, Chet Ramey wrote:
> I get the same results if I run the pipeline in an interactive shell.
> This is pretty much what I expect. The whitespace and newlines will
> disappear due to read's $IFS processing if they're first or last in
> the string.
Which is wh
On 12/17/12 3:34 AM, Fiedler Roman wrote:
> From your description, I would expect
>
> --- HYPOTHETICAL-OUTPUT---
> # ./FragmentedSend.py | ./BashReadTest
> Read status 142, value ""
> Read status 142, value "Stat" << the partial read
> FAILED READ: "us: OK"
> Traceback (most recent call la
> Von: Chet Ramey [mailto:chet.ra...@case.edu]
> Gesendet: Montag, 17. Dezember 2012 15:10
>
> On 12/17/12 3:34 AM, Fiedler Roman wrote:
> > That is strange: If I understand correctly, following script combined with
> > the
> one from first mail should still fail, but with different error. But i
On 12/17/12 3:34 AM, Fiedler Roman wrote:
> That is strange: If I understand correctly, following script combined with
> the one from first mail should still fail, but with different error. But it
> fails in a way similar to discarding partial input, not saving it. Could it
> be, that Ubuntu-ba
> -Ursprüngliche Nachricht-
> Von: Chet Ramey [mailto:chet.ra...@case.edu]
> Gesendet: Samstag, 15. Dezember 2012 23:53
>
> On 12/14/12 6:28 AM, Fiedler Roman wrote:
> > Hello list,
> >
> > One of our bash-scrips failed with very low frequency but randomly. The
> result was that exactly 1
On 12/14/12 6:28 AM, Fiedler Roman wrote:
> Hello list,
>
> One of our bash-scrips failed with very low frequency but randomly. The
> result was that exactly 1 byte was lost, so the string returned by "read -t
> 1" was too short. The culprit seems to be the built-in read function itself,
> the
Hello list,
One of our bash-scrips failed with very low frequency but randomly. The result
was that exactly 1 byte was lost, so the string returned by "read -t 1" was too
short. The culprit seems to be the built-in read function itself, the
probability of failure was about 1:10 in our case.
14 matches
Mail list logo