From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 00/14] Enhanced df - followup
Date: Wed, 30 Apr 2014 17:25:32 +0000 (UTC) [thread overview]
Message-ID: <pan$c60c5$f81c6a24$3cc19892$c799d54a@cox.net> (raw)
In-Reply-To: 20140430130134.GL5988@twin.jikos.cz
David Sterba posted on Wed, 30 Apr 2014 15:01:34 +0200 as excerpted:
> On Tue, Apr 29, 2014 at 05:10:31PM +0000, Duncan wrote:
>> To users familiar with Unix/POSIX/Linux CLI, "usage" (as --usage) is
>> most often seen as a rather less common and generally briefer form of
>> --help
>
> I did a quick check of ~20 randomly chosen binaries in /usr/bin and none
> of them had --usage among options, unlike --help.
Yes, it wasn't nearly as common as I had the impression it was (I would
have guessed about a third coverage, now it looks like a tenth at best),
when I went to check, as well. But I did find some.
> Though adding a command alias is trivial, I'd rather not do that right
> now. Let's see if we can live with 'btrfs fi us'. I worked for me during
> developing the patch series.
Actually, that suggests a nice, short, non-conflicting alternative,
"use". =:^)
"Use" doesn't conflict with other (not-so) common usage like "usage",
doesn't have the hard to type implications of a compound device_usage or
the like, either, and is nice and short on its own. =:^)
Regardless, I don't feel particularly strongly about it, and as both you
and I found, the other use of "usage" is less common than I had at first
thought. It might be slightly confusing here, that's all. As others
don't seem to have that problem I'm now happy either way and the existing
patches use usage, so leaving them as they are is fine by me. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2014-04-30 17:25 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 15:56 [PATCH 00/14] Enhanced df - followup David Sterba
2014-04-29 15:57 ` [PATCH 01/14] btrfs-progs: read global reserve size from space infos David Sterba
2014-04-29 15:57 ` [PATCH 02/14] btrfs-progs: add original 'df' and rename 'disk_usage' to 'usage' David Sterba
2014-04-29 15:58 ` [PATCH 03/14] btrfs-progs: move device usage to cmds-device, more cleanups David Sterba
2014-04-29 15:58 ` [PATCH 04/14] btrfs-progs: check if we can't get info from ioctls due to permissions David Sterba
2014-04-29 16:01 ` [PATCH 05/14] btrfs-progs: zero out structures before calling ioctl David Sterba
2014-04-29 16:02 ` [PATCH 06/14] btrfs-progs: print B for bytes David Sterba
2014-04-29 16:02 ` [PATCH 07/14] btrfs-progs: Print more info about device sizes David Sterba
2014-04-29 19:23 ` Mike Fleetwood
2014-04-30 11:39 ` Goffredo Baroncelli
2014-04-30 12:11 ` David Sterba
2014-04-30 13:31 ` Frank Kingswood
2014-04-30 13:37 ` David Taylor
2014-04-30 17:38 ` Goffredo Baroncelli
2014-05-02 13:13 ` David Sterba
2014-05-02 13:15 ` David Sterba
2014-05-14 18:00 ` David Sterba
2014-04-30 11:52 ` David Sterba
2014-04-29 16:02 ` [PATCH 08/14] btrfs-progs: compare unallocated space against the correct value David Sterba
2014-04-29 16:02 ` [PATCH 09/14] btrfs-progs: add section of overall filesystem usage David Sterba
2014-04-29 16:02 ` [PATCH 10/14] btrfs-progs: cleanup filesystem/device usage code David Sterba
2014-04-29 16:02 ` [PATCH 11/14] btrfs-progs: extend pretty printers with unit mode David Sterba
2014-04-29 16:02 ` [PATCH 12/14] btrfs-progs: replace df_pretty_sizes with pretty_size_mode David Sterba
2014-04-29 16:02 ` [PATCH 13/14] btrfs-progs: clean up return codes and paths David Sterba
2014-04-29 16:03 ` [PATCH 14/14] btrfs-progs: move global reserve to overall summary David Sterba
2014-04-29 17:10 ` [PATCH 00/14] Enhanced df - followup Duncan
2014-04-29 17:17 ` Marc MERLIN
2014-04-29 17:33 ` Holger Hoffstätte
2014-04-30 0:42 ` Duncan
2014-04-30 8:15 ` Martin Steigerwald
2014-04-30 12:37 ` David Sterba
2014-04-30 13:01 ` David Sterba
2014-04-30 17:25 ` Duncan [this message]
2014-04-29 19:14 ` Mike Fleetwood
2014-04-30 12:22 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$c60c5$f81c6a24$3cc19892$c799d54a@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).