[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Discovering alternative commands



On Thu 01 Jun 2017 at 09:20:08 (-0500), Richard Owlett wrote:
> On 06/01/2017 08:14 AM, tomas@tuxteam.de wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On Thu, Jun 01, 2017 at 07:22:36AM -0500, Richard Owlett wrote:
> >>I'm working on a problem that requires as input an association of
> >>disk partitions and their "label" (in gparted sense).
> >>
> >>I already have blkid and lsblk. They are obviously designed for
> >>different purposes. They both _can_ supply the desired information.
> >>Neither is ideal for me.
> >
> >You're always so whimsical :)
> 
> *ROFL* I disagree.

I agree very much.

> My questions may be weird, obtuse, or convoluted. Rarely, if ever,
> whimsical ;)
> What people have said about my world view for >70 yrs best left ...

The problem with whimsical is that it has two meanings. From the web,
for ease of cut and paste,

1.
playfully quaint or fanciful, especially in an appealing and amusing way.
"a whimsical sense of humor"

No, not that.

2.
acting or behaving in a capricious manner.
"the whimsical arbitrariness of autocracy"

Yes, exactly that. You read people's answers and then pronounce upon
them in accordance with your thinking, which we're not party to
because you rarely if ever reveal it.

As an example, you wrote above:

> >>I already have blkid and lsblk. They are obviously designed for
> >>different purposes. They both _can_ supply the desired information.
> >>Neither is ideal for me.

with not a hint of what would be ideal.

> >Do those commands provide the information you need, albeit in a wrong
> >format, or is anything truly amiss?
> 
> Yes.
> 
> >
> >>Two questions (one asking for fish, the other asking to be taught to fish):
> >>1. what other commands should I look at?
> 
> That is EXPLICITLY the intended question.

Right. So are we meant to spend time looking for different commands
which, importantly, must reveal must either reveal more information
or the same information in a different way, in order that perchance
it might be more ideal for you?

> I've in the past have had teachers who would pick
> grammatical/syntactic nits who would have asserted that "can" would
> would have a better word choice than "should". [P.S. linguistics is
> an semantically fascinating universe of discourse ;]
> 
> I terms of set theory ;}
> Please enumerate those commands which can report all partition ids
> and associated labels.
> That specifies the appropriate necessary and sufficient conditions.
> Literally the best way to interpret my questions is literally.

Oh, so my question above was wrong. We're expected to find _all_
commands, regardless of whether they might be more ideal or not.

> >>2. is there some reference that groups commands/programs by similarity?
> >
> >Your requests for help tend to contain restrictions which sometimes
> >are difficult to grasp for your interlocutors.
> 
> I'll paraphrase a hermeneutics professor "If the plain sense makes
> common sense, seek no other sense."
> 
> >To you, of course, these
> >restrictions seem natural, because they are the result of a thought
> >process you have access to -- but consider that we don't. Sometimes
> >those restrictions seem artificial, without the context, and I'm left
> >left wondering whether it's that I'm not understanding your request
> >or whether it's you excluding a viable possibility.
> >
> >So is it the output's content or their form what isn't up to your
> >needs?
> 
> Neither.
> One, of many, things that prompted me ask if either was preferable
> is one requires root privileges and the other not.

So we were wrong all along, and we're _still_ only allowed to know one
thing that prompted you to ask your question, and we weren't told it
before spending time diligently seeking commands which might,
or might not, be ideal for you because they might require root privilege.

Anyway, rather than suggest a command that may or may not be ideal,
I would ask you to look in two places:

/dev/disk/…
/run/udev/data/b*

Plenty of information there to parse.

Cheers,
David.


Reply to: