Unexpected behavior of 'alias' command ... is this a bug?

Project:JNode Core
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:by design
Description

I was looking at the DefaultAliasManager class to see whether the 'add' method had "add new or update existing" behavior and I spotted something unexpected (to me!). The 'add' method takes an alias name and a class name as arguments. Before creating the alias, it tries to lookup the supplied class name as an alias. If this succeeds, it uses the result of the lookup instead of the supplied class name.

It looks like someone has tried to support "alias of an alias" on the cheap. This approach works in some respects (e.g. alias loops are impossible), but not in others (e.g. "alias a Aye ; alias b a; alias a Bee" doesn't result cause 'b' to be an alias for 'Bee'). Personally, I think it would be better to allow JNode aliases to point to other aliases, but that's debatable.

However, if we do keep the current DefaultAliasManager behavior, this ought to be properly documented in the javadoc for the AliasManager interface (!), the 'alias' command help and the 'alias' manual page.

How should we proceed?

#1

Submitted by lsantha on Fri, 03/28/2008 - 20:43.
Status:active» by design

If you make an alias point to an other alias then you will need extra things to see if something is an alias or not. The current approach clearly separates the alias from the aliased. The good in this is that looking up an alias is efficent as it should be. I would prefere keeping the lookup as fast as possible and making the addition of a new alias more expensive. Just think about the frequency of alias lookups versus updates. The 'problem' with the current approach that you pointed out could be fixed by replacing all occurences of the old aliased with the new aliased in every existing eligible alias binding. However I'm not sure if that problem is really a problem. It looks to me like a delicate question and it depends on what the user wants to do. So this looks like an open topic for me and it might be just good enough as it is.

#2

Submitted by Stephen Crawley on Sat, 03/29/2008 - 00:46.

OK. I've documented the existing behavior in the "alias" book page. I'll update the javadoc and close the issue.

FWIW, the Bjorne shell will eventually need an 'alias' mechanism that behaves like conventional shell aliases. If this is different to the native JNode shell alias mechanism, we will have to reconcile the two different meanings of the term 'alias'.

#3

Submitted by Stephen Crawley on Sat, 03/29/2008 - 11:56.

I've committed a fix for this. The javadoc has been updated. I have moved the clever alias mapping behavior from the DefaultAliasManager.add(...) method to the AliasCommand.execute(...) method. That way this behavior won't cause problems for other clients of the AliasManager API that might need aliases to behave in a more straight-forward fashion.

Marking this issue as 'by design'.