Sort - Checking & Handling File Types

[Amit Biswas]

I am not completely sure if you would consider this a bug or not. Sort like many other applications does not check for file types of the inputs that are passed in as arguments. Any case, I wanted to entertain the idea of checking file types (https://github.com/pkmoore/rrapper/blob/master/anomalies/weird_filetypes.md). For example, sorting files that of type block/character/fifo does not make much sense as it will just hang or use up all cpu cycles. The best implementation of file type checking is in the coreutils application mv (copy.c).

I have included a patch that adds file type check for the types mentioned above. Any input or criticism is highly appreciated. I would be happy to look an an alternative option or otherwise.

Thanks!
Amit
<email address hidden>

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "patch for checking file type" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[C de-Avillez (hggdh2)]

Thank you for opening this bug and helping make Ubuntu/GNU Coreutils better. I have sent email to <email address hidden> asking about this, and a few other bugs relating to the same basic issue, and am waiting on feedback from upstream:

Hello,

We have had some bugs reported recently at our BTS:

https://bugs.launchpad.net/bugs/1807295
https://bugs.launchpad.net/bugs/1807797
https://bugs.launchpad.net/bugs/1808092
https://bugs.launchpad.net/bugs/1808095

They deal with sort, split, fmt, and uniq, respectively, and provide tentative patches.

I would like to re-direct the reporters to upstream (i.e., you folks), but I feel it would be nice to do the redirect with a small blurb of what upstream thinks about that.

Thank you,

..C..

[C de-Avillez (hggdh2)]

First of all, I apologise for the delay.

Given what upstream, below, answered, I am closing this bug WONTFIX. Please contact Coreutils upstream at <email address hidden> for more details.

In general, changes to Coreutils code should be submitted upstream. Distro-wise, we very rarely deviate from upstream (and, for Coreutils and many of the Ubuntu packages, from Debian).

Cheers,

------ email from upstream ------

Hello,

On 2018-12-28 11:21 a.m., C de-Avillez wrote:
> We have had some bugs reported recently at our BTS:
>
> https://bugs.launchpad.net/bugs/1807295
> https://bugs.launchpad.net/bugs/1807797
> https://bugs.launchpad.net/bugs/1808092
> https://bugs.launchpad.net/bugs/1808095
>
> They deal with sort, split, fmt, and uniq, respectively, and provide
> tentative patches.

A summary other mailing-list readers:

The "filetype" in question is regular files vs fifo / char devices /
block /devices.

The four requests all say something like:

==

"Sort like many other applications does not check for file types of the
inputs that are passed in as arguments. [...] For example, sorting files
that of type block/character/fifo does not make much sense as it will
just hang or use up all cpu cycles. "

==

> I would like to re-direct the reporters to upstream (i.e., you folks),
> but I feel it would be nice to do the redirect with a small blurb of
> what upstream thinks about that.

First and foremost,
I think these are not bugs, and this is perfectly valid behavior.
If a user wants to process a non-regular file, they can do so.

The reasoning of "wasting" CPU/memory can be just as valid to
processing arbitrary large binary files.

---

Also,
Few observations:
1. These four issues were reported by different people (all new
LaunchPad users), during very short time period (second week of
december).

2. Three out of the four link to this
document, which explains about different file types as part of what
looks like a sys-call exerciser:
https://github.com/pkmoore/rrapper/blob/master/anomalies/weird_filetypes.md

3. The above document mention but does not explain what "S_IFSOCK" is,
and (perhaps as a result) none of their patches deals with S_IFSOCK
(despite that everything said about char-devices and fifos applies
to sockets as well).

4. Rejecting FIFOs as input indicates the submitters have some lack of
familiarity with unix command-line.

Given all the above,
I suspect this is part of a homework exercise given to students at some
college, perhaps something like "find bugs in an free software project
and submit a patch to them".

While good intentioned, these suggestions should be rejected as
"wontfix".

For any students or potential contributers who want to start working on
GNU coreutils - PLEASE write to <email address hidden> and introduce
yourself, and we will easily provide ideas on useful contributions
that would be accepted.

Of course, the above is just my opinion, and others are welcomed
to chime in.

regards,
  - assaf