'count' command

I have implementation of wc in java. It works fast (about 90% of original wc performance). I think it's possible to port it for jnode. If required, i can send it.

That will be great!

Here it is. Please note, that it is not JNode shell command, it's standalone java application.

This source was written one or two years ago.. it's work, but i saw that it possible has bug for option -L (same option in wc that shows length of longest line). Other options works fine.

Hi,

In file attachments you can found a new version.

*) Fix world count (bug)
*) Add multi file support + pipe support
*) Integrate on Jnode

Yves

I checked this out, nice work.

Commited.

I noticed some issues with the code:

1. The names of the member fields of WcCommand should be camel case, not capitalized. Doesn't checkstyle pick this up?
2. The 'execute' method should not catch Exception and print a stacktrace; see the JNode DOs and DON'Ts page for an explanation.
3. Don't put line breaks into Syntax and Argument description strings. The help system is responsible for adding line breaks at the appropriate point. (Aside: ideally a command should not make any assumptions about how wide the user's console is, though this is hard to achieve in practice.)
4. Don't use '\n\r' or '\r\n' in a JNode command's message strings. The JNode is end-of-line sequence is '\n'. (Aside: if you are trying to make your code portable you shouldn't use hardwired '\n' either.)
5. IMO, don't let your IDE add those stupid "non-Javadoc" comments. Any decent Java IDE can show you the Javadoc of whatever method your code implements / overrides. So those comments serve no useful purpose, and just take up space.

1) I dont think checkstyle really can pick that up. After all it is normal for many static final names to do. I actually meant to change those before i commited, i'll take care of that.

2) nod, though for new commands, what i would like to adopt is a standard --debug flag. What i have been doing is putting a static source level DEBUG and setting an instance boolean debug to DEBUG || Debug.isSet(). At least until a command is mostly stable. This way you can have a debug(String) method to dump debug statements on stderr or conditionally print stack traces. Although the logger is the proper solution, commands aren't so complex to need a permanent solution.

3 & 4) I cleaned up the string. As i mentioned in the forum post on the subject, and i'll reitterate here, can we please not embed strings into the middle of class methods. Pull them out and replace them with private static final String at the top of the class. This makes it easy to do mass grep searches on the code base to extrapolate text strings into a localization framework.

5) i like vim

Re 1). The Sun and JNode rules are:

• static final names are "ALL_CAPS",
• type names are "CapitalizedByWord"
• other member names, parameter names and locals are "camelCasedByWord", and
• package names are "all.lowercased".

It would be a good thing if the checkstyle rules enforced this, where possible.

Admittedly, I've been in the habit of using ALL_CAPS for non-static final Arguments as well. It is a carry over from when Argument instances were declared as static final ... I should probably stop doing it.

Re 2). I was too terse. The DO's and DON'Ts page advises that the preferred behaviour for commands is to allow any unexpected exceptions to propagate out of 'execute'. The shell will print a stacktrace or not, depending on the user's setting of "jnode.debug". If an exception is the result of a "user error", a command may (arguably should) catch it and produce a user-friendly error message with no stack trace.

Rationale: it is unrealistic to expect each and every command to implement a "--debug" flag to mean the same thing. You can bet that some commands won't implement the flag, some will send the stacktrace somewhere unexpected, some will cause "--debug" to do other things, and so on. Besides, letting the exceptions propagate is less work for command implementers.

Maybe I should expand the material in the D&D page to cover this.

Re: 5) Are you trolling for sympathy?

*) fix non-static case
*) fix main method
*) remove some javadoc
*) add some error msg

Yves

Looks better, pushed upstream.

If you think you are done with this Yves, you can mark this fixed, or do so when you think your done with it.

Refactored this into command/posix and added black-box tests.

Marking as fixed.

Can I request that you (someone) create the User Command page for 'wc' before (re-)closing this issue. Please use the source markup for one of existing command pages as a template, and try to conform to the same style and structure.

doc page is up

Automatically closed -- issue fixed for two weeks with no activity.