Re: cut -d fails when using a multi-byte delimiter

[Kamil Dudka]

On Wednesday, March 27, 2019 11:34:03 PM CET Assaf Gordon wrote:
> On 2019-03-27 3:24 a.m., Kamil Dudka wrote:
> > On Wednesday, March 27, 2019 9:04:06 AM CET Tim Rühsen wrote:
> > 
> > I do not think there was any problem with format of the submission.  As I
> > understand it, the effort is now stalled because the lack of competent and
> > motivated enough reviewers.
> 
> Respectfully, no.
> 
> Adding proper multibyte support for coreutils is an on-going
> effort that started long before these specific patches

Sorry, I did not want to say that nobody was working on this.  I just wanted 
to point out that the mentioned patches were sent upstream long time ago but 
have not been merged yet.

> (for overview and details see
> https://crashcourse.housegordon.org/coreutils-multibyte-support.html ).

Nice summary.  Is there any reason why Eric's patches are not mentioned there?

> These patches complement some of the on-going patches,
> while other aspects still need to be addressed.
> (unfortunately they were developed from scratch instead
> of relying on existing efforts, so merging them is also work).

Would it help to mention your summary in coreutils FAQ to avoid duplicated 
work in the future?

> As with all volunteer efforts, these things take time
> (at least I'm a volunteer, not working for a company that supports
> coreutils or free-software works).
> 
> A major hurdle is supporting more limited environments
> such as cygwin, and yet I don't see redhat putting emphasis
> on these efforts - so I can assume it is not a top-priority.

Red Hat has been using a downstream multi-byte patch for coreutils at least 
since 2003 (long time before I joined Red Hat):

    https://partner-bugzilla.redhat.com/82032

It sort of works now, so there is no big demand to re-implement it properly.  
Suse uses the same patch, as far as I know.

Kamil

> If we could assume only sane environments (e.g proper and efficient mbcs
> libc support and 32-bit wchar_t) then all these features would've
> been included long ago (IMHO).
> 
> regards,
>   - assaf