Please remove commands without dashes

[Reuben Thomas]

Another dragging annoyance with recent wajig has been the introduction
of commands without dashes. I can no longer remember why this was
done; I thought it was to do with bash completion, but I've just done
an experiment and bash completion has no trouble with commands
containing dashes.

Since other commands seem to use dashes (apt-get dist-upgrade), can
wajig please only use dashes? If there is a really good reason to keep
the dashless variants, can the dashed variant please be the one that
is auto-completed, and can the list of valid commands please NOT
contain the undashed variants, as this only makes the list of valid
commands far too long to be useful?

Sorry to be demanding yet another return to the old ways, but I've
been living with this change for many months now, and it's an
unmitigated failure for me: it confuses my fingers, confuses my brain
working with older wajigs on machines that aren't mine, looks ugly,
and makes the error message for "wajig foo" unreadable.

I am quite prepared to help with a patch for this!

--
http://rrt.sc3d.org

[Tshepang Lekhonkhobe]

On 18/07/2012 01:33, Reuben Thomas wrote:
> Another dragging annoyance with recent wajig has been the introduction
> of commands without dashes. I can no longer remember why this was
> done; I thought it was to do with bash completion, but I've just done
> an experiment and bash completion has no trouble with commands
> containing dashes.

You can have a look at debian/changelog for the reasoning.

> Since other commands seem to use dashes (apt-get dist-upgrade), can
> wajig please only use dashes? If there is a really good reason to keep
> the dashless variants, can the dashed variant please be the one that
> is auto-completed, and can the list of valid commands please NOT
> contain the undashed variants, as this only makes the list of valid
> commands far too long to be useful?
>
> Sorry to be demanding yet another return to the old ways, but I've
> been living with this change for many months now, and it's an
> unmitigated failure for me: it confuses my fingers, confuses my brain
> working with older wajigs on machines that aren't mine, looks ugly,
> and makes the error message for "wajig foo" unreadable.

Note that the use of dashes was very inconsistent, so you will end up
breaking (Squeeze and Wheezy) scripts anyways if you went all-dashes.

Also, it's rather late in the release cycle to do changes like this, so
we will end up with inconsistently dashful wajig completion for Squeeze,
then consistently dashless wajig completion for Wheezy, then dashful
wajig for Wheezy+1. Not good.

> I am quite prepared to help with a patch for this!

Me appreciates.

[Reuben Thomas]

On 18 July 2012 12:40, Tshepang Lekhonkhobe <tshe...@gmail.com> wrote:
>
> You can have a look at debian/changelog for the reasoning.

I can only find a reference to the restoration of dash-separation in 2.5.

> Note that the use of dashes was very inconsistent, so you will end up
> breaking (Squeeze and Wheezy) scripts anyways if you went all-dashes.

As I said, I'm not insisting on the removal of non-dashed commands.

> Also, it's rather late in the release cycle to do changes like this, so we
> will end up with inconsistently dashful wajig completion for Squeeze, then
> consistently dashless wajig completion for Wheezy, then dashful wajig for
> Wheezy+1. Not good.

Assuming you agree about completion, surely a change purely to
completion ought to be able to get in as a bug-fix?

--
http://rrt.sc3d.org

[Reuben Thomas]

On 18 July 2012 12:48, Reuben Thomas <r...@sc3d.org> wrote:
> On 18 July 2012 12:40, Tshepang Lekhonkhobe <tshe...@gmail.com> wrote:
>>
>> You can have a look at debian/changelog for the reasoning.
>
> I can only find a reference to the restoration of dash-separation in 2.5.
>
>> Note that the use of dashes was very inconsistent, so you will end up
>> breaking (Squeeze and Wheezy) scripts anyways if you went all-dashes.
>
> As I said, I'm not insisting on the removal of non-dashed commands.

To amplify: the most important thing is to be the same as the
underlying command.

--
http://rrt.sc3d.org

[Reuben Thomas]

On 18 July 2012 12:40, Tshepang Lekhonkhobe <tshe...@gmail.com> wrote:
>

>> I am quite prepared to help with a patch for this!
>
> Me appreciates.

So, concentrating on wheezy, I've just prepared a patch for
bash-completion. It aims to work as follows:

1. Where a wajig command is just a pass-through to another command
(e.g. apt-get), it should be spelled the same way.

2. Where a wajig command existed in an earlier version, it should be
spelled the same way. (I used 2.2, which I believe was the last
version before all the changes.)

3. Otherwise, use common sense, preferring dashes to separate words.

My patch uses the same line breaks for the two copies of the block of
commands, making it much easier to see that they're the same, and to
generate one semi-automatically from the other.

If we can agree the principles above, and agree that my patch
satisfies them, then I think you should be able to get a bug-fix patch
(for bash-completion only) into wheezy.

After that, we can think about changing wajig so that only one form of
each command is accepted (this seems reasonable where we have *not*
changed historical names), and in particular so that the command-line
help is more readable.

After *that*, we can think about where it might be desirable in the
long term to make command naming more consistent.

--
http://rrt.sc3d.org

[Tshepang Lekhonkhobe]

On 18/07/2012 13:48, Reuben Thomas wrote:
>> Note that the use of dashes was very inconsistent, so you will end up
>> breaking (Squeeze and Wheezy) scripts anyways if you went all-dashes.
>
> As I said, I'm not insisting on the removal of non-dashed commands.

okay

>> Also, it's rather late in the release cycle to do changes like this, so we
>> will end up with inconsistently dashful wajig completion for Squeeze, then
>> consistently dashless wajig completion for Wheezy, then dashful wajig for
>> Wheezy+1. Not good.
>
> Assuming you agree about completion, surely a change purely to
> completion ought to be able to get in as a bug-fix?

I don't think so (but you can ask anyone on the release team to make
sure). It would also be nice if other people agreed with you that this
is a worthy change.

And as regards your motivation to the release team, what bug does it
actually fix? You can check if it matches any of this criteria [1].
Current way of working is pretty much fine to me (nothing is broken). It
just so happens you prefer something else.

PS: I really hope you should have brought this up before Debian froze.

[1]: http://release.debian.org/wheezy/freeze_policy.html

[Reuben Thomas]

On 18 July 2012 13:31, Tshepang Lekhonkhobe <tshe...@gmail.com> wrote:
>>
>> Assuming you agree about completion, surely a change purely to
>> completion ought to be able to get in as a bug-fix?
>
>
> I don't think so (but you can ask anyone on the release team to make sure).
> It would also be nice if other people agreed with you that this is a worthy
> change.

It's arguably under 4 & 6. It's a minor fix, not to the code of the
package's program itself, which corrects an inconsistency with
previous releases, introduced during the current release cycle (i.e.
no bug about it in the BTS). (That's how I see it; you see it as a
feature that was changed and then reverted, but I'm thinking more how
to "market" it to whoever would approve pushing it during the freeze.)
Pushing it now will avoid things changing one way Squeeze→Wheezy and
another Wheezy→Wheezy+1.

> PS: I really hope you should have brought this up before Debian froze.

Unfortunately, I don't use Debian any more, so I don't pay so much
attention to its rhythms. The consequences of such an error to Ubuntu
are less serious (although it's still annoying when something bad is
baked into a release, especially an LTS release).

At the end of the day, though, I'm happy to keep running wajig from hg
for a bit, so the most important thing is the fix, not which release
it gets into. In the medium term all Debian releases are obsolete!

--
http://rrt.sc3d.org

[Tshepang Lekhonkhobe]

On 18/07/2012 14:03, Reuben Thomas wrote:
> On 18 July 2012 12:40, Tshepang Lekhonkhobe<tshe...@gmail.com> wrote:
>>
>>> I am quite prepared to help with a patch for this!
>>
>> Me appreciates.
>
> So, concentrating on wheezy, I've just prepared a patch for
> bash-completion. It aims to work as follows:
>
> 1. Where a wajig command is just a pass-through to another command
> (e.g. apt-get), it should be spelled the same way.
>
> 2. Where a wajig command existed in an earlier version, it should be
> spelled the same way. (I used 2.2, which I believe was the last
> version before all the changes.)
>
> 3. Otherwise, use common sense, preferring dashes to separate words.
>
> My patch uses the same line breaks for the two copies of the block of
> commands, making it much easier to see that they're the same, and to
> generate one semi-automatically from the other.
>
> If we can agree the principles above, and agree that my patch
> satisfies them, then I think you should be able to get a bug-fix patch
> (for bash-completion only) into wheezy.

See my other mail.

> After that, we can think about changing wajig so that only one form of
> each command is accepted (this seems reasonable where we have *not*
> changed historical names), and in particular so that the command-line
> help is more readable.

I would really rather break old scripts, than be held back from
improving. It's not a popular opinion I know, but why carry the baggage?
If it was tar or sed, I'd understand. But it's wajig, which not too many
people depend on. That is, I agree with what you say in above paragraph,
all but the stuff in brackets.

> After *that*, we can think about where it might be desirable in the
> long term to make command naming more consistent.

I like dashless (simple consistency and less typing), but if others
don't (like you do), I'll be happy to push your patch.

[Reuben Thomas]

On 18 July 2012 13:45, Tshepang Lekhonkhobe <tshe...@gmail.com> wrote:
>
> I would really rather break old scripts, than be held back from improving.

I agree to an extent: in particular, I use wajig exclusively from the
command line, and I imagine most users do too.

However, the previous round of name-changing was insufficiently
carefully thought through, so I believe the best way to proceed is to
back it out and start again from clearly-defined principles.

> I like dashless (simple consistency and less typing), but if others don't
> (like you do), I'll be happy to push your patch.

Dashes make it more legible, and TAB-completion saves more keystrokes
than dashes lose. Also, I don't know about you, but I run my most
frequent wajig commands by history search:

W A Alt-P [Alt-P...]

(I have:

# FIXME: \M- doesn't work in readline 5.2
"\ep": history-search-backward
"\en": history-search-forward

in my .inputrc. For others,

Ctrl-R W A J I G [Ctrl-R...] would have a similar effect.)

I would argue that if you really want to save more keystrokes without
losing legibility, then search for more single-word commands.

--
http://rrt.sc3d.org

[Tshepang Lekhonkhobe]

On 18/07/2012 14:42, Reuben Thomas wrote:
> On 18 July 2012 13:31, Tshepang Lekhonkhobe<tshe...@gmail.com> wrote:
>>>
>>> Assuming you agree about completion, surely a change purely to
>>> completion ought to be able to get in as a bug-fix?
>>
>>
>> I don't think so (but you can ask anyone on the release team to make sure).
>> It would also be nice if other people agreed with you that this is a worthy
>> change.
>

> It's arguably under 4& 6. It's a minor fix, not to the code of the

> package's program itself, which corrects an inconsistency with
> previous releases, introduced during the current release cycle (i.e.
> no bug about it in the BTS). (That's how I see it; you see it as a
> feature that was changed and then reverted, but I'm thinking more how
> to "market" it to whoever would approve pushing it during the freeze.)
> Pushing it now will avoid things changing one way Squeeze→Wheezy and
> another Wheezy→Wheezy+1.

I dont see how 4 & 6 from that page[1] apply.
Anyways, the inconsistency doesn't break anything, since this is bash
completion after all. If it broke old command, it would be another
issue. Why do you care so much anyways? It's just bash completion, and
does not make anything ambiguous.

>> PS: I really hope you should have brought this up before Debian froze.
>
> Unfortunately, I don't use Debian any more, so I don't pay so much
> attention to its rhythms. The consequences of such an error to Ubuntu
> are less serious (although it's still annoying when something bad is
> baked into a release, especially an LTS release).

[offtopic] What do you use and why? I guess it's Ubuntu?


[1]: http://release.debian.org/wheezy/freeze_policy.html

[Reuben Thomas]

On 18 July 2012 13:57, Tshepang Lekhonkhobe <tshe...@gmail.com> wrote:
>
> I dont see how 4 & 6 from that page[1] apply.
> Anyways, the inconsistency doesn't break anything, since this is bash
> completion after all.

It breaks users, which is more important than breaking software!

> Why do you care so much anyways?

Because I am losing lots of brain cycles from things not working
consistently. If this were not the case, I really would have better
things to do than push for this patch!

> [offtopic] What do you use and why? I guess it's Ubuntu?

Ubuntu, because the hardware support seems better, and I prefer the
regular release cycle.

--
http://rrt.sc3d.org

[Tshepang Lekhonkhobe]

On 18/07/2012 14:51, Reuben Thomas wrote:
> On 18 July 2012 13:45, Tshepang Lekhonkhobe<tshe...@gmail.com> wrote:
>>
>> I would really rather break old scripts, than be held back from improving.
>
> I agree to an extent: in particular, I use wajig exclusively from the
> command line, and I imagine most users do too.
>
> However, the previous round of name-changing was insufficiently
> carefully thought through, so I believe the best way to proceed is to
> back it out and start again from clearly-defined principles.

I am not sure. I only reverted the changes because the complaints were
quite loud, and I don't like it when people are not happy, especially
when it's my fault.

>> I like dashless (simple consistency and less typing), but if others don't
>> (like you do), I'll be happy to push your patch.
>
> Dashes make it more legible, and TAB-completion saves more keystrokes
> than dashes lose.

Agreed.

> Also, I don't know about you, but I run my most
> frequent wajig commands by history search:
>
> W A Alt-P [Alt-P...]
>
> (I have:
>
> # FIXME: \M- doesn't work in readline 5.2
> "\ep": history-search-backward
> "\en": history-search-forward
>
> in my .inputrc. For others,
>
> Ctrl-R W A J I G [Ctrl-R...] would have a similar effect.)
>
> I would argue that if you really want to save more keystrokes without
> losing legibility, then search for more single-word commands.

Advanced Unix skills there. I don't go that far. I just use a heck of a
lot of aliases, e.g.:

$ alias ii
alias ii='wajig install --noauth'
$ alias rr
alias rr='wajig remove --noauth'

[Karl Schmidt]

On 07/18/2012 07:45 AM, Tshepang Lekhonkhobe wrote:
>
> I would really rather break old scripts,

Grump.. Hiss .. heavy sigh.

> than be held back from
> improving. It's not a popular opinion I know, but why carry the baggage?

So the scripts keep working! At the very least such changes should go through a depreciated time of
one Debian release. This is usually done via spitting out a deprecated warning in a log somewhere..

--
--------------------------------------------------------------------------------
Karl Schmidt EMail Ka...@xtronics.com
Transtronics, Inc. WEB http://secure.transtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434

Any cat would tell you that you can only wash one paw at a time;
while we try to do everything at once. -kps

--------------------------------------------------------------------------------

[Tshepang Lekhonkhobe]

On 18/07/2012 23:33, Karl Schmidt wrote:
> On 07/18/2012 07:45 AM, Tshepang Lekhonkhobe wrote:
>>
>> I would really rather break old scripts,
>
> Grump.. Hiss .. heavy sigh.
>
>> than be held back from
>> improving. It's not a popular opinion I know, but why carry the baggage?
>
> So the scripts keep working! At the very least such changes should go
> through a depreciated time of one Debian release. This is usually done
> via spitting out a deprecated warning in a log somewhere..

I think the pain is often worth it (e.g. Python 3 broke compatibility
with Python 2), so long as the reason is good enough. Of course there
will be disagreement on what 'good enough' is.

As an aside, I think 'apt-get' should really change some stuff to be
more intuitive. For example, no new user would guess correctly what
UPDATE subcommand does; a better alternative would be UPDATE-CACHE or
UPDATE-INDEX or UPDATE-PACKAGE-INDEX or...
Same thing applies to UPGRADE. It does not do a full upgrade for
example... aptitude was smart to introduce SAFE-UPGRADE and
FULL-UPGRADE. Thousands of scripts would break if such changes were made
of course, but I think it's worth it.

I agree with your suggestion of deprecating stuff first though, since
very few people read the changelog before/after upgrading their packages.

[Reuben Thomas]

On 18 July 2012 14:05, Tshepang Lekhonkhobe <tshe...@gmail.com> wrote:

On 18/07/2012 14:51, Reuben Thomas wrote:

On 18 July 2012 13:45, Tshepang Lekhonkhobe<tshe...@gmail.com>  wrote:

I would really rather break old scripts, than be held back from improving.

I agree to an extent: in particular, I use wajig exclusively from the
command line, and I imagine most users do too.

However, the previous round of name-changing was insufficiently
carefully thought through, so I believe the best way to proceed is to
back it out and start again from clearly-defined principles.

I am not sure. I only reverted the changes because the complaints were quite loud, and I don't like it when people are not happy, especially when it's my fault.

I like dashless (simple consistency and less typing), but if others don't
(like you do), I'll be happy to push your patch.

Dashes make it more legible, and TAB-completion saves more keystrokes
than dashes lose.

Agreed.

Now that Wheezy is released, how about this patch? (It hasn't changed since I sent it.)