[Top][All Lists]

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

bug#13120: Not quite a bug, but ...

From: Pádraig Brady
Subject: bug#13120: Not quite a bug, but ...
Date: Sun, 09 Dec 2012 12:34:44 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 12/07/2012 08:23 PM, Todd Shandelman wrote:
Hi,  address@hidden  -

Not quite a bug, but why does the same option, essentially, have two very
different names in the 'expand' and 'unexpand'  utilities?

This is confusing and hampers convenient usage.

I am referring to* --initial* in the one case and* --first-only* in the

See below.

Or what am I missing?

Yes that is inconsistent.
Interestingly the POSIX defined expand and unexpand are inconsistent
in relation to this to start with.

unexpand only processes leading blanks by default, but
expand processes all blanks by default.

So unexpand needs the -a option to process all blanks,
and expand needs the -i, --initial option to process only leading blanks.

Given the above you might think that the --first-only option to unexpand
is redundant.  However -a is implied by -t (as per POSIX), therefore
to really limit to initial blanks, you need this option.

So as for naming.  I agree that --first-only is inconsistent.
It's also a bit ambiguous. Does it mean only the first tab is written,
or all leading blanks are processed.  Now deprecating --first-only
for the more consistent --initial has some cost.  For example
it would break part of my FSlint program:
Also, I see busybox copied --first-only into its unexpand implementation.
But I guess to be forward looking --first-only should be deprecated
in favor of --initial?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]