Another look at cat

Submitted by gchii on Fri, 05/01/2009 - 20:24.

A better cat command might support a -f (non-URI) option rather than a -u (URI) option. A URI follows a pattern and a machine can distinguish between a filename and a URI most of the time. When a filename looks like a URI, an explicit use of the -f option would help. Or, a filename that looks like a URI can be URI-encoded with the formal use of the file: scheme.

The equivalent of a cat command in another JVM-based programming language supports a mix for filenames and URIs, with default filename detection.

  cat('a.txt');
  cat('http://www.jnode.org/');

My favorite cat command in Java supports a mix of filenames and URIs. In fact, it always constructs a URI object for each argument.

  cat a.txt http://www.jnode.org/ c.txt

The URI mechanism supports an extension of recognized URIs through plug-ins. By adding the plug-in for reading Java resources, my favorite cat command supports the display of a Java resource.

cat x-resource:/mypackage/myapp/application.properties

After some thought, I belive that the purpose of cat is different from the purpose of wget. Both commands should be implemented with respect for modern network technologies.

‹ Working with other languages Isolate and System Resource ›

Well, the way i see it the

Submitted by cluster on Fri, 05/01/2009 - 21:56.

Well, the way i see it the underlying idea that you are proposing spans much further than cat. You are right that cat and wget have different purposes, but lets expand your idea for a second.

Supposing that cat were to work the way you describe, what about commands like bzip2, tar, grep, tail, and just about any other command that is designed to be inserted into a pipeline and work with a stream of information. It would be a maintainers nightmare to have to maintain network aware code into all of these. Especially when you dont _need_ to make these applications network aware. The cat example i believe is more of an edge case. For example, would it not be simpler to do the following:

cat [url]
wget [url] -O -
---
cat [file] [url] [file]
wget [url] -O - | cat [file] - [file]

Its not that i'm against your idea at all. I actually do like the idea. I think we just need to be careful about _where_ and _how_ we implement this. The discussion was brought up before, and one topic that was brought up was to abstract this away from the commands through a pseudo file system. In this way the command still uses a 'File' and File{Input,Output}Stream, but the underlying file system layer does the dirty work of dealing with the network issues. In this way, we can bring your proposal to just about 'every' command that naturally deals with files, including commands/applications that are hard-coded (non jnode commands) to use files.

Of course, as has been mentioned before, something like this definetly is _not_ on the priority list, as jnode is in much greater need of real file systems that are fast/secure/stable.

Might i recommend that we revisit this when jnode has more of its core features that we _need_ stabilized?

Make a note of it

Submitted by gchii on Sat, 05/02/2009 - 01:40.

Thanks for your thoughful reply. And yes, my favorite head and tail commands are network enabled. How is this possible?

Already, the JNode Command API seems to strongly recommend the use of a FileArgument to encapsulate a file argument. Network enable the FileArgument class and you're done. In other words, an advanced FileArgument class (network-aware, virtual file system-aware) might have methods to actually open a file, such as openInputStream() and openOutputStream(). An advanced FileArgument class might use a URI to open a stream.

Actually, I would suggest something like this: InputFileArgument and OutputFileArgument extends FileArgument.

Let's make a note of using the FileArgument class for giving advanced features to all JNode commands.