bug#47777: Feature request

[Stuart Blake Tener]

 Pádraig,

You (and any other developer) surely have the right to feel that you
do not have the time or desire to implement such a feature (for any
reason). You may also feel that I'd be the only one served by such a
feature and therefore the feature request lacks worthiness to have
time allocated to it. I would take no offense if you said, we are not
interested in that request, but, this is open source so you may
implement it yourself if you wish. That is a very fair response to
take, however, your response is not that and as such is was a bit
offensive. Presuming you did not mean it to be offensive, I would
imagine you can appreciate how I might not feel all smiles by being
told what will be the most useful thing for me, I prefer to make that
determination on my own thank you very much. As such, I honestly
attempted to articulate with the greatest specificity I could that
which I meant.

If English is not a first language for you and you really were not
sure what I meant, okay, I apologize in advance. However, I doubt that
is the case since you restated what you thought I said in your own
words with similar meaning in precedence to lambasting the idea in a
dismissive and derisive manner.

The foregoing notwithstanding, I do believe that software is best
designed when it provisions that greatest level of flexibility and
capability to potential users. Any time a programmer or designer
begins to determine what functionality a user will never use or want,
it all but guarantees someone will complain and say, NO, that is
EXACTLY what I want it to do. Thus, I would argue that whilst there
may surely be a use case as you propose and as I already have a use
case for what I propose, then perhaps I am best to amend my request
such that it satisfies both. The fact that you have seen a way to
expand and more greatly augment the value of my idea is surely
interesting and therefore I am amending my request in pursuance of
such a capability!

--include-type=parm1[,parm2,parm3...]
A parameter representing a filesystem type to be additive to the
currently supported default list of filesystems.

--include-replace
this parameter overrides the default functionality of the
"--include-type" being additive to the currently supported list of
default filesystems and replaces that list with the filesystem or
filesystems so specified in the "--include-type" parameter.

Stuart

Quoting: Pádraig Brady <P@draigbrady.com>

> On 14/04/2021 15:36, Stuart Blake Tener wrote:
> > Honorable maintainers,
> >
> > I am interested to request a feature addition to the 'df' program for
> > Linux. I have been working with UNIX in general since 1985. For some
> > time I have wanted this feature and just never took the time to ask
> > for it (okay, that is not your fault!), but here I am requesting away.
> >
> > It is surely possible to use '--type' to enumerate (painfully) all the
> > filesystem types you want. However, what I would like is an
> > '--include-type'. Thus, if I want df to work as normal but just to
> > include one more filesystem that I want in its functional list (say
> > ZFS), then this would be quite handy! What say you?
> >
> > Thanks in the past for coreutils and thanks in advance too! Do keep up
> > the excellent work and stay safe (thug free), healthy, and blessed.
> >   Very Respectfully,
>
> Do you mean for --include-type=blahfs to display blahfs
> along with the default types it displays.
> I.e. where blahfs would normally be suppressed
> (due to being a dummy file system etc.).
>
> If so, that doesn't seem that useful,
> as for that use case you'd probably be more
> interested in seeing blahfs in isolation.
>
> cheers,Pádraig
 Very Respectfully,

Stuart Blake Tener, BScCS, N3GWG (Extra), MROP
Computer Scientist / FCC Licensed Radio Operator

Las Vegas, NV / Philadelphia, PA

(310) 358-0202 Mobile Phone
(215) 338-6005 Google Voice