Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #204667 > unrolled thread

Partition information as text file?

Back to article view | Back to linux.debian.user

Contents

  Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-26 15:40 +0100
    Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-01-26 18:10 +0100
    Re: Partition information as text file? Felix Miata <mrmazda@earthlink.net> - 2019-01-26 20:40 +0100
      Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-26 22:20 +0100
        Re: Partition information as text file? "Alexander V. Makartsev" <avbetev@gmail.com> - 2019-01-26 23:00 +0100
        Re: Partition information as text file? Felix Miata <mrmazda@earthlink.net> - 2019-01-27 03:10 +0100
        Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-01-27 22:30 +0100
          Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-28 13:50 +0100
            Re: Partition information as text file? Ionel Mugurel Ciobîcă <I.M.Ciobica@gmail.com> - 2019-01-28 16:50 +0100
            Re: Partition information as text file? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-28 20:50 +0100
              Re: Partition information as text file? <tomas@tuxteam.de> - 2019-01-29 15:40 +0100
                Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-29 16:30 +0100
                  Re: Partition information as text file? <tomas@tuxteam.de> - 2019-01-29 16:40 +0100
                  Re: Partition information as text file? "Thomas Schmitt" <scdbackup@gmx.net> - 2019-01-29 17:20 +0100
                    Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-31 15:20 +0100
                      Re: Partition information as text file? "Thomas Schmitt" <scdbackup@gmx.net> - 2019-01-31 16:00 +0100
                        Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-01-31 20:30 +0100
                          Re: Partition information as text file? "Thomas Schmitt" <scdbackup@gmx.net> - 2019-01-31 21:10 +0100
                            Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-02-01 15:10 +0100
                              Re: Partition information as text file? "Thomas Schmitt" <scdbackup@gmx.net> - 2019-02-01 15:30 +0100
                                Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-02-01 16:10 +0100
                                  Re: Partition information as text file? <tomas@tuxteam.de> - 2019-02-01 16:30 +0100
                                    Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-01 17:10 +0100
                                    Re: Partition information as text file? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-01 19:40 +0100
                                      Re: Partition information as text file? <tomas@tuxteam.de> - 2019-02-01 22:30 +0100
                                  Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-01 17:20 +0100
                                    Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-02-01 18:10 +0100
                                      Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-02 02:10 +0100
                                        Re: Partition information as text file? <tomas@tuxteam.de> - 2019-02-02 11:00 +0100
                                          Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-02 16:30 +0100
                                            Re: Partition information as text file? <tomas@tuxteam.de> - 2019-02-02 17:20 +0100
                                Re: Partition information as text file? rhkramer@gmail.com - 2019-02-01 17:00 +0100
                              Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-01 17:10 +0100
                              Re: Partition information as text file? Felix Miata <mrmazda@earthlink.net> - 2019-02-01 17:20 +0100
                                Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-01 17:30 +0100
                              Re: Partition information as text file? Joe <joe@jretrading.com> - 2019-02-01 19:10 +0100
                                Re: Partition information as text file? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-01 19:20 +0100
                                  Re: Partition information as text file? Dan Ritter <dsr@randomstring.org> - 2019-02-01 19:30 +0100
                                  Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-01 23:10 +0100
                  Re: Partition information as text file? Peter Ehlert <peter@sdi-baja.com> - 2019-01-29 17:40 +0100
                  Re: Partition information as text file? Jude DaShiell <jdashiel@panix.com> - 2019-01-29 19:00 +0100
              Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-29 15:40 +0100
                Re: Partition information as text file? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-29 21:10 +0100
                  Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-30 16:10 +0100
                    Re: Partition information as text file? <tomas@tuxteam.de> - 2019-01-30 17:00 +0100
                      Talking about loop devices (was: Re: Partition information as text file?) David <bouncingcats@gmail.com> - 2019-01-31 02:20 +0100
                        Re: Talking about loop devices (was: Re: Partition information as  text file?) David <bouncingcats@gmail.com> - 2019-01-31 04:50 +0100
                        Re: Talking about loop devices (was: Re: Partition information as  text file?) <tomas@tuxteam.de> - 2019-01-31 10:10 +0100
                        Re: Talking about loop devices Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-31 20:00 +0100
                          Re: Talking about loop devices David <bouncingcats@gmail.com> - 2019-02-01 06:30 +0100
                    Re: Partition information as text file? Joe <joe@jretrading.com> - 2019-01-30 17:10 +0100
                      Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-31 15:30 +0100
                    Re: Partition information as text file? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-30 19:50 +0100
                Re: Partition information as text file? David <bouncingcats@gmail.com> - 2019-01-30 03:10 +0100
                  Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-30 16:20 +0100
            Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-01-29 19:30 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#204891

On 02/01/2019 08:22 AM, Thomas Schmitt wrote:
> Hi,
> 
> Richard Owlett wrote:
>> [Gparted] PROVED that what I wanted was possible.
> 
> Regrettably it does not retrieve the information by some universal info
> program or library, but rather has particular info sources for each of
> the supported filesystems. (There are more filesystems around than i can
> see in the Gparted source.)
> 
> 
>> It's "suitability to purpose" was degraded on *2* counts:
>> 1. it does not output the data as a text file.
> 
> So you need one or more scripts ... Then the script[s] would put out
> the retrieved numbers in the text format which you desire.

The need for *ME* to write a script was a BASIC assumption to my asking 
about commands relevant to my task.

> 
> 
>> man page format [...] almost total lack of examples [...]
> 
> If you refer to Gparted's man page, ...

I was referring to Linux man pages in general. I've ~10 man pages of 
commands mentioned in this thread -- none with useful examples. For a 
specific command I routinely do a web search with the keywords 
"examples" &/or "tutorial".

Though I don't refer to myself as a programmer I've written "scripts" 
[using term loosely]:
   in the early 60's using CORC/CUPL {Cornell's predecessor to BASIC}
   in the mid 70's using DEC's TECO {not just an editor ;}
   later dBASEII and Paradox
   am now exploring Tcl/Tk

[toc] | [prev] | [next] | [standalone]

#204893

[Multipart message — attachments visible in raw view] — view raw

On Fri, Feb 01, 2019 at 09:00:06AM -0600, Richard Owlett wrote:
> On 02/01/2019 08:22 AM, Thomas Schmitt wrote:

[...]

> >So you need one or more scripts ... Then the script[s] would put out
> >the retrieved numbers in the text format which you desire.
> 
> The need for *ME* to write a script was a BASIC assumption to my
> asking about commands relevant to my task.

Perhaps the humble command "file" could be an ally in that. It's
not a complete solution, though...

Remember: "file" looks (with some exceptions, see below) into the
contents of a file and tries to find out what it is, by looking
for "magic numbers" (more precisely patterns) stored in a file
(/usr/share/misc/magic).

Here's a small session from my box (with some elisions marked as [...]

  tomas@trotzki:~$ mount
  /dev/sda1 on /boot type ext2 (rw,relatime,block_validity,barrier,user_xattr,acl)
  /dev/mapper/trotzki-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
  /dev/mapper/trotzki-usr on /usr type ext4 (rw,relatime,data=ordered)
  /dev/mapper/trotzki-home on /home type ext4 (rw,relatime,data=ordered)
  /dev/mapper/trotzki-var on /var type ext4 (rw,relatime,data=ordered)
  [...]

(Note: my "partitions" are, with exception of /dev/sda1, which is the boot
partition, LVM volumes which are cut out from a physical volume which is
LUKS encrypted: I don't want someone to get at my (and my customer's)
data just because I leave the laptop in the metro).

Now:

  tomas@trotzki:~$ file /dev/mapper/trotzki-home 
  /dev/mapper/trotzki-home: symbolic link to ../dm-4

Ah.

  tomas@trotzki:~$ file /dev/dm-4
  /dev/dm-4: block special (254/4)

Not yet what we wanted. But:

  tomas@trotzki:~$ sudo file -s /dev/dm-4
  /dev/dm-4: Linux rev 1.0 ext4 filesystem data, UUID=c5d1ae98-df63-4c04-913d-661b82d38075 (needs journal recovery) (extents) (64bit) (large files) (huge files)

I guess that's not all info you want, but hey. Sudo is needed, because mere
mortals have no business in reading raw disks, usually; The "needs journal
recovery" sounds alarming, but remember that the thing is mounted, i.e.
active, so that's OK too.

Perhaps this can be a small building block for you.

I guess you'd like more info about the file system (size, what not).
Those commands (and their outputs!) are most probably file system
specific, as Thomas points out.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#204898

On Fri 01 Feb 2019 at 16:23:04 (+0100), tomas@tuxteam.de wrote:

> Not yet what we wanted. But:
> 
>   tomas@trotzki:~$ sudo file -s /dev/dm-4
>   /dev/dm-4: Linux rev 1.0 ext4 filesystem data, UUID=c5d1ae98-df63-4c04-913d-661b82d38075 (needs journal recovery) (extents) (64bit) (large files) (huge files)
> 
> I guess that's not all info you want, but hey. Sudo is needed, because mere
> mortals have no business in reading raw disks, usually; The "needs journal
> recovery" sounds alarming, but remember that the thing is mounted, i.e.
> active, so that's OK too.

I hadn't bothered to say this already, but not replaying the journal
could be one reason that wrong information is returned from unmounted
filesystems, as Pascal mentioned earlier.

That could be another reason to mount them (readonly) and let df
complete the dirty work of finding the information you want (as
I outlined much earlier in this thread).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#204909

Le 01/02/2019 à 16:23, tomas@tuxteam.de a écrit :
> 
>    tomas@trotzki:~$ file /dev/mapper/trotzki-home
>    /dev/mapper/trotzki-home: symbolic link to ../dm-4
> 
> Ah.
> 
>    tomas@trotzki:~$ file /dev/dm-4
>    /dev/dm-4: block special (254/4)
> 
> Not yet what we wanted. But:
> 
>    tomas@trotzki:~$ sudo file -s /dev/dm-4

In one single command :

# file -Lsk /dev/mapper/whatever

> Sudo is needed

No it's not. Read permission on the raw device is needed, by whatever 
way including sudo but not only (su, root session...).

[toc] | [prev] | [next] | [standalone]

#204910

[Multipart message — attachments visible in raw view] — view raw

On Fri, Feb 01, 2019 at 07:30:31PM +0100, Pascal Hambourg wrote:
> Le 01/02/2019 à 16:23, tomas@tuxteam.de a écrit :
> >
> >   tomas@trotzki:~$ file /dev/mapper/trotzki-home
> >   /dev/mapper/trotzki-home: symbolic link to ../dm-4
> >
> >Ah.
> >
> >   tomas@trotzki:~$ file /dev/dm-4
> >   /dev/dm-4: block special (254/4)
> >
> >Not yet what we wanted. But:
> >
> >   tomas@trotzki:~$ sudo file -s /dev/dm-4
> 
> In one single command :
> 
> # file -Lsk /dev/mapper/whatever

Yep, thanks. I just wanted to sketch a path to the idea.

> >Sudo is needed
> 
> No it's not. Read permission on the raw device is needed, by
> whatever way including sudo but not only (su, root session...).

This is of course more correct than my handwaving description :-)
> 

[toc] | [prev] | [next] | [standalone]

#204900

On Fri 01 Feb 2019 at 09:00:06 (-0600), Richard Owlett wrote:
> On 02/01/2019 08:22 AM, Thomas Schmitt wrote:
> > Richard Owlett wrote:
> > > [Gparted] PROVED that what I wanted was possible.
> > 
> > Regrettably it does not retrieve the information by some universal info
> > program or library, but rather has particular info sources for each of
> > the supported filesystems. (There are more filesystems around than i can
> > see in the Gparted source.)
> > 
> > > It's "suitability to purpose" was degraded on *2* counts:
> > > 1. it does not output the data as a text file.
> > 
> > So you need one or more scripts ... Then the script[s] would put out
> > the retrieved numbers in the text format which you desire.
> 
> The need for *ME* to write a script was a BASIC assumption to my
> asking about commands relevant to my task.
> > 
> > > man page format [...] almost total lack of examples [...]
> > 
> > If you refer to Gparted's man page, ...
> 
> I was referring to Linux man pages in general. I've ~10 man pages of
> commands mentioned in this thread -- none with useful examples. For a
> specific command I routinely do a web search with the keywords
> "examples" &/or "tutorial".
> 
> Though I don't refer to myself as a programmer I've written "scripts"
> [using term loosely]:
>   in the early 60's using CORC/CUPL {Cornell's predecessor to BASIC}
>   in the mid 70's using DEC's TECO {not just an editor ;}
>   later dBASEII and Paradox
>   am now exploring Tcl/Tk

Interesting. I thought Tcl/Tk was for writing GUIs. I toyed with it
briefly in the late 90s before I started using Tkinter (ie Python).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#204903

On 02/01/2019 10:15 AM, David Wright wrote:
> [snip]
> 
> Interesting. I thought Tcl/Tk was for writing GUIs. ...

*CAVEAT* LECTOR
It is more like Tk being a GUI interface for Tcl.

[toc] | [prev] | [next] | [standalone]

#204915

On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote:
> On 02/01/2019 10:15 AM, David Wright wrote:
> > [snip]
> > 
> > Interesting. I thought Tcl/Tk was for writing GUIs. ...
> 
> *CAVEAT* LECTOR
> It is more like Tk being a GUI interface for Tcl.

Sure, and for several other languages, but I assume you wouldn't want
a GUI interface for your text-producing script even if you write it
in Tcl.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#204917

[Multipart message — attachments visible in raw view] — view raw

On Fri, Feb 01, 2019 at 07:05:53PM -0600, David Wright wrote:
> On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote:
> > On 02/01/2019 10:15 AM, David Wright wrote:
> > > [snip]
> > > 
> > > Interesting. I thought Tcl/Tk was for writing GUIs. ...
> > 
> > *CAVEAT* LECTOR
> > It is more like Tk being a GUI interface for Tcl.
> 
> Sure, and for several other languages, but I assume you wouldn't want
> a GUI interface for your text-producing script even if you write it
> in Tcl.

Tcl still makes for a reasonable scripting language. It's just a bit
different of most "modern" languages (except perhaps shell), so for
Perlies and Pythoners and PHPers it takes some "getting used" to.

But it is pretty powerful.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#204925

On Sat 02 Feb 2019 at 10:58:09 (+0100), tomas@tuxteam.de wrote:
> On Fri, Feb 01, 2019 at 07:05:53PM -0600, David Wright wrote:
> > On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote:
> > > On 02/01/2019 10:15 AM, David Wright wrote:
> > > > [snip]
> > > > 
> > > > Interesting. I thought Tcl/Tk was for writing GUIs. ...
> > > 
> > > *CAVEAT* LECTOR
> > > It is more like Tk being a GUI interface for Tcl.
> > 
> > Sure, and for several other languages, but I assume you wouldn't want
> > a GUI interface for your text-producing script even if you write it
> > in Tcl.
> 
> Tcl still makes for a reasonable scripting language. It's just a bit
> different of most "modern" languages (except perhaps shell), so for
> Perlies and Pythoners and PHPers it takes some "getting used" to.
> 
> But it is pretty powerful.

Yes, I remember Tkinter's thinness overlying it: it would occasionally
be necessary to tickle the Tcl to get precisely what you wanted.

But as for being different, I've found nothing to approach Spitbol
(a superior implementation of Snobol, which I ran on IBM 370s in the
'70s and '80s and then on Vaxen into the mid-'90s). Fortunately
when it fell by the wayside, I found Perl, with its associative
arrays, and even an implementation of Perl on DOS, which kept me
going until I started using Python on linux in late '95.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#204927

[Multipart message — attachments visible in raw view] — view raw

On Sat, Feb 02, 2019 at 09:26:31AM -0600, David Wright wrote:
> On Sat 02 Feb 2019 at 10:58:09 (+0100), tomas@tuxteam.de wrote:
> > On Fri, Feb 01, 2019 at 07:05:53PM -0600, David Wright wrote:
> > > On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote:
> > > > On 02/01/2019 10:15 AM, David Wright wrote:
> > > > > [snip]
> > > > > 
> > > > > Interesting. I thought Tcl/Tk was for writing GUIs. ...
> > > > 
> > > > *CAVEAT* LECTOR
> > > > It is more like Tk being a GUI interface for Tcl.
> > > 
> > > Sure, and for several other languages, but I assume you wouldn't want
> > > a GUI interface for your text-producing script even if you write it
> > > in Tcl.
> > 
> > Tcl still makes for a reasonable scripting language. It's just a bit
> > different of most "modern" languages (except perhaps shell), so for
> > Perlies and Pythoners and PHPers it takes some "getting used" to.
> > 
> > But it is pretty powerful.
> 
> Yes, I remember Tkinter's thinness overlying it: it would occasionally
> be necessary to tickle the Tcl to get precisely what you wanted.
> 
> But as for being different, I've found nothing to approach Spitbol
> (a superior implementation of Snobol, which I ran on IBM 370s in the
> '70s and '80s and then on Vaxen into the mid-'90s). Fortunately
> when it fell by the wayside, I found Perl, with its associative
> arrays, and even an implementation of Perl on DOS, which kept me
> going until I started using Python on linux in late '95.

Yes, Snobol and its family was pretty interesting. FWIW, Tcl has
gained associative arrays.

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#204895

On Friday, February 01, 2019 09:22:10 AM Thomas Schmitt wrote:
> If you refer to Gparted's man page, then the answer is obviously that
> nobody expects hard info from the manual of a clicky-colorful GUI program.
> (I.e. not "RTFM" but "RTSL" = "Read The Source, Luke.")

I hope that's not the case (because I'm an advocate of Linux displacing 
Windows on the desktop -- I don't expect that target audience to have much 
success reading the source).

Also, on the gparted man page (on Wheezy), I see:

<quote>
More documentation can be found in the application help manual, and online at:
       http://gparted.org
</quote>

I didn't look at that, but I hope it is a useful resource.

[toc] | [prev] | [next] | [standalone]

#204896

On Fri 01 Feb 2019 at 07:59:42 (-0600), Richard Owlett wrote:
> On 01/31/2019 02:03 PM, Thomas Schmitt wrote:
> > Hi,
> > 
> > Richard Owlett wrote:
> > > > > What bugs me is Gparted [though it does not output text]  reports
> > > > > used/unused space on each partition/file system.
> > 
> > i wrote:
> > > > [...] Gparted runs external programs, which a simple
> > > > shell script could do too.
> > 
> > David Wright wrote:
> > > So going back to the OP, is this a sensible approach to choose instead
> > > of letting mount and df figure things out for themselves?
> > 
> > It's what Gparted does and what Richard mentioned as example of the desired
> > information.
> 
> I'd make that statement stronger.
> My starting point was Gparted displays *ALL* the desired information
> for *ALL* members of the set [ /dev/sd* ] whether mounted or not.

I think you mean /dev/sdX*.

> That PROVED that what I wanted was possible.

We don't doubt that the information is obtainable. My concern was
whether you wanted a script to place the required information in
a file by COP,¹ or after the indeterminate amount of time it takes
to digest and regurgitate all that code. Fortunately the amount of
code you need to examine will be reduced by the fact that you
personally have a very limited group of partition types in your
inventory.

> It's "suitability to purpose" was degraded on *2* counts:
> 1. it does not output the data as a text file.
> 2. it displays information for only 1 device at a time.

Yes, the thought of juggling several partition tables simultaneously
had probably not occurred to any sane person.

> > Given that the source code of Gparted is published, we do not
> > have to speculate how it does this, but rather can riddle over its C++ code.
> 
> Having known working source code for a program that almost meets my
> needs/desires remedies a major deficiency of the man page format --
>  [/begin_rant   almost total lack of examples /end_rant ;]

Have you tried pressing F1 in the gparted window itself?

I was under the impression that man pages were an aide-mémoire for CLI
users so that they don't have to commit all the options and arguments
to memory. Its flat-file format doesn't really lend itself to copious
examples, particularly where they would be trying to describe how to
navigate round a widget-filled picture.

But this dead horse has been flogged enough times on this list already.

Perhaps when your script is finished you could share it here. Many of
us are probably running systems with no more than ext & fat filesystems,
and could usefully employ it.

¹ Close of Play seems to be missing from wiki's Cop page, even though
it appears under End_of_day.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#204901

Richard Owlett composed on 2019-02-01 07:59 (UTC-0600):

> Thomas Schmitt wrote:

>> It's what Gparted does and what Richard mentioned as example of the desired
>> information.

> I'd make that statement stronger.
> My starting point was Gparted displays *ALL* the desired information for 
> *ALL* members of the set [ /dev/sd* ] whether mounted or not.

> That PROVED that what I wanted was possible.

> It's "suitability to purpose" was degraded on *2* counts:
> 1. it does not output the data as a text file.
> 2. it displays information for only 1 device at a time.

>> Given that the source code of Gparted is published, we do not
>> have to speculate how it does this, but rather can riddle over its C++ code.

> Having known working source code for a program that almost meets my 
> needs/desires remedies a major deficiency of the man page format --
>   [/begin_rant   almost total lack of examples /end_rant ;]

Maybe the following would do better

script
parted # instead of gparted
some parted commands
parted exit
script exit
nano typescript

All assuming you tried dfsee and didn't manage to find options to produce exactly your
desires in its logs even with some editing.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#204902

On Fri 01 Feb 2019 at 11:14:11 (-0500), Felix Miata wrote:
> Richard Owlett composed on 2019-02-01 07:59 (UTC-0600):
> > Thomas Schmitt wrote:
> 
> >> It's what Gparted does and what Richard mentioned as example of the desired
> >> information.
> 
> > I'd make that statement stronger.
> > My starting point was Gparted displays *ALL* the desired information for 
> > *ALL* members of the set [ /dev/sd* ] whether mounted or not.
> 
> > That PROVED that what I wanted was possible.
> 
> > It's "suitability to purpose" was degraded on *2* counts:
> > 1. it does not output the data as a text file.
> > 2. it displays information for only 1 device at a time.
> 
> >> Given that the source code of Gparted is published, we do not
> >> have to speculate how it does this, but rather can riddle over its C++ code.
> 
> > Having known working source code for a program that almost meets my 
> > needs/desires remedies a major deficiency of the man page format --
> >   [/begin_rant   almost total lack of examples /end_rant ;]
> 
> Maybe the following would do better
> 
> script
> parted # instead of gparted
> some parted commands
> parted exit
> script exit
> nano typescript
> 
> All assuming you tried dfsee and didn't manage to find options to produce exactly your
> desires in its logs even with some editing.

Um, I think that was last Saturday's solution, complete with EXAMPLE
(all caps in homage to OP), minutes before your DFSee.

Strange, there were no follow-ups then. Let's see if that changes.
There's this mighty tree hanging off your DFSee comment.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#204904

On Fri, 1 Feb 2019 07:59:42 -0600
Richard Owlett <rowlett@cloud85.net> wrote:


> ... a major deficiency of the man page format --
>   [/begin_rant   almost total lack of examples /end_rant ;]
> 

That's what's expected of man pages. If you want examples, poke around
the Net for tutorials, and be prepared to find a wide range of quality.
A good place is often (though certainly not always) the documents on the
website associated with the application.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#204906

On Fri, Feb 01, 2019 at 06:06:18PM +0000, Joe wrote:
> On Fri, 1 Feb 2019 07:59:42 -0600
> Richard Owlett <rowlett@cloud85.net> wrote:
> 
> > ... a major deficiency of the man page format --
> >   [/begin_rant   almost total lack of examples /end_rant ;]
> 
> That's what's expected of man pages. If you want examples, poke around
> the Net for tutorials, and be prepared to find a wide range of quality.

I disagree.  Perhaps you've come to expect a lack of examples from the
man pages published by various GNU projects.  GNU developers prefer their
own texinfo format instead, so they often write only stub man pages.

A well-written man page includes an EXAMPLES section, unless the command
being documented is so trivial that none is required (e.g. true(1)).

The lack of examples is not a "deficiency of the format".  It is a
deficiency of that particular page, written by that particular author.

[toc] | [prev] | [next] | [standalone]

#204908

Greg Wooledge wrote: 
> On Fri, Feb 01, 2019 at 06:06:18PM +0000, Joe wrote:
> > On Fri, 1 Feb 2019 07:59:42 -0600
> > Richard Owlett <rowlett@cloud85.net> wrote:
> > 
> > > ... a major deficiency of the man page format --
> > >   [/begin_rant   almost total lack of examples /end_rant ;]
> > 
> > That's what's expected of man pages. If you want examples, poke around
> > the Net for tutorials, and be prepared to find a wide range of quality.
> 
> I disagree.  Perhaps you've come to expect a lack of examples from the
> man pages published by various GNU projects.  GNU developers prefer their
> own texinfo format instead, so they often write only stub man pages.
> 
> A well-written man page includes an EXAMPLES section, unless the command
> being documented is so trivial that none is required (e.g. true(1)).

... or the command is so complex that it refers you to other man
pages:

procmailex

perlfaq and perlfaq1-9

-dsr-

[toc] | [prev] | [next] | [standalone]

#204913

On Fri 01 Feb 2019 at 13:10:19 (-0500), Greg Wooledge wrote:
> On Fri, Feb 01, 2019 at 06:06:18PM +0000, Joe wrote:
> > On Fri, 1 Feb 2019 07:59:42 -0600 Richard Owlett <rowlett@cloud85.net> wrote:
> > 
> > > ... a major deficiency of the man page format --
> > >   [/begin_rant   almost total lack of examples /end_rant ;]
> > 
> > That's what's expected of man pages. If you want examples, poke around
> > the Net for tutorials, and be prepared to find a wide range of quality.
> 
> I disagree.  Perhaps you've come to expect a lack of examples from the
> man pages published by various GNU projects.  GNU developers prefer their
> own texinfo format instead, so they often write only stub man pages.
> 
> A well-written man page includes an EXAMPLES section, unless the command
> being documented is so trivial that none is required (e.g. true(1)).
> 
> The lack of examples is not a "deficiency of the format".  It is a
> deficiency of that particular page, written by that particular author.

Well, I've just given my opinion elsewhere. But it would be an
interesting challenge to write an example of a man page EXAMPLE
for that particular page, beyond the example that is given there.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#204805

+1

On 1/29/19 7:22 AM, Richard Owlett wrote:
> Gparted displays the desired data in the GUI, but I see no way to get 
> that information as a text stream. I need a text file

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web