JMichelle (Java Midori Shell)
Development (Japanese only)

Return to JMichelle page.

This page was last updated on 10 Oct 2000 by Midori IGA

JMichelle のプロジェクト運用的なこと,,,

プロジェクト運用的なこと

  1. プロジェクト運用上のウェブページ
    現在、開発は http://sourceforge.net/projects/jmichelle/ を中心に行っております。
    ミラーとして 従来のページ http://www01.u-page.so-net.ne.jp/db3/midori/JMichelle.html も残しています。
  2. ソースコードなどの投稿方法
    現時点でソースコードに関しては SourceForge (http://sourceforge.net/projects/jmichelle/) 内にCVSリポジトリを展開済みです。(HTMLは近日中に展開予定)
    匿名によるCVS接続方法は下記です (どなたでもCVS匿名接続が可能です) CVSサーバを管理・運用する能力は 作者たちにはあまりありませんが、前向きに取り組んでおります。CVS熟練者を募集中(!!!)。文字コードに関しては 後述の記載をご覧下さい。ちなみに CVSは http://www.cvshome.org/ から取得可能です。Windows版は ftp://ftp.cvshome.org/pub/cvs-1.10.5/windows/cvs.exe から取得可能です。環境設定の例を下記に例示します
    Windowsの際の環境設定例
    1. CVS.EXEは \WINDOWS\SYSTEM (2000/NTの場合は \WINNT\SYSTEM32)にコピー格納するのが手っ取り早いです
    2. CVSで利用するドライブを C: ドライブと仮定します。(CVS実装の都合上、単一ドライブでの作業が前提になります)
      C:\HOMEディレクトリを作成してください
    3. 2.環境変数を 下記のように設定下さい。
      • SET HOME=\home
      • SET HOMEDRIVE=c:
      • SET HOMEPATH=\home

JMichelle メーリングリスト

メーリングリストを jmichelle@b6.easyml.com で運用しています。(2000/09/21 運用開始 :-)
現在は 開発者向けも利用者向けも区別なく メーリングリストは1つしかありません。(もちろん 状況に合わせて運用方法は 逐次改良や変更など加えていきます。)

もちろん JMichelleメーリングリストには JMichelleに関わる内容のみポストしてくださいね。
ML登録などの操作が どうしてもうまくいかない場合は mailto:midori.iga@nifty.ne.jp までご一報ください。

文字コード

ソースコードおよびドキュメントに関しては、英語圏への配慮も含め、基本的に半角英数字のみ(正確には 7bit範囲)になるような運用を考えております。といっても 下記のような手法により ごく自然に日本語が利用可能になるように考慮されています。(特に 7bit化Unicodeエンコーディング運用は優れた運用であると自負しております)

分岐開発
そうではなく JMichelle を 自作シェル開発の際の素材(スタート地点)として利用される場合もあるでしょう。JMichelle は GNU GPL ライセンスを採用していますので、GNU GPLライセンスに従った範囲の中で 自由に分岐(フォーク) し、変更・配布など行うことができます。どうぞご自由に。また JMichelle をフォークしたプロダクトの情報などありましたら ぜひお寄せください。当ページにてもリンクを張らせていただきます。もちろん 現状の JMichelle に無い より優れた機能などありましたら、当方的にも喜んで JMichelle に取り込ませていただきます。

JMichelle の開発に参加されようとする方へ,,,

JMichelle開発当初の私の思い

  1. OS環境やOSのバージョンに左右されない マルチプラットホームをバイナリレベルで実現することができるようなユーザインタフェースとしてのシェルを入手したく、それじゃ自作しようということで開発を初めました。
  2. 私がシェルを開発するのだから、もちろんJAVA言語を採用しました。JAVA言語はマルチプラットホームなシェルプログラムをバイナリレベルで実現するのにふさわしいのです。
  3. 一方 JAVA言語の特性として、1プロセスあたりのメモリ消費量や起動時のCPU消費量は大変多いです。逆に マルチスレッドは非常に記述しやすいです。
    この特性を鑑み 基本的には 1プロセス内で複数のシェルやコマンドのインスタンスを生成するようにデザインしました。これにより 多量のコマンドをパイプライン処理したとしても プロセスは1個になるので結果的に効率的に動作するシェルを なおかつシンプルにデザインすることが出来ます。1プロセス内でインプロセスコマンド起動を行うことにより HotSpotやJIT環境下でも快適な動作速度が
    得られるものと期待できます。
  4. やっとシェルが得られても それが重いソフトになっていたら面白くありません。
    そのため JMichelleは コマンドラインベースで標準入出力主体なJavaアプリケーションとして開発しています。これにより Javaとしては画期的な軽快さを得ることが出来ます。きびきびと起動できます。もちろん この実装方針が理由で起こる欠点があります。困ったことに Java言語は 標準入力を行単位でしか利用できません。(BufferedInputStreamであるためです) しかし この欠点は前向きに取り組み 行単位での入力時点でのコマンド名自動補完機能や低機能なtelnetクライアント環境での利用などが期待できます。
    (変なテクニックを用いた回避策も無いことはないのですが、これは避けて標準的な手法を採用しています)
  5. せっかく今から書き下ろすのだから、URI (RFC 2396) を主体として作成しています。
    URIベースで それら様々なリソースを統合されたディレクトリツリーに統合することを目標にしています。現時点で既に ローカルファイルシステムとftpクライアントは統合済みです。遠い将来の目標として、http: や nfs: などの統合や sql:, pop3: なども構想にはあります。Factory.getInstance()によるファクトリデザインパターン(?) を利用しています。
  6. 遠い遠い未来の構想として、JMichelleをベースに SwingベースのファイルマネージャなGUIを開発することを考えています。それも JMichelleには手を入れずにラッパーとしてのGUIを です。そのようなことなので、現在のコマンドラインから1行づつ取り込む構造は なるべくそのまま手を入れず これに沿った形で開発して欲しいのです。これは Javaの標準入力の行単位な特性を有効活用しようとするものです。
    ただし これはあくまでも遠い未来の話しです。しかし GUI対応があると より多くの利用者が利用できることも確かです。また GUIに発展させると、シェルスクリプティングに対応したGUIなファイルマネージャソフトを得るという画期的な成果物をも期待できます。
    (あまり夢を語ると かえって混乱する恐れもありますよね。ちょっと反省)

JMichelle-ML上でのWatanabeさんからの突っ込みへの対応として、、、

  1. 基本形が コンソール
  2. 発展系その1 として JTextArea
  3. 発展系その2 として Swingばりばり

が、私の希望ではあります。
つまり どうしても私はコンソールは好きだけれど (これは私の都合 :-) 、それ以外のUIが ある一定のInterfaceを継承さへしていれば 切り替え可能なようなのが 理想型です。そして、コンソール側に新機能を実装すれば、例えば Swingのファイルマネージャにもその新機能がメニューなどの形で『自動的』に増える、、、みたいにです。
さしあたり機能追加しつつ 何が共通部分となり得るかを 模索中だったです。

JMichelle開発にあたって私の提案

  1. シェルの実装で 異なる2つのアイデアが出てきて いずれも捨てがたく悩ましいような事が発生した時には原則的に LINUXや/bin/bash に近い方を採用するようにしたいと思うのですが どうでしょうか？
    目標: 当面 LINUX上の bash を目標のシェルと位置づけています。さらにJMichelleは JavaベースなGPLオペレーティングシステムが登場した際の標準シェルを目指しています (笑)
  2. コマンドは極力内部に取り込むように考えています。
    現在 grep などのコマンドが実装されていますが、これらは全て内部に取り込んでしまっています。これによりシェルのモジュールサイズの増加を懸念される方もいらっしゃるでしょうが、結果的に動作は速くなります。また 後述の標準入出力のJMichelle化やSystem.exitの利用禁止などの理由からも必要なことです。その形態は LINUXディストリビューションの運用方式を模倣するイメージをしていただければと思います。
  3. GPL, LGPLな既存ソフトを発見した場合、それがコマンドラインベースだったら 積極的に取り込みたく思っています。実際 既に grep は 丁度 LGPLなソフトとして公開されていましたので そのまま取り込みました。
    (gnu.regexpのメンバーには 利用させていただく旨 メールは送信済みです)
    GPL, LGPL ではないソフトの取り込みは 避けたいと思っています。それが魅力的であってもです。、、、ちなみに 私は JTar という JavaでGPLなtarアーカイバを発見しまして、これは行けると思ったのですが、なんだかうまく行かず断念しました。まぁ、さしあたり私はコマンドを増やすことよりも ファイルコピー機能などに興味を持っています。
    (渡辺氏が何に興味を持っているかは不明)
  4. 私は UIとしてのシェルを主体として考えていたので、現在 シェルスクリプティング機能がありません。
    それ以前に パイプライン処理やリダイレクションが未実装だからシェルスクリプティングは作成できませんね。どなたか (おそらく 渡辺さん :-) がリダイレクションを実装された時点で シェルスクリプティングが開発可能な状況になるのではと、、、期待しています :-P

JMichelle-ML上でのWatanabeさんからの突っ込みへの対応として、、、
// Watanabeさん：おっと。　リダイレクションやパイプラインは不得手です。
// 　むしろ、いがぴょんの領域ではないかと・・・。　でも、興味のあるところなので、
// 　私がチャレンジしてみるのもいいかも。シェルの醍醐味のところですからね。
// スクリプトは考えていました。というよりも、バッチファイルみたいなものですが。
// MdShellCmd.def は autoexec.bat(.cshrc)になるべきではないかと。
// | alias wwwc C:\WWWC\WWWC.exe&

それ すごく良いです。いただき。
Aさんって 結構 UNIX知っているんじゃぁないですか。
(少なくとも私よりず〜っと)
また スクリプティングって Aさんの得意分野ですもんね。
なお、メサキ的感覚ですが、上の記載そのままだと、aliasコマンドがバックグラウンドで動作してしまう恐れが (爆笑)

技術的なこと

  1. 本体のシェルのカーネル部分以外に System.exit() がソースコードに混入しないようにしてください。
    というのも、ある1コマンド内で System.exit()を呼ぶと 全体が停止してしまいます。
  2. 正常系に関して、System.in, System.out, System.err を直接利用しないでください。代わりに MdShellEnv.getIn(), MdShellEnv.getOut(), MdShellEnv.getErr() を利用してください。これにより (現在は未実装ですが) パイプライン処理が可能になることが期待できます。
    逆に デバッグやトレース用としては、System.out System.err を直接利用するようしてください。
  3. カレントディレクトリを移動しての子プロセス実行について、以前はJavaのAPIの中だけでは実現できないと思っていたのですが、それは誤りでして、JavaAPIのみで実装できました。(thanx to WATANABE)
ちょうど今 作業していること
修正履歴

Return to JMichelle page.