As I understand, the performance problem of the read built-in utility
originates from its need to read one byte at a time in order not to
swallow input it doesn't process.
Would it make sense to add an "exclusive" option (call it "-x" for now)
to read, where "read -x" essentially means "I promi
> On Sep 27, 2024, at 4:51 PM, Paul Goyette wrote:
>
> On Fri, 27 Sep 2024, tlaro...@kergis.com wrote:
>
>> I will finally learn english some day ;-)
>
> Wait until we native English speakers can learn at least some
> of it! :-)
Me talk pretty one day!
-- thorpej
On Fri, 27 Sep 2024, tlaro...@kergis.com wrote:
I will finally learn english some day ;-)
Wait until we native English speakers can learn at least some
of it! :-)
+-+--+--+
| Paul Goyette (.sig) | PGP Key fingerprint: | E-ma
>>> If the -r option not was given, and the two character sequence
>>> `\'
>> ^^^ ^
>> was not s
> But for the 's', no, English is just weird for things like that.
On Fri, Sep 27, 2024 at 02:04:59PM -0400, Mouse wrote:
> >>> If the -r option not was given, and the two character
> >>> sequence `\'
> >> ^^^ ^
> >> was not s
>
> >
Date:Fri, 27 Sep 2024 18:09:03 +0200
From:tlaro...@kergis.com
Message-ID:
| Just a note on typos:
| > mences. If more lines of data are requred in
| ^^
|
On Fri, Sep 27, 2024 at 10:47:39PM +0700, Robert Elz wrote:
> Date:Fri, 27 Sep 2024 15:04:18 +0200
> From:tlaro...@kergis.com
> Message-ID:
>
> | If I understand correctly your view, the explanation could be
> | something around this (I mean for the idea; for the
Date:Fri, 27 Sep 2024 15:04:18 +0200
From:tlaro...@kergis.com
Message-ID:
| If I understand correctly your view, the explanation could be
| something around this (I mean for the idea; for the way it is
| expressed in some kind of english...):
This what I came u
On Fri, Sep 27, 2024 at 06:52:31PM +0700, Robert Elz wrote:
> Date:Fri, 27 Sep 2024 12:25:49 +0200
> From:tlaro...@kergis.com
> Message-ID:
>
>
> | I have an algebraic mind: I always think of rule. A line, sometime
> | ago, was considered a sequence of bytes endi
Date:Fri, 27 Sep 2024 12:25:49 +0200
From:tlaro...@kergis.com
Message-ID:
| I have an algebraic mind: I always think of rule. A line, sometime
| ago, was considered a sequence of bytes ending by the first appearance
| of '\n'. If a "line" is defined more genera
On Fri, Sep 27, 2024 at 07:03:15AM +0700, Robert Elz wrote:
> Date:Tue, 24 Sep 2024 17:30:42 +0200
> From:tlaro...@kergis.com
> Message-ID:
>
> | Furthermore the continuation test on:
> |
> | if (c != '\n') /* \ \n is always just removed */
> |
Date:Tue, 24 Sep 2024 17:30:42 +0200
From:tlaro...@kergis.com
Message-ID:
| Furthermore the continuation test on:
|
| if (c != '\n') /* \ \n is always just removed */
| goto wdch;
|
| seems wrong. Shouldn't it be?:
|
|
Date:Wed, 25 Sep 2024 20:03:56 +0200
From:tlaro...@kergis.com
Message-ID:
| But a nul byte given as an escaped sequence does not generate an error
| and is discarded (present implementation OK, since choice up to the
| implementation) conforming to (issue 8, tak
On Wed, Sep 25, 2024 at 07:20:31PM +0200, tlaro...@kergis.com wrote:
> On Thu, Sep 26, 2024 at 12:02:08AM +0700, Robert Elz wrote:
> >
> > That is, currently the read builtin simply ignores \0 bytes in the input,
> > except if \0 is the delimiter character. We could change that, and make
> > \0
On Thu, Sep 26, 2024 at 12:02:08AM +0700, Robert Elz wrote:
> Date:Wed, 25 Sep 2024 21:01:12 +0700
> From:Robert Elz
> Message-ID: <24247.1727272...@jacaranda.noi.kre.to>
>
> This isn't avoiding adding a -n that works, but a possible simpler change
> that might help,
Date:Wed, 25 Sep 2024 21:01:12 +0700
From:Robert Elz
Message-ID: <24247.1727272...@jacaranda.noi.kre.to>
This isn't avoiding adding a -n that works, but a possible simpler change
that might help, is much easier to install properly, should break nothing,
and I think wi
Date:Wed, 25 Sep 2024 15:12:07 +0200
From:tlaro...@kergis.com
Message-ID:
| FWIW, you will find below a proposed solution:
Thanks, but there is no need, I will make it work eventually.
I like that you got rid of atoi() from the previous version, but
sh has a funct
On Tue, Sep 24, 2024 at 02:27:48PM +0200, tlaro...@kergis.com wrote:
> On Tue, Sep 24, 2024 at 06:54:35PM +0700, Robert Elz wrote:
> > Date:Tue, 24 Sep 2024 12:56:49 +0200
> > From:
> > Message-ID:
> >
> > | The present patch does two things:
> > |
> > | 1) Set,
On Wed, Sep 25, 2024 at 12:18:28AM +0700, Robert Elz wrote:
>
> It isn't possible. Actually using \ as the delimiter (without
> -r anyway) makes little sense at all, but that doesn't mean it
> needs to be prohibited.
Then, this is another thing that has to be corrected in POSIX, issue
8:
---8<
Date:Tue, 24 Sep 2024 17:30:42 +0200
From:tlaro...@kergis.com
Message-ID:
| In the present code, a delimiter can not be "any character": because
| if the delimiter is the backslash, what shall be the behavior?
That isn't even a half an issue ... the read reads ch
Date:Tue, 24 Sep 2024 14:27:48 +0200
From:tlaro...@kergis.com
Message-ID:
| This can be solved by resetting nread to 0 when an actual end-of-line
| is reached and escaped.
I think it better to just not have a limit in the normal case, it
serves no purpose, except
Date:Tue, 24 Sep 2024 09:09:29 -0400
From:Greg Troxel
Message-ID:
| Sure, but the problem is that if you have a file which is e.g one line
| (single \n at end) that is 10 MB, read from it is unreasonable, and it's
| difficult to deal with this in portable code.
On Tue, Sep 24, 2024 at 06:54:35PM +0700, Robert Elz wrote:
> Date:Tue, 24 Sep 2024 12:56:49 +0200
> From:
> Message-ID:
>
> | The present patch does two things:
> |
> | 1) Set, by default, the maximum of bytes read, in every case, as being
> | LINE_MAX (the m
On Tue, Sep 24, 2024 at 09:09:29AM -0400, Greg Troxel wrote:
> Robert Elz writes:
>
> > Date:Tue, 24 Sep 2024 12:56:49 +0200
> > From:
> > Message-ID:
> >
> > | The present patch does two things:
> > |
> > | 1) Set, by default, the maximum of bytes read, in eve
Robert Elz writes:
> Date:Tue, 24 Sep 2024 12:56:49 +0200
> From:
> Message-ID:
>
> | The present patch does two things:
> |
> | 1) Set, by default, the maximum of bytes read, in every case, as being
> | LINE_MAX (the maximum number of bytes in a line in a te
On Tue, Sep 24, 2024 at 06:54:35PM +0700, Robert Elz wrote:
> Date:Tue, 24 Sep 2024 12:56:49 +0200
> From:
> Message-ID:
>
> | The present patch does two things:
> |
> | 1) Set, by default, the maximum of bytes read, in every case, as being
> | LINE_MAX (the m
Date:Tue, 24 Sep 2024 12:56:49 +0200
From:
Message-ID:
| The present patch does two things:
|
| 1) Set, by default, the maximum of bytes read, in every case, as being
| LINE_MAX (the maximum number of bytes in a line in a text file);
I am not really in favour
The intrinsics built-in read was specified in earlier POSIX to
treat text file, that are supposed to end with a newline. It has been
relaxed to take into account usage and implementation, allowing to
treat as input a file without a newline.
Problem arise when read is used, for example in pkgsrc u
28 matches
Mail list logo
