bug#14224: Feature request for the `cut`: record delimiter

[Bob Proulx]

severity 14224 wishlist
thanks

George Brink wrote:
> I have a task of extracting several "fields" from the text file. The
> standard `cut` tool could be a perfect tool for a job, but...

Thank you for the bug report.  However note that 'cut' is often not
the right tool for the job.  Almost always when people want more than
cut offers it is revealed that they should be using awk or other tool.

> In my file the '\n' character is a legal symbol inside fields and therefore
> the text file uses other symbol for record-separator.

Then it isn't a text file.  By definition.

  http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html

    3.392 Text File

    A file that contains characters organized into one or more lines.
    The lines do not contain NUL characters and none can exceed
    {LINE_MAX} bytes in length, including the <newline>.  Although IEEE
    Std 1003.1-2001 does not distinguish between text files and binary
    files (see the ISO C standard), many utilities only produce
    predictable or meaningful output when operating on text files.  The
    standard utilities that have such restrictions always specify "text
    files" in their STDIN or INPUT FILES sections.

  http://pubs.opengroup.org/onlinepubs/009695399/utilities/cut.html

  INPUT FILES

    The input files shall be text files, except that line lengths
    shall be unlimited.

Of course GNU isn't Unix (nor POSIX) and we can extend them usefully
if it makes sense to do so.  However creeping featurism is the Evil
and therefore will need discussion and justification.

Could you please give a discription of your input syntax in more
detail?  Usually people will suggest a better tool for the job and
that often solves the problem immediately.

> The fix for this should be a simple one. I can probably make it
> myself but where to send the patch?

Since it isn't a bug then it isn't a "fix".  It would be an enhancement.
I have set the bug severity appropriately.

> The README in coreutils suggests to read README-hacking and HACKING for
> guide-lines on making a patch, but there are no such files in the the
> coreutils-8.21.tar.xz.

Anyone working on the source code is expected to be working from the
version control files.  Because the pace of change is rapid and doing
so just makes it easier all around.

Here is the current HACKING file from the vcs online web frontend.

  http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=HACKING;hb=HEAD

Please read through that document.  It should give you all of the
information you need to submit patches to the project.  Be sure to
read the "Copyright assignment" section so that it doesn't come as a
surprise later after a lot of work has been put into it.  Any
non-trivial contribution needs an assignment and it is good to get
that started early.

If you have any questions please ask them.  Since this bug is already
created it is okay to follow-up with questions here.  Please keep the
bug log address in the recipient list.

But if you are asking questions or generating random discussion then
please use the address@hidden mailing list instead of the bug
tracker.  We often spend a lot of time closing bug reports that are
doing nothing but asking questions.

Bob