RFC666 日本語訳
0666 Specification of the Unified User-Level Protocol. M.A. Padlipsky. November 1974. (Format: TXT=49024 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Padlipsky Request for Comment: 666 26 November 1974 NIC: 31396
Padlipskyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 666 1974年11月26日NIC: 31396
Specification of the Unified User-Level Protocol
統一されたユーザレベルプロトコルの仕様
After many discussions of my RFC 451, I discovered that the "Unified User-Level Protocol" proposed therein had evolved into what had always been its underlying motivation, a common command language. There are several reasons why this latter approach satisfies the original goals of the UULP and goes beyond them into even more useful areas:
私のRFC451の多くの議論の後に、私は、そこに提案された「統一されたユーザレベルプロトコル」がいつも基本的な動機(一般的なコマンド言語)であったことに発展したと発見しました。 この後者のアプローチがUULPの元の目標を満たして、さらに役に立つ領域にそれらを越えるいくつかの理由があります:
1. User convenience. As evidenced by the good response to the common editor "neted", the Network Working Group has come to acknowledge the fact that the convenience of non-system programmer users of the Network must be served. Allowing users to invoke the same generic functions -- including "batch" jobs -- irrespective of which Server Host they happen to be using is surely a compelling initial justification for a common command language. Note that the concern with generic functions -- which "all" Servers do, one way or another -- is intended to emphasize the common command subset aspects of the language, rather than the "linguistic" elegance of it all. The attempt is to specify an easy way of getting many things done, not a complicated way of getting "everything" done.
1. ユーザの便宜。 "netedする"であった一般的なエディタへの良い応答で証明されるように、Network作業部会はNetworkの非システム・プログラマユーザの便利に役立たなければならないという事実を承認するようになりました。 たまたまどのServer Hostを使用しているかの如何にかかわらずユーザが同じジェネリック機能(「バッチ」仕事を含んでいる)を呼び出すのを許容するのは、確実に一般的なコマンド言語のための無視できない初期の正当化です。 ジェネリック機能に従った関心がそれのすべての「言語学」の優雅よりむしろ言語の一般的なコマンド部分集合局面を強調するつもりであることに注意してください。「all」のServersがいずれにしても機能をします。 試みは「すべて」を完了させる複雑な方法ではなく、多くのことを完了させる簡単な方法を指定することです。
2. "Resource sharing". Another area which is receiving attention in the NWG of late is that of "automatic" or program-driven invocation of resources on foreign systems. A common intermediate representation of some sort is clearly necessary to perform such functions if we are to avoid the old "n by m problem" of the Telnet Protocol -- in this case, n Hosts would otherwise have to keep track of m command languages. For the common intermediate representation to be human-usable seems to kill two birds with one stone, as expanded upon in the next point.
2. 「リソース・シェアリング。」 最近NWGで配慮を受けるのは、外国システムに関するリソースの「自動である」かプログラム駆動の実施のものです。私たちが古い「m問題によるn」を避けるつもりであるならある種の共通中間体表現がそのような機能を実行するのに明確に必要であるということであるテルネット・プロトコルの別の領域--そうでなければ、この場合、n Hostsがmコマンド言語の動向をおさえなければならないでしょう。 共通中間体表現が人間使用可能であることは一石二鳥を殺すように思えます、次のポイントで広げられるように。
3. Economy of mechanism. In RFC 451, I advanced the claim that a single user-level protocol which connected via socket 1 and Telnet would offer economy of mechanism in that new responders would not be required to service Initial Connection Protocols on socket after socket as protocol after protocol evolved. This consideration still applies, but an even greater economy is visible when we consider the context of resource sharing. For if the common command language is designed for direct employment by users, as the present proposal is, there is no need for users on terminal support "mini-Hosts" (e.g., ANTS and TIPs) to require an intermediary server when all they actually want is to work on a particular Server in the common
3. メカニズムの経済。 RFC451では、私は次々とプロトコルが発展したので、新しい応答者はソケットの上に次々とInitial Connectionプロトコルを修理する必要はないでしょう、したがって、ソケット1とTelnetを通して接続したシングルユーザーレベルプロトコルがメカニズムの経済を提供するだろうというクレームを進めました。 この考慮はまだ適用されていますが、私たちがリソース・シェアリングの文脈を考えるとき、さらに大きい経済は目に見えます。 一般的なコマンド言語が直接雇用のためにユーザによって設計されるなら、彼らが実際に欲しいすべてが一般的で特定のServerに働くことであるときに、端末のサポート「ミニホスト」(例えば、ANTSとTIPs)のユーザが仲介者サーバを必要とする必要性は全く現在の提案と異なっていません。
Padlipsky [Page 1] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[1ページ]RFC666
language. (This is especially true in light of the fact that many such users are not professional programmers -- and are familiar with no command language.) That is, if resource sharing is achieved by an intermediate language which is only suitable for programs, you would have to learn the native command language of Server B if you didn't want to incur the expense of using Server A only to get at generic functions on Server B. (And you might still have to learn the native language of Server A, even if the expense of using two Servers where one would do isn't a factor.)
言語。 (これは多くのそのようなユーザが職業プログラマでないという事実の観点から特に本当です--そして、コマンド言語なしでなじみ深いです。) すなわち、リソース・シェアリングがプログラムだけに適当な中間言語によって達成されて、あなたがServer BでServer Aを使用するジェネリック機能に達する費用を被りたくないなら、Server Bの固有のコマンド言語を学ばなければならないでしょうに。(そして、あなたはまだServer Aの母国語を学ばなければならないかもしれません、1つがする2Serversを使用する費用が要素でなくても。)
4. Front-ending. Another benefit of the common command language proposed here is that it is by and large intended to lend itself to implementation by front-ending onto existing commands. Thus, the unpleasant necessity of throwing out existing implementations is minimized. Indeed, the approach taken is a conscious effort to come up with a common command language by addition to "native" command languages rather than by replacement, for the compelling reason that it would be unworkable as well as ill-advised to attempt to legislate the richness represented by existing command languages out of existence. Further, as it is a closed environment, no naming conflicts with native commands would arise.
4. 前の結末です。 ここで提案された一般的なコマンド言語の別の利益は存在することへの前の結末のコマンドで実装に適していることを概して意図するということです。 したがって、既存の実装を放り出すという不快な必要性は最小にされます。 本当に、取られたアプローチは追加で交換でというよりむしろ「ネイティブ」のコマンド言語に一般的なコマンド言語を思いつく意識している取り組みです、既存のコマンド言語によって存在から表された豊かを制定するのを試みるのが「非-実行可能」であって、あさはかであるだろうというやむにやまれない理由によって。 さらに、それが閉じている環境であるときに、固有のコマンドとの闘争を命名するのは起こらないでしょう。
5. Accounting and authentication. As evidenced by the spate of RFCs about the implications of the FTP in regard to both accounting for use of Network services and authenticating users' identifications (Bressler's RFC 487, Pogran's RFC 501, and my RFC 505 -- and even 491), this area is still up in the air. The generic login command proposed here should help matters, as it allows the Server to associate an appropriate process with the connection while actuating appropriate accounting and access control as well, if it chooses.
5. 会計と認証。 Networkサービスの使用を説明して、ユーザの識別(BresslerのRFC487、PogranのRFC501、私のRFC505、および491さえ)を認証しながら両方に関するFTPの含意に関してRFCsのほとばしりで証明されるように、この領域はまだ未定です。 ここで提案されたジェネリックログインコマンドは件を助けるべきです、Serverが適切な会計とまた、アクセスコントロールを作動させている間それで適切なプロセスを接続に関連づけることができるとき、選ぶなら。
6. Process-process functions. By enabling the invocation of foreign object programs, the present proposal offers a rubric in which such process-to-process functions as "parallelism" can be performed. (See the discussion of the "call" command, below.) Note that the UULP is not being advanced as a panacea: It is assumed that the actual transactions carried out are most likely not going to be in the common command language (although some certainly could be); however, what is furnished is a known way of getting the presumably special- cased programs executing elsewhere. Also, it offers a convenient environment into which can be placed such new functions, which we would like to have become generic, as Day's File Access Protocol.
6. プロセスプロセスは機能します。 異物プログラムの実施を可能にすることによって、現在の提案は「平行関係」のようなプロセスからプロセスへの機能を実行できる見出しを提供します。 (以下での「呼び」コマンドの議論を見ます) UULPが万能薬として進められていないことに注意してください: 一般的なコマンド言語には行われた現物売買がたぶんない(何かが確かにそうであるかもしれませんが)と思われます。 しかしながら、家具つきであることのことはおそらく特別なケースに入れられたプログラムをほかの場所で実行させる知られている方法です。 また、どれが置かれたそのようなもの新しい機能であるかもしれないかに便利な環境を提供します、私たちがそうしたいもの。デーのFile Accessプロトコルとしてジェネリックになりました。
All of which seems to be a fair amount of mileage to get out of a distaste for remembering whether you find out who's logged in by saying "systat", "users", "s.who:c", "listf tty", or "who"....
それのすべてがあなたが、だれが"systat"を言うことによってログインしたかを見つけるかどうかを覚えている「ユーザ」のために嫌悪を出る公正な量のマイル数であるように思える「s.、だれ、: c」、"listf tty"、または「だれ」…
Padlipsky [Page 2] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[2ページ]RFC666
Context
文脈
Although ultimately intended to become the general responder to the Initial Connection Protocol, the UULP is initially to be a Telnet Protocol "negotiated option". When the option is enabled, the Server Host will furnish a command environment which supports the common conventions and commands discussed herein.
結局Initial Connectionプロトコルへの一般的な応答者になることを意図しますが、UULPが初めはテルネット・プロトコル「交渉されたオプション」であることになっています。 オプションが可能にされるとき、Server Hostはここに議論した一般的なコンベンションとコマンドをサポートするコマンド環境を提供するでしょう。
In a sense, the UULP is a "selector". That is, the common command subset includes commands to exit from the common command environment and enter various other environments, along the lines of CCN's current Telnet Server. To exit from the UULP environment to the "native" command processor, the UULP command is "local" (see also the discussion of Case, below). Note that all commands terminate in Telnet "Newline" (currently cr-lf), unless altered by the "eol" command (below); internal separator is space (blank). (Entrance into other environments -- such as the FTP Server -- is discussed below.) There are two reasons for introducing a mechanism other than the apparently natural one of simply de-negotiating the option: First, it is bound to be more convenient for the user to type a command than to escape to his User Telnet program to cause the option disabling. Second, it is hoped that eventually the UULP will be legislated to be the default environment encountered by any Network login, in which case the natural way to enter the Server's "native" command environment would be by UULP command.
ある意味で、UULPは「セレクタ」です。 すなわち、一般的なコマンド部分集合は一般的なコマンド環境から出て、他の様々な環境に入るコマンドを含んでいます、CCNの現在のTelnet Serverの系列に沿って。UULP環境から「ネイティブ」のコマンドプロセサまで出るために、UULPコマンドは「地方である」(また、以下のCaseの議論を見てください)。 "eol"コマンド(below)によって変更されない場合、すべてのコマンドがTelnet「ニューライン」(現在のcr-lf)で終わることに注意してください。 内部の分離符はスペース(空白の)です。 (以下でFTP Serverなどの他の環境への入り口について議論します。) 反-単にオプションを交渉する明らかに自然なもの以外のメカニズムを紹介する2つの理由があります: まず最初に、それはユーザがコマンドをタイプするようにオプションの無効にすることを引き起こすために彼のUser Telnetプログラムに逃げるより近いのが制限されています。 2番目に、そんなに結局、UULPがどんなNetworkログインでも遭遇するデフォルト環境になるように制定されることが望まれていて、その場合、Serverの「ネイティブ」のコマンド環境に入る自然な方法はUULPコマンドでしょう。
Note: all UULP commands discussed herein are listed in Appendix 1,
categorized as to optionality, with brief descriptions given. The
appendix may be taken as a first-pass UULP Users' Manual.
以下に注意してください。 ここに議論したすべてのUULPコマンドがoptionalityに関して分類されたAppendix1に簡単な説明を与えていて記載されています。 付録は最初に、パスUULP UsersのManualとしてみなされるかもしれません。
Responses
応答
Any optional commands which are not supported by a particular Server are to be responded to by a message of the form "Not implemented: commandname.", where the variable is the name of the command which was requested. Note that throughout this document, all literals must be sent exactly as specified, so as to allow for the possibility of Servers' being driven by programs (including "automata" or "command macros") in addition to "live" users.
フォームに関するメッセージによって特定のServerによってサポートされない少しの任意のコマンドにも応じられることになっている、「実装されません:、」 "commandname"、変数が要求されたコマンドの名前であるところ。 このドキュメント中では、ちょうど指定されるとしてすべてのリテラルを送らなければならないことに注意してください、「生きてください」に加えてプログラムによってやる気満々(「オートマトン」か「コマンドマクロ」を含んでいる)のユーザであるServersの可能性を考慮するために。
In general, the view has been taken here that a small number of literal, constrained responses is superior to a vast variety of numerically coded responses in which text may vary. Again, the motivation is to achieve an economy of mechanism. For on the coded model, there must be a coordinator of code assignments, which is just as well avoided. Further, as has been experienced in the use of the FTP, when there are many codes there are many ambiguities. (The sender may have a perfectly valid case for choosing, say, 452, while
一般に、視点はここに取って、そのa少ない番号の文字通りの、そして、強制的な応答がテキストが異なるかもしれない広大なバラエティーの数の上でコード化された応答より優れているということです。 一方、動機はメカニズムの経済を達成することです。 ただまた、避けられたコード課題のコーディネータがコード化されたモデルの上にいるに違いないので。 多くのコードがあるとき、さらに、FTPの使用で経験されたように、多くのあいまいさがあります。 (送付者には、選ぶための完全に有効なケース、たとえば452があるかもしれません。
Padlipsky [Page 3] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[3ページ]RFC666
the receiver may have an equally good interpretation of the codes' definitions for expecting, say, 453.) Experience with a related "error table" mechanism on Multics also bears out the assertion that coded responses create both managerial and technical problems. A final objection to numeric codes might be considered irrelevant by live some, but I think that the aesthetics of the situation do merit some attention. And when the common command language is being employed by live users, it seems to me that they would only be distracted by all those numbers flying around. (Nor can we assume that the numbers could be stripped by their "User UULP", for one of the basic goals here is to make it straightforward enough for a user at a TIP to deal with.)
受信機には、たとえば453を期待するためのコードの定義の等しく良い解釈があるかもしれません。) また、Multicsの上の関連する「誤りテーブル」メカニズムの経験はコード化された応答が経営者で両方を作成するという主張を証明します、そして、. 数字コードへの最終的な異論が無関係であると考えられるかもしれないことにおける技術的な問題はいくつかを住ませていますが、私は状況の美意識が何らかの注意に値すると考えます。 そして、一般的なコマンド言語が活動的なユーザによる就職であるときに、彼らが周囲を飛ぶそれらのすべての数によってそらされるだけであるように思えます。 (または、私たちは、ここの基本的な目標の1つがそれをTIPのユーザが対処するほど簡単にすることであるので数がそれらの「ユーザUULP」によって剥取られるかもしれないと思うことができません。)
Arguments
議論
During the review process, it became evident that some global comments on arguments were in order. Two areas in particular appear to have led to some confusion: the strategy of specification of arguments on the command line, and the question of "control arguments". On the first score, the goal of "front-endability" must be recalled. Consider two native implementations of a particular command, one of which (A) expects to collect its arguments by interrogation of the user, and the other of which (B) expects to receive them on invocation (being invoked as a closed subroutine). Now, it is easy to imagine that a "Server UULP" could feed the arguments to A as needed without requiring A to be rewritten, but it is quite difficult to see how B could be made to interrogate for arguments without extensive rewriting. Therefore, a "least common denominator" approach of specifying arguments in advance incurs the minimum cost in terms of reworking existing implementations.
吟味の過程の間、議論のいくつかのグローバルなコメントが整然としていたのは明白になりました。 2つの領域が何らかの混乱に通じたように特に見えます: コマンドラインの議論の仕様の戦略、および「コントロール議論」の問題。 先制点では、「前部-endability」の目標を思い出さなければなりません。 特定のコマンドの2つのネイティブの実装を考えてください(閉じたサブルーチンとして呼び出されて)。(A)はユーザの査問で議論を集めることをそれの1つを期待します。(B)は、それが、実施でそれらを受けるとそのもう片方を予想します。 現在、Aが書き直される必要でない「サーバUULP」が必要に応じて議論をAに提供するかもしれないと想像するのが簡単ですが、Bに議論のために大規模であるのなしで書き直しについてどう査問させることができたかを見るのはかなり難しいです。 したがって、指定議論の「共通項」アプローチはあらかじめ、作りなおすことの既存の実装に関して最低費用を被ります。
On the second score, I have borrowed a notion from the Multics command language's convention called "control arguments" because it seems to be quite convenient in actual practice. The key is that some arguments are meant as literals, usually specifying a mode or control function to the command, while others are variables, specifying something like a particular file name or user identifier. A common example is a "mail" command, where the variables are the user identifiers and the Host identifiers, and the "control argument" is the designator that user identifiers have ceased and Host identifiers have begun. The convention used here is to begin the control argument with a hyphen, as this character never seems to be used to begin variable arguments. Thus, we use "-at" in the mail example. Although it is not a deep philosophical point, this approach does relieve argument lists of order-dependency, and feels right to me.
2番目のスコアでは、私は実際行なわれているところでは全く近いように思えるので「コントロール議論」と呼ばれるMulticsコマンド言語のコンベンションから概念を借りました。 キーによるリテラル、通常、モードを指定するか、またはコントロールがコマンドに機能するときいくつかの議論が意味されるということです、他のものは変数ですが、特定のファイル名やユーザ識別子のように指定して。 一般的な例は「メール」コマンドです、そして、「コントロール議論」はユーザ識別子がやめた指示子です、そして、Host識別子は始まりました。そこでは、変数は、ユーザ識別子とHost識別子です。 ここで使用されたコンベンションはハイフンとのコントロール議論を始めることになっています、このキャラクタが、可変議論を始めるのに使用されるように決して思えないように。 その結果、私たちが使用する、「-、」 メールの例で。 それは深い哲学的なポイントではありませんが、このアプローチは、オーダー依存をアーギュメントの並びに取り除いて、私にとって気持ちが落ち着いています。
Padlipsky [Page 4] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[4ページ]RFC666
Case
ケース
Although it appears to have been legislated out of existence by the specification of the Network Virtual Terminal's keyboard in the Telnet Protocol, the question of what to do about users at upper- case-only terminals remains a thorny one in practice. There are two aspects to consider: the alphabetic case of commands, and the ability to cause "case-mapping" in order to allow lower-case input. Some Servers have no local problems with the first aspect, as they operate internally in all upper-case or all lower-case and merely map all input appropriately. (Problems do arise, though, when one is using the User FTP on such a system to deal with a mixed-case system, for example.) Other Servers, however, attach the normal linguistic significance to case. (E.g., Smith's name is "Smith" -- not "SMITH", and not "smith".) To minimise superfluous processing for those Servers which are indifferent to case, all UULP commands are to be recognized as such whether they arrive as all upper-case or all lower-case. (They will be shown here as all lower merely for typing convenience.) Note that arbitrarily mixed case is not recognized, as it is an unwarranted assumption about local implementation to suppose that input will necessarily be case-mapped.
Network Virtual Terminalのキーボードの仕様によって存在からテルネット・プロトコルで制定されたように見えますが、上側のケースだけ端末のユーザに関してするべきことに関する問題は実際にはとげがあるもののままで残っています。 考える2つの局面があります: コマンドのアルファベットケース、および小文字の入力を許すために「ケースマッピング」を引き起こす能力。 いくつかのServersには、最初の局面の地方の問題が全くありません、すべての大文字かすべてで内部的に小文字で作動して、単に適切にすべての入力を写像するとき。 (もっとも、1つが例えば複雑なケースシステムに対処するのにそのようなシステムの上でUser FTPを使用しているとき、問題は起こります) しかしながら、他のServersはケースに入れる正常な言語学の意味を付けます。 (例えば、スミスの名前は「スミス」です--「鍛冶屋」ではなく「スミス」でない) それらのケースに入れるためにありきたりのServersのために余計な処理を最小とならせるように、すべてのUULPコマンドはそれらがすべての大文字かすべての小文字として到着するか否かに関係なく、そういうものとして認識されることです。 (すべてが単に便利をタイプするために下ろされるとき、それらはここに示されるでしょう。) 任意に複雑なケースが認識されないことに注意してください、入力が必ずケースで写像されていると思うのが、地方の実装に関する保証のない仮定であるので。
On the second aspect, any Server which does distinguish between upper- and lower-case in commands' arguments (a.k.a. parameters) must furnish a UULP "map" command as specified in Appendix 2 in order to support logins from upper-case-only terminals attached to User Hosts which either do not support the Telnet Protocol's dictum that all 128 ASCII codes must be generable, or support it awkwardly. This seems a simpler and preferable solution than the alternative of legislating that upper-case Network-wide personal identifiers (and perhaps even Network Virtual Path Names) be pre-conditions to a usable common command subset. (As noted below, these latter concepts will fit in smoothly when they are agreed upon. The point here, though, is that we need not deprive ourselves of the benefits of a UULP until they are agreed upon.)
第2の面では、(通称パラメタ)がUULP「地図」を提供しなければならないというコマンドの主張における上側と小文字の間で区別するどんなServerも、すべての128のASCIIコードがテルネット・プロトコルの断言がそれであるとサポートしないUser Hostsに取り付けられた上側のケースだけ端末からログインをサポートするためにAppendix2で指定されるように生成できるか、またはぎこちなくそれをサポートしなければならないと命令します。 これは制定の代替手段よりさらに簡単で望ましいソリューションに見えます。大文字のNetwork全体の個人的な識別子(恐らくNetwork Virtual Path Namesさえ)は使用可能な一般的なコマンド部分集合へのプレ状態です。 (それらが同意されるとき、以下に述べられるように、これらの後者の概念はスムーズに適合するでしょう。 もっとも、ここのポイントはそれらが同意されるまで私たちが自分達からUULPの利益を奪う必要はないということです。)
User Names
ユーザ名
As implied above, the various Servers have their various ways of expressing users' names. Clearly, the principle of economy of memory dictates that there should be a common intermediate representation of names in and for the Network. It is probably also clear that this representation will be based upon the Network Information Center's "NIC ID's". However, it is unfortunately amply clear than an acceptable mechanism for securing up-to-date information cannot be legislated here - much less a mechanism for securely updating the implied data base. Therefore, at this stage it seems to be the
上で含意されるように、様々なServersには彼らのユーザの名前を表す様々な方法があります。 明確に、メモリの経済の原則は、NetworkとNetworkのための名前の共通中間体表現があるべきであると決めます。 また、この表現がNetworkインフォメーション・センターの「NIC IDのもの」に基づくのも、たぶん明確です。 しかしながら、残念ながら、それはここで最新情報を保証するための許容できるメカニズムを制定できません--まして、しっかりと暗示しているデータベースをアップデートするためのメカニズムより十分に明確です。 したがって、それが見えるこの段階で、いてください。
Padlipsky [Page 5] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[5ページ]RFC666
sensible thing to specify only the UULP syntax for conveying to the Server the fact that it is to treat a user name as a Network-wide name rather than as a local name, and let the supporting mechanisms evolve as they may.
発展しても、地方名としてというよりむしろNetwork全体の名前としてユーザ名を扱って、サポートメカニズムをさせることになっているという事実をServerに伝えながらUULP構文だけを指定する分別があるもの。
The prefacing of a name with an asterisk ("*") denotes a Network-wide
name. (Such names may be either all upper-case or all lower-case, as
with UULP commands' names.) The name "*free" is explicitly reserved
to mean that (in the context of logging in) a login is desired on a
supported or sampling account, if such an account is available. The
response if no such account is available is to be "Invalid ident:
*free." When Network-wide names are generally available Servers will
either map them into local names or cause them to be registered as
local names as they prefer. The point is that a Network-wide name
will be "made to work" by the Server in the context of the UULP.
アスタリスク(「*」)の名前の前書きはネットワーク全体の名前を指示します。 (UULPコマンドの名前すべての大文字かすべてのどちらかが小文字であったなら、そのような名前はそうするかもしれません。) 「」 *が解放する名前」は(ログインすることの文脈の)ログインがサポートされるか標本抽出アカウントで望まれていることを意味するために明らかに予約されます、そのようなアカウントが利用可能であるなら。 「応答はどんなそのようなアカウントも利用可能でないなら病人は以下をidentする」ことです。 *「自由です」。 Network全体の名前が一般に利用可能であるときに、Serversは好むように彼らを地方名に写像するか、または地方名としてそれらを登録させるでしょう。 ポイントはUULPの文脈のServerはNetwork全体の名前を「働かされる」ということです。
Special Characters and Signals
特殊文字と信号
Another area in which the facts of life must outweigh the letter of the Telnet Protocol if the user's convenience is to be served is that of "erase" and "kill" characters. It is possible that User Telnets will uniformly facilitate the transmission of the Telnet control codes for generic character erase and generic line kill. It is certain, however, that User Telnets will differ -- and users will, if they use more than one User Telnet, be again placed in the uncomfortable position of having to develop too many sets of reflexes. Therefore, the UULP will optionally support the following commands: "erase char" and "kill char", where char is a printable ASCII character (to avoid possible conflicts with "control characters" which are recognized in the innermost areas of particular operating systems). Presumably, unwary users can be instructed not to choose an alphabetic, so as to avoid being placed in a position where they cannot invoke certain commands (erase and kill themselves, for example, in which case they couldn't be changed).
現実がユーザの便宜が役立たれることであるならテルネット・プロトコルの手紙より重くなければならない別の領域は「抹消」と「殺してください」というキャラクタのものです。 User Telnetsが抹消とジェネリック系列で死ぬジェネリックキャラクタのために一様にTelnet制御コードの送信を容易にするのは、可能です。 しかしながら、User Telnetsが異なるのが、確かであり、あまりに多くの反射能力を見いださなければならない不愉快な位置に置かれて、彼らが1User Telnetを使用すると、ユーザは再び確かでしょう。 したがって、UULPは任意に以下のコマンドをサポートするでしょう: 「炭を消してください」と「炭をだめにしてください」、炭が印刷可能なASCII文字(特定のオペレーティングシステムの最も奥深い領域で認識される「制御文字」との可能な闘争を避ける)であるところで。 おそらく、不注意なユーザが選ばないよう命令できる、アルファベット、彼らが、あるコマンドを呼び出すことができない(例えば、それらがどの場合であることができなかったかに、変えた状態で自分たちを消して、殺してください)ところで位置に置かれるのを避けます。
These commands are supplements to the related Telnet control codes, and have the same meanings. The point here is that it may be far more convenient for a user to be able to say "erase #" and get the "#" to be recognized as the erase character by the Server than for the user to get his User Telnet to send the Telnet equivalent. The commands are designated as optional because they may lead to severe implementation problems on some Servers, and because the equivalent functions do, after all, exist in Telnet.
これらのコマンドは、関連するTelnet制御コードへの補足であり、同じ意味を持っています。 ユーザが「#、を消してください」と言って、消去文字としてサーバで「#」を認識させることができるのがユーザが彼のユーザtelnetにtelnet同等物を送らせるよりはるかに便利であるかもしれないというポイントがここにあります。 いくつかのServersで厳しい実装問題を引き起こすかもしれなくて、同等な機能がTelnetに結局存在しているので、コマンドは任意であるとして指定されます。
Note: the erasing is assumed to be performed "as early as
possible". That is, the sequence "erase x" "erase x" should come
out equivalent to "erase x" "erase" -- the second appearance of
以下に注意してください。 消すことによって「できるだけ早く」実行されると思われます。 すなわち、系列「抹消x」「抹消x」は「抹消x」「抹消」に同等な状態で出て来るべきです--、外観を後援します。
Padlipsky [Page 6] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[6ページ]RFC666
"x" resulting in the erasing of the space in the command line.
Presumably, this is a sufficiently uncommon path that anomalous
results would be tolerated by the user community, but the intent
ought to be clear.
コマンドラインのスペースを消すことをもたらす「x。」 おそらく、これははっきりと変則的な結果がユーザーコミュニティによって許容されるでしょうが、意図が許容されるべきである十分珍しい経路です。
The Telnet "synch" and "break" mechanisms are, by their very nature, best left to Telnet. End of line, however, might well be a different story. Therefore, as a potential convenience, the UULP optionally supports "eol char" to ask the Server to treat char as the end of line character thenceforth. To revert to Telnet Newline, "eol" (i.e., no argument, current terminator).
彼らのまさしくその本質でTelnet「同時性」と「中断」メカニズムをTelnetに残すのは最も良いです。 しかしながら、行末はたぶん別の話でしょう。 したがって、潜在的便利として、UULPは、そのときから行末キャラクタとして炭を扱うようにServerに頼むために任意に「eol炭」をサポートします。 Telnet Newline、"eol"(すなわち、議論がない、現在のターミネータ)に振り向けるために。
Prompts
プロンプト
Another aspect in which Servers vary while being the same is how they indicate "being at command level". Some output "ready messages"; others, "prompt characters". For the UULP, where some functions will be performed by means of a command's logging in to another system, the ability to specify a known prompt character is extremely desirable. The UULP command is "prompt char" where char is the character which is to be sent when the user's process (on the Server) is at command level. It is explicitly permitted to prefix char to a line consisting of a "native" prompt or ready message. Also, this command is explicitly acknowledged to be permissible prior to login. (Again, warning must be made of the bad results which can ensue if an alphabetic character is chosen.)
同じである間Serversが異なるもう一つの側面は彼らがどう「コマンドレベルにいること」を示すかということです。 或るものは「持ち合わせのメッセージ」を出力しました。 他のもの、「キャラクタをうながしてください。」 UULPに関しては、知られているプロンプト文字を指定する能力は非常に望ましいです。そこでは、いくつかの機能がコマンドの伐採によって中で別のシステムに実行されるでしょう。 UULPコマンドは炭がユーザのプロセス(Serverの)がコマンドレベルにあるとき送られることになっているキャラクタである「迅速な炭」です。 それが迅速であるか持ち合わせの「ネイティブ」のメッセージから成る系列へ炭を前に置くことが明らかに許可されています。 また、このコマンドはログインの前に許されると明らかに承諾されます。 (一方、英字が選ばれているなら続くことができる悪い結果で警告を作らなければなりません。)
Note: "prompt", "eol", "erase", and "kill" may all be re-invoked
with a new value of char in order to change the relevant setting;
all may be turned off by invocation with no argument.
以下に注意してください。 「迅速です」、"eol"、「抹消」、および「殺してください」は関連設定を変えるために炭の新しい値ですべて再呼び出されるかもしれません。 すべてが実施によって議論なしでオフにされるかもしれません。
Login
ログイン
Perhaps the stickiest wicket of them all is the attempt to specify a generic login, but here we go. The UULP login command is "login userident", where userident is either a locally-acceptable user identifier or a Network-wide identifier as discussed above. Note that for utility in contexts to be discussed later, the locally- acceptable form must not contain spaces. Servers may respond to the login attempt with arbitrary text (such as a "message of the day"), but some line of the response must be one of the following: a prompt (as discussed above; indicating, in the present context, successful login); "Password:"; or "Invalid ident: userident." When passwords are required, it is the Server's responsibility either to send a mask or to successfully negotiate the Hide Your Input option.
恐らくそれらのすべての最もねばねばする門はジェネリックログインを指定する試みですが、ここに、私たちは行きます。 UULPログインコマンドはuseridentが上で議論するように局所的に許容できるユーザ識別子かNetwork全体の識別子のどちらかである「ログインuserident」です。 後で文脈のユーティリティについて議論するために、局所的に許容しているフォームが空間を含んではいけないことに注意してください。 サーバは任意のテキスト(「1日のメッセージ」などの)でログイン試みに反応するかもしれませんが、応答の何らかの系列が以下の1つであるに違いありません: プロンプト(現在の文脈でうまくいっているログインを示して、上で議論するように)。 「パスワード:」、。 または、「病人はidentします」。 "userident"。 パスワードが必要であるときに、マスクを送るか、または首尾よくHide Your Inputオプションを交渉するのが、Serverの責任です。
Padlipsky [Page 7] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[7ページ]RFC666
Note that "login *free" is specifically defined to require no password. (If a "freeloader" has access to a User Telnet and has learned of the "*free" syntax, it is fruitless to assume that he couldn't have also read the common password.) If a password must be given, acceptable responses are arbitrary text containing a line beginning either with a prompt or with "Login unsuccessful." or with "Account:". If an account is requested, the responses must be either the "Login unsuccessful" message or the text containing a prompt already described. If any errors occur during the login sequence, users are to re-try by starting from the login command. (I.e., it is not required that the Server "remember" idents or passwords.)
「無料のログイン*」がパスワードを全く必要としないように明確に定義されることに注意してください。 」 *は」 構文を解放して、それは、仮定するために実りがありません。「(「たかる人」がUser Telnetにアクセスして、知っていた、また、彼は一般的なパスワードを読むことができませんでした)。 パスワードを与えなければならないなら、許容できる応答がプロンプトか「ログイン失敗」で始まる系列を含む任意のテキストである、「説明してください。」 アカウントが要求されるなら、応答は、「ログイン失敗」のメッセージか既に説明されたプロンプトを含むテキストのどちらかであるに違いありません。 何か誤りがログイン系列の間、発生するなら、ユーザは、ログインコマンドから始めることによって、再試行することになっています。 (すなわち、Serverがidentsかパスワードを「覚えていること」が必要ではありません。)
It is explicitly acknowledged that an acceptable response to "login *free" is "Limited access only." (followed by a prompt). This is intended to warn (human) users that the free account on the Server in question exists only to allow such functions as accepting mail and telling if a particular user happens to be logged in. (For objections to "loginless" performance of such tasks, see RFC 491. Note also that nothing here says that a Server must do anything other than return a prompt in response to "login *free" in the event that loginless operation is natural to it.) Given the UULP login discipline and the "prompt" command, it is reasonably straightforward for a program to login on a free account and perform one of these functions, for if the login command succeeded, the program will "see" a guaranteed prompt character.
「*から無料でログインする」許容できる応答が「株式会社アクセス専用」であると明らかに認められます。 (プロンプトはあとに続いています。) これが、特定のユーザがたまたまログインされるなら問題のServerの上の無料のアカウントが存在すると(人間)のユーザに警告することをメールを受け入れて、言うような機能を許容する意図します。 そのようなタスクの"loginless"性能への反論に関して、RFC491を見てください。(また、ここの何も、loginless操作がそれに当然である場合Serverが「無料のログイン*」に対応してリターン以外の何にもプロンプトをしなければならないと言わないことに注意してください。) UULPログイン規律と「迅速な」コマンドを考えて、プログラムが無料のアカウントにログインして、これらの機能の1つを実行するのは、合理的に簡単です、ログインコマンドが成功したなら、プログラムが保証されたプロンプト文字を「見る」ので。
To make life simpler for those Hosts which normally have some sort of "daemon" process service mail and the like, a further expansion to login is in order. The point here is that some Hosts may not know what sort of process to pass an unqualified "login *free" to, whereas they'd be sure what to do with an explicit request to process mail, do a who command, or set up console to console communications. Therefore, UULP "login" will allow a "control argument" (as discussed above) of either "-mail", "-who", or "-concom", and the respective UULP commands involved must use the respective strings in any login line they transmit. Again, nothing is being said about what a Server has to do with the information, but some Servers need/want it.
ログインするために寿命を通常、ある種の「デーモン」プロセスサービスメールと同様のもの、一層の拡張を持っているそれらのHostsには、より簡単にするのは整然としています。 いくつかのHostsが、彼らが確実にメールを処理するという明白な要求で何をするだろうか、しかし、コンソールコミュニケーションにコンソールを命令するか、またはセットアップするaをするために何が資格のない「無料のログイン*」を通過するためにちょっと処理されるかを知らないかもしれないというポイントがここにあります。 したがって、UULP「ログイン」が「メール」の「コントロール議論」(上で議論するように)を許容する、「-、だれ、」 それぞれの、が彼らが伝えるどんなログイン台詞でも結ぶ必須使用にかかわったか"-concom"、およびそれぞれのUULPが、命令する。 一方、何もServerが情報でしなければならないことに関して言われていませんが、いくつかのServersがそれが必要である、または欲しいです。
Usage Information
用法情報
Most Servers offer some sort of on-line documentation, from calling sequences of commands to entire users' manuals. There are two sorts of information of interest in the UULP environment: "normal" system information, and information about the particular Server's UULP implementation. To learn how to get descriptions of "native" commands, the UULP command is "help -sys" (abbreviation: "?"). Note that "-sys" is viewed as a "control argument" and as such prefaced by
ほとんどのServersがコマンドに関する呼出し手順から全体のユーザのマニュアルまである種のオンラインドキュメンテーションを提供します。 UULP環境には興味がある情報の2種類があります: 「正常な」システム情報、および特定のServerのUULP実装の情報。 「ネイティブ」のコマンド、UULPコマンドの記述を得る方法を学ぶのは、「助け-sys」(略語: “?")です。 "-sys"が「コントロール議論」として見なされて、そのようなものとして前書きされる注意
Padlipsky [Page 8] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[8ページ]RFC666
a hyphen ("-") to facilitate distinction from other sorts of name
(e.g., command names). To get a description of the Server's UULP
implementation, "help -uulp". To get a description of a particular
UULP command's implementation, "help comname". To be reminded of how
to use the help command, "help".
他の種類の名前(例えば、コマンド名)から区別を容易にするハイフン(「-」)。 ServerのUULP実装の記述を得るためには、「-uulpを助けてください。」 特定のUULPコマンドの実装の記述を得るためには、「comnameを助けてください。」 どう援助コマンドを使用するかについて思い出させられるためには、「助けてください。」
Note: as with command names and Network-wide user names, control
arguments may be either all upper-case or all lower-case.
以下に注意してください。 コマンド名とNetwork全体のユーザ名なら、コントロール議論は、すべての大文字かすべて、小文字のどちらかであるかもしれません。
It is specifically acknowledged that "No peculiarities." is an appropriate response to "help comname" if nothing of interest need be said about the Server's implementation of the UULP command in question. (After all, we're sparing users the necessity of studying a dozen or so users' manuals; the least they can do is to read the UULP command list.) Appropriate information for less taciturn Hosts to furnish would be such data as local command invoked (if such be the case), argument syntax (e.g., pathname description, or name of help file about pathnames), "To be implemented.", or even "Not to be implemented."
「いいえのユニークさ」 適切な応答が興味がない無さであるなら「comnameを助けることになっている」という必要性がServerの問題のUULPコマンドの実装に関して言われていると明確に認められます。 (結局、私たちはユーザのマニュアルをおよそ1ダース研究するという必要性からユーザを開放しています; それらができる最少がUULPコマンドリストを読むことになっています。) それほど無口でないHostsが提供する適切な情報は呼び出された、ローカルのコマンド(そのようなものがケースであるなら)、議論構文(例えば、パス名記述、またはパス名に関するヘルプファイルの名前)のようなデータ、「実装されない」ように同等の「実装されます」です。
"Mail"
「メール」
Even though a separate mail protocol is being evolved for general purposes, the UULP needs to address this topic as, by virtue of being login based, it allows systems which do access control and sender authentication on mail to make these abilities available to users within its framework of generic functions. Therefore, to read one's mailbox, the UULP command is "readmail". To have "live" input collected and sent to a local user, "mail userident"; to a remote user, "mail userident -at hostname", where the arguments have the "obvious" meanings. To send a previously-created file, "mail -f filename userident -at hostname". Several useridents may be furnished; the delimiter is space (blank). Similar considerations apply to hostnames. If both are lists, they sould be treated pairwise. (A more elaborate syntax could be invented to deal with the desire to send to several users at a given host and then to other users at other hosts, but it seems unnecessary to do so at this point, for multiple invocations would get the job done.)
別々のメールプロトコルは一般用に発展することにされますが、これらの能力が基づくログインであることによってそれでジェネリック機能のフレームワークの中でユーザにとって利用可能になる場合があって、メールでアクセスコントロールと送付者認証をするシステムでUULPは、この話題を扱う必要があります。 したがって、人のメールボックス、UULPにコマンドを読み込むのは、"readmail"です。 「生きてください」を入力させるのは、地元のユーザ、「メールuserident」に集まって、発信しました。 リモート・ユーザーに「useridentに郵送してください、-、ホスト名、」、議論が「明白な」意味を持っているところ。 以前に作成されたファイルを送るために「-fファイル名useridentに郵送してください、-、ホスト名、」 数個のuseridentsが提供されるかもしれません。 デリミタはスペース(空白の)です。 同様の問題はホスト名に適用されます。 それらは両方がリストであるなら、souldします。扱われた対状になってください。 (他のホストで与えられたホストの数人のユーザと、そして、そして、他のユーザに発信する願望に対処するために、より精巧な構文を発明できましたが、それほどここにするのは不要に思えます、複数の実施で仕事を完了するでしょう、したがって。)
The mail command prefaces the message with a line identifying the
sender (Host and time desirable, but not mandatory). For "live"
collection, the end of message is indicated by a line consisting of
only a period (".") followed by the regnant line terminator (usually
the Telnet Newline, but see also the discussion of the eol command).
If remote mail is not successfully transmitted, it is to be saved in
a local file and that file's name is to be output as part of the
failure message. ("Queueing" for later transmission is admired, but
系列が送付者を特定している状態で(ホストと時間望ましい、しかし、義務的でない)、メールコマンドはメッセージについて前書きします。 「ライブな」収集において、メッセージの終わりが期間だけから成る系列によって示される、(「」、)、君臨があとに続いて、ターミネータを裏打ちしてください、(通常また、eolコマンドの議論を見るのを除いたtelnetニューライン リモートメールが首尾よく伝えられないなら、それはローカルファイルで保存されることになっています、そして、そのファイルの名前は失敗メッセージの一部としての出力であることです。 (しかし、後のトランスミッションのための「待ち行列」は賞賛されています。
Padlipsky [Page 9] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[9ページ]RFC666
not required.) The transmission mechanism will follow the general mail protocol. Note that when invoked with a "-at" clause, the mail command will send "login *free -mail" to the remote Host(s), followed by a mail command with no "-at" clause.
必要ではありません。) 効果波及経路は一般郵便プロトコルに従うでしょう。 aで呼び出されたらそれに注意してください、「-、メールコマンドで」 節(コマンドがリモートHost(s)への「ログイン*の有でないメール」を送るメール)が従った、「-、」 節。
A desirable, but not required, embellishment to "readmail" would be
the accepting of a Host name ("-at hostname") to cause the local Host
to go off to the named Host (via "login *free -mail") and check for
mail there. Several hostnames could, of course, be specified. A
further embellishment, which would probably be quite expensive, would
be to accept "-all" as a request to check all Hosts (or, perhaps, all
Hosts known to have a free account for the purpose) for mail.
"readmail"への望ましい、しかし、必要でない潤色がHost名の受諾であるだろう、(「-、ホスト名、」、)、地方のHostが命名されたHost(「ログイン*の有でないメール」を通した)へ去って、メールがないかどうかそこでチェックすることを引き起こすために。 もちろんいくつかのホスト名を指定できました。 さらなる潤色(たぶんかなり高価である)はメールのために、すべてをチェックするという要求としての「-すべて」というHosts(恐らく目的のための無料のアカウントを持っているのが知られているすべてのHosts)を受け入れるだろうことです。
Direct Communication
ダイレクトコミュニケーション
The ability to exchange messages directly with other logged in users is apparently greatly prized by many users. Therefore, despite the fact that there is a sense in which this function is not within the purview of the UULP, we will address it, after a digression.
直接ユーザに登録されたもう一方とメッセージを交換する能力は多くのユーザによって明らかに大いに尊重されます。 したがって、UULPの範囲の中にこの機能がない感覚があるという事実にもかかわらず、私たちはそれを扱うつもりです、脱線の後に。
Digression: The UULP assumes that there can be straightforward
"front ends" at the various Servers which translate generic
function calls in a common spelling to calls for specific, pre-
existing "native" functions. In the area of console to console
communications, however, this premise does not really hold. The
problem is that both major "native" implementations known to the
author are seriously flawed. The TENEX "link" mechanism is both
insecure (you've got no business seeing everything I type even if
I'm careless enough to let you) and inconvenient (why should I be
forced to remember that pesky semi-colon? how do I get back into
phase after I've forgotten one?). It is also likely to be
extremely difficult to simulate on systems which do not force
Network I/O through local TTY buffers, even if the user interface
were not subject to criticism. The Multics "send_message"
mechanism, on the other hand, has a more sophisticated design, but
is absurdly expensive. Therefore, the UULP mechanism to be
described assumes that, for this function, new local
implementations will be developed to support it.
脱線: UULPは、簡単な「前の終わり」が特定の、そして、プレ既存の「ネイティブ」の機能のための呼び出しに一般的なスペルにおけるジェネリックファンクションコールを翻訳する様々なServersにあることができると仮定します。 しかしながら、コンソールコミュニケーションへのコンソールの領域では、この前提が本当に成立しません。 問題は作者にとって知られている両方の主要な「ネイティブ」の実装がひどく失敗するということです。 私はなぜやむを得ずそのやっかいなセミコロンを覚えているべきですか?TENEX「リンク」メカニズムは、不安定であって、かつ(あなたはどんなビジネスにも不注意であっても私がタイプするすべてがあなたをさせるために十分であることを見させていません)不便です(私が1つを忘れた後にどのようにフェーズを入れて戻しますか?)。 また、それもローカルのTTYバッファを通してNetwork入出力を強制しないシステムの上でシミュレートするのが非常に難しい傾向があります、ユーザーインタフェースは批評を受けることがなかったとしても。 他方では、「_メッセージを送ってください」というMulticsメカニズムは、より洗練されたデザインを持っていますが、とんでもないほど高価です。 したがって、説明されるべきUULPメカニズムは、新しい地方の実装がそれをサポートするためにこの機能において開発されると仮定します。
To permit console to console communications: "concom -on"; to refuse,
"concom -off". Default is off. To enter message-sending mode:
"concom userident -at hostname" ("-at" clause is optional). To exit
from message-sending mode, type a line consisting of only a period
(cf. Mail, above). While in message-sending mode, each line will be
transmitted as a unit. The first message sent by concom must be
prefaced by an identifying line, beginning "From:" and containing an
appropriate address to which to reply. The closing period-only line
コンソールコミュニケーションへのコンソールを可能にするために: 「concomにオン」。 廃物で、「concomにオフです」。 デフォルトはオフです。 メッセージ送信モードを入れるために: 「concom userident、-、ホスト名、」、(「-、」 節が任意である、) メッセージ送信モードから出るには、期間だけから成る系列をタイプしてください。(Cf。 上のメール). 各台詞はメッセージ送信モードで一体にして伝えられるでしょうが。 「From:」を始めて、特定系列でconcomによって送られた最初のメッセージを始めなければなりません。 そして、返答する適切なアドレスを含むこと。 終わりの期間だけの系列
Padlipsky [Page 10] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[10ページ]RFC666
should be transmitted, so as to allow the other concom to close as well. Acceptable error response is "Not available: userident." (which neither confirms nor denies the existence of the particular user -- a matter of concern on the security front). The command must, of course, do whatever is necessary to transmit the messages; i.e., if locally invoked, access the local mechanism, and if invoked for remote communications, access the remote Host's concom command (via "login *free -concom"). Thus, a user at a TIP would use the local form of concom on the Host of the other party if this is convenient, or would use the remote form on his "usual" Server if the direct use is inconvenient for some reason (such as having no account there, say).
また、もう片方のconcomが閉じるのを許容するために伝えられるべきです。 許容できる誤り応答がそうである、「利用可能でない:、」 "userident"。 (特定のユーザの存在を確認でない、また否定しないもの--セキュリティ前部で重要な件)。 コマンドはもちろんメッセージを送るのに必要なことなら何でもしなければなりません。 すなわち、局所的に呼び出されるなら、局所機構にアクセスしてください、そして、リモートコミュニケーションのために呼び出されるなら、リモートHostのconcomコマンド(「ログイン*の自由な-concom」を通した)にアクセスしてください。 したがって、TIPのユーザは、これが便利であるなら相手のHostの上のconcomの地方のフォームを使用するだろうか、またはダイレクト使用が何らかの理由(いいえがそこで説明して、言うのを持つことなどの)で不便であるなら、彼の「普通」のServerのリモートフォームを使用するでしょう。
The prerequisites for establishing communications are to find out if the user is logged in, and what "address" to use if so. The mechanism for gathering this information is an expanded "who" command. (Note that "who" is the UULP command to invoke the generic who's logged in function, with no constraints on format of reply.) The syntax is "who userident -at hostname", where both arguments may be multiple. If no "-at" clause, then check local Host only. Response must begin "From hostname: userident:" followed by either an appropriate address (e.g., "ll" if local "concom" uses TTY numbers and userident is logged in on TTY ll), or "Not available."
コミュニケーションを確立するための前提条件はユーザがログインされるかどうかと、そうだとすれば、どんな「アドレス」を使用したらよいかを見つけることになっています。 この情報を集めるためのメカニズムは拡張「だれ」コマンドであるか。 (「だれ」がUULPであるかが、そうしたジェネリックを呼び出すのが回答の形式で規制なしで機能にログインしたと命令することに注意してください。) 構文がそうである、「useridentする、-、ホスト名、」、両方の議論がそうするかもしれないところでは、倍数はそうです。 いいえ、「-、」 節、当時のチェックの地方のHost専用。 応答が始まらなければならない、「ホスト名から:、」 「userident:」 適切なアドレス(地方の"concom"がTTY番号とuseridentを使用するなら、例えば、"ll"はTTY llでログインされる)であとに続かれる、または「利用可能ではありません」。
As with mail, a "-all" embellishment might be pleasant. Note that the search for the specified user(s) -- whether or not "-all" is used -- still assumes that a "login *free -who" login will be used on the appropriate remote Host(s), followed by "who userident". This is why responses to the expanded who command must be so rigidly specified. Note also that regardless of whether the inquiry is made in terms of Network-wide or local user name, the response must be appropriate for use in "concom".
メールなら、「-すべて」という潤色は快いかもしれません。 「-すべて」が使用されているか否かに関係なく、指定されたユーザの捜索がまだそのaを仮定していることに注意してください、「*から無料でログインしてください、-、だれ、」 ログインは「だれがuseridentするか」によって続かれた適切なリモートHost(s)で使用されるだろうか。 これは広げることへの命令する応答をあまりに厳格に指定しなければならない理由です。 また、"concom"における使用に、Network全体の、または、ローカルのユーザ名で問い合せをするかどうかにかかわらず応答が適切であるに違いないことに注意してください。
"Good" concom implementations will presumably do an expanded who command automatically, so as to spare the user the necessity of having to do it separately. Indeed, the -concom control argument to login is defined to imply the ability to do a who as well as a concom to cater to this possibility. It is tempting to legislate that such an approach be the rule, but the implementation implications are not quite clear enough to do so. The implicit who should be viewed as a strong hint to implementers, though.
おそらく、「良い」concom実装がする、広げられて、だれが、別々にそれをしなければならないという必要性からユーザを開放するために自動的に命令しますか? 本当に、ログインする-concomコントロール議論は、aと同様にこの可能性に満たすためにconcomするaをする能力を含意するために定義されます。 そんなにそのようなアプローチを制定するために魅力的であるのが、規則であるのにもかかわらずの、実装含意が全くそうするほど明確であるというわけではないということです。 もっとも、強いヒントとしてimplementersにおいて見なされるべきである暗黙。
File Creation and Manipulation
ファイル作成と操作
The common command subset must furnish the ability to create and manipulate files. Creation is necessary in order to send mail on the one hand, and to produce source files for subsequent compilation on the other hand. Manipulation (such as copying, renaming, typing out,
一般的なコマンド部分集合はファイルを作成して、操作する能力を提供しなければなりません。 作成が、一方では、メールを送って、他方では、その後の編集のためのソースファイルを作り出すのに必要です。 操作、(タイプで打って、改名して、コピーするのなどように
Padlipsky [Page 11] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[11ページ]RFC666
and the like) is necessary both as a convenience aspect for users who seek to operate only in the common command language and as a means of performing desired batch functions (see below). For file manipulation commands, the user could enter the File Transfer Protocol environment. However, the FTP user interface is constrained by a very high degree of program-drivability. It is also lacks abbreviations and suffers from the lack of mnemonicity dictated by limiting command names to four characters. Further, some valuable functions (such as causing a file to be typed out) are not dealt with. Therefore, various UULP file manipulation commands are given in Appendix 1. They need not be addressed in detail here. However, some context would be useful:
そして、同様のもの) ともに一般的なコマンド言語だけで作動しようとするユーザのための便利局面として必要であり、働く手段として望まれていて、バッチは機能します(以下を見てください)。 ファイル操作命令のために、ユーザはFile Transferプロトコル環境に入ることができました。 しかしながら、FTPユーザーインタフェースはプログラム-drivabilityの非常に高度合いによって抑制されます。 それは、また、欠乏略語であり、コマンド名を4つのキャラクタに制限することによって書き取られたmnemonicityの不足に苦しみます。 さらに、いくつかの貴重な機能(ファイルがタイプで打たれることを引き起こすことなどの)は対処されていません。 したがって、Appendix1で様々なUULPファイル操作命令を与えます。 それらはここで詳細に扱われる必要はありません。 しかしながら、何らかの文脈が役に立つでしょう:
The file manipulation commands assume that all Servers have some notion roughly corresponding to "the user's working directory". All file names, whether the yet to be invented Network Virtual Pathname or the "local" variety, are taken to refer to files in this directory unless otherwise indicated. That is, the user should not have to furnish "dsk:" or the like; it is taken as given that when he refers to file "x" he means "the file named 'x' in my current working directory" and the Server "knows" what that means.
ファイル操作命令は、すべてのServersで何らかの考えがおよそ「ユーザの働くディレクトリ」に対応するようになると仮定します。 別の方法で示さない場合、まだ発明されなかったNetwork Virtual Pathnameか「地方」のバラエティーであることにかかわらずこのディレクトリのファイルを示すためにすべてのファイル名を取ります。 すなわち、ユーザが提供する必要はないはずである、「dsk:」 同様のもの。 ファイル「x」を示すとき、それを考えて、彼が「私の現在の働くディレクトリの'x'というファイル」を言っているとき、それを取ります、そして、Serverはそれが何を意味するかを「知っています」。
At the present stage of development of the UULP, it does not seem fruitful to go into a reasoned explication of the following statement. For now, suffice it to say that those file manipulation commands (a copy of a foreign file, for example) which need to employ the FTP do employ the FTP and let it go at that. As the context and implications of the protocol become more widely understood, the detailed implementation notes will be added to the file commands -- and refined for the other commands, doubtless. In a way, the common file commands may be viewed as a kind of "User FTP" of known human interface when they deal with foreign files. (And, of course, until there's a Network virtual pathname, the issue doesn't really arise.) I expect that an "identify" command might be desirable, so that UULP commands which have to access other Servers in turn on behalf of the specific current user can have the necessary login information available to them. Such a command is included in Appendix 1, but should rank as speculation for now.
UULPの開発の現段階では、以下の声明の推論された解説に入るのは実り多く思えません。 当分、それを満足させて、FTPを使う必要があるそれらのファイル操作命令(例えば、外部ファイルのコピー)がFTPを使って、それをおまけに、行かせると言ってください。 プロトコルの文脈と含意が広くより理解されるようになるとき、詳細な実装注意はファイルコマンドに追加されるでしょう--そして、他のコマンドのために洗練されました、疑いないです。 外部ファイルに対処するとき、ある意味で、一般的なファイルコマンドは知られているヒューマンインターフェースの一種の「ユーザFTP」として見なされるかもしれません。 (もちろん、そして、Networkの仮想のパス名があるまで、問題は本当に起こりません。) 私は、「特定」コマンドが望ましいかもしれないと予想します、順番に特定の現在のユーザを代表して他のServersにアクセスしなければならないUULPコマンドが彼らにとって、利用可能な必要なログイン情報を持つことができるように。 そのようなコマンドは、Appendix1に含まれていますが、当分思惑として格付けするべきです。
On the topic of file creation, matters are rather complicated. It is clear that the ability to create files in the UULP environment is extremely desirable. It is also clear that using mail to a fake address to get the file created, then renaming the "unsent mail" file is too byzantine to expect users to do. Unfortunately, it is not clear exactly what the alternative is. That is, it's fairly clear that we need a common editor, but it's not at all clear which editor it should be.
ファイル作成の話題に関して、問題はかなり複雑です。 UULP環境でファイルを作成する能力が非常に望ましいのは、明確です。 また、ファイルを作成させるのににせのアドレスにメールを使用して、次に、「unsentメール」ファイルを改名するのがユーザがすると予想できないくらい複雑であるのも、明確です。 残念ながら、代替手段がまさに何であるかが明確ではありません。 すなわち、私たちが一般的なエディタを必要とするのが、かなり明確ですが、それがどのエディタであるべきであるかが全く明確ではありません。
Padlipsky [Page 12] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[12ページ]RFC666
Two widely-known editors come to mind: TECO and QED. However, not everybody has them. Even if everybody did, the "dialects" problem is bound to be a large one. Even if all the relevant system programmers could agree, there remains the question of whether the intended user population would be willing to bother learning a language as complex as TECO or QED. Therefore an optional UULP command to be called "neted" is proposed. (See also RFC 569.) This editor is a line- oriented context editor (no "regular expressions", but also no line numbers). It is copiously documented in Chapter 4 or the Multics Programmers' Manual, including an annotated listing of the (PL/I) source code. A simple user's guide has been prepared (see Appendix 3). Several implementations already exist, and commitments have been made for more. It may also be repugnant to some of the system programmers who would be called upon to implement it -- which is why it is optional, until and unless higher authority makes it mandatory.
2人の広く知られているエディタが思い浮かびます: TECOとQED。 しかしながら、みんなはそれらを持っているというわけではありません。 みんながそうしたとしても、「方言」問題は大きいものであることが制限されています。 すべての関連システム・プログラマが同意できても、対象とする使用者人口が、TECOかQEDと同じくらい複雑な言語を学ぶのを苦しめても構わないと思うだろうかどうかに関する問題は残っています。 したがって、"netedする"であると呼ばれるべき任意のUULPコマンドは提案されます。 (また、RFC569を見てください。) このエディタは系列の指向の文脈エディタ(「正規表現」でないのにもかかわらず、また行番号がでもない)です。 それは第4章かMultics ProgrammersのManualにおびただしく記録されます、(PL/I)ソースコードの注釈されたリストを含んでいて。 簡単な使用手引書は準備されました(Appendix3を見てください)。 いくつかの実装が既に存在しています、そして、詳しい情報については、公約をしました。 そして、また、訪問されるシステム・プログラマの何人かに、それを実装するのもいとわしいかもしれません--それが任意である理由がどのであるかより高い権威で義務的にならない場合。
Other Protocols
他のプロトコル
The nominal initial impetus for proposing a UULP was to allow new Network user protocols to be invokable through a common mechanism, rather than requiring a new responding mechanism to be built for a new contact socket for each new protocol. Although this goal has been shunted into the background by the admission of the true goal of the UULP, it has not been dropped completely. Therefore, to enter the FTP Server environment, the UULP command is "ftp"; to enter the RJE Server environment, the UULP command is "rje". Exit is as per the respective protocols. (Where possible, exit should be back to the UULP environment.)
UULPを提案するための名目上の初期の起動力は新しい応じるメカニズムがそれぞれの新しいプロトコルのための新しい接触ソケットのために造られるのが必要であるというよりも新しいNetworkユーザプロトコルが一般的なメカニズムを通してむしろ「呼び出-可能」であることを許容することでした。 この目標はUULPの本当の目標の入場でバックグラウンドに転じましたが、それは完全に下げられるというわけではありませんでした。 したがって、FTP Server環境に入るために、UULPコマンドは"ftp"です。 RJE Server環境に入るために、UULPコマンドは"rje"です。 出口がそれぞれのプロトコルに従ってあります。 (UULP環境には出口が可能であるところに、あるべきです。)
Invoking Foreign Programs
外国プログラムを呼び出します。
There are two broad contexts in which it is desirable to cause a specific local program to be invoked from the common command environment: The User side of the connection may itself be a program, and the desired Server side program a specifically cooperating one; this is the more sophisticated context, of course. The less sophisticated context assumes that the User side is a "live" user, and the desire is to invoke a compiler or an object program the user has already compiled in the common language -- again as a convenience to the user so that he may operate in a sort of "Server-transparent" mode. (The latter case also covers "batch" use of the Server; see below.) In both contexts, the important role of the UULP is to specify the mechanisms through which the particular programs may be invoked, irrespective of the idiosyncrasies of the Servers' command languages.
特定のローカルのプログラムが一般的なコマンド環境から呼び出されることを引き起こすのが望ましい2つの広い文脈があります: 接続のUser側面がそうするかもしれない、それ自体、プログラム、および必要なServerが横であったなら、明確に協力関係を持っているものをプログラムしてください。 これが、より洗練された文脈である、もちろん。 それほど洗練されなかった文脈は、願望がUser側が「ライブな」ユーザであり、ユーザが一種の「サーバ透明な」モードで働くことができるように再び便利として共通語で既にユーザにコンパイルしたコンパイラかオブジェクトプログラムを呼び出すことであると仮定します。 (また、後者のケースはServerの「バッチ」使用をカバーしています; 以下を見てください。) 両方の文脈では、UULPの重要な役割は特定のプログラムが呼び出されるかもしれないメカニズムを指定することです、Serversのコマンド言語の特異性の如何にかかわらず。
Padlipsky [Page 13] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[13ページ]RFC666
Programming languages are much too big a problem to tackle here. However, assuming that a user somehow manages to create a source program, he still wants some commonality of spelling in invoking the appropriate compiler, or even the object program. As an optional but strongly recommended UULP command, then, "call name" should invoke object program name (where the named program may be a "native" command with arguments specified as appropriate). The values "pl1", "-basic", "-fortran", "-lisp", etc., should be recognized as requesting the invocation of the appropriate language processor (to operate on a named source file or interpretively/interactively if no source file was named), with "reasonable" defaults in effect. Note that this all is meant to imply that "native" commands are not directly invokable from the UULP environment (other than by "call"), to avoid potential naming conflicts between system commands and new UULP commands.
言語をプログラムして、多くがここで取り組む大き過ぎる問題ですか? しかしながら、ユーザがどうにか原始プログラムを作成すると仮定して、彼は適切なコンパイラ、またはオブジェクトプログラムさえ呼び出すのにおいてまだスペルの何らかの共通点が欲しいです。 そして、任意の、しかし、強くお勧めのUULPコマンドとして、「呼び出し名」はオブジェクトプログラム名(命名されたプログラムが議論が適宜指定されている「ネイティブ」のコマンドであるかもしれないところ)を呼び出すべきです。 「pl1"、「基礎」、"-fortran"、「舌足らず」などが「妥当な」デフォルトが有効な状態で適切な言語プロセッサ(指定されたaを作動させるには、ソースファイルが全く命名されなかったなら、インタラクティブにファイルか解釈的/の出典を明示する)の実施を要求しながら、認められるべきである」値。 これがすべて、「ネイティブ」のコマンドがシステム・コマンドと新しいUULPとの衝突をコマンドと命名する可能性を避けるためにUULP環境(「呼び出し」を除いた)から直接「呼び出-可能」でないことを含意することになっていることに注意してください。
Note that the "call" command in the UULP environment constitutes a
rubric for "parallel" computation, given any ad hoc convention for
the return of completion information. (Writing on the Telnet
write socket plus 2 would seem appropriate, provided the initiator
has the ability to "listen" for the rfc; but even a response in
the data stream as a special-cased program is assumed on the
"user"side anyway.)
UULP環境における「呼び」コマンドが「平行な」計算のために見出しを構成することに注意してください、完成情報の復帰のためのどんな臨時のコンベンションも考えて。 (2は適切に見えるでしょう、創始者にrfcのために「聴く」能力があるなら; 書き続けて、Telnetはソケットを書いて、しかし、特別にケースに入れられたプログラムとしてのデータ・ストリームにおける応答さえ「ユーザ」側でとにかく想定されます。)
Other Matters
他の件
The topic of "batch" mode merits some attention. As with the file manipulation commands, more consultation is necessary for a firm spec. However, I suspect that a "-batch" control argument to login should initiate batch mode processing by the Server, and given the call and identify commands all we might then require is a convention for designating the output file in order to return it via a copy command in the "job" itself (if output is to be returned rather than stored at the Server). Of course, -batch will probably need some substructure as to password and timing matters. More details will emerge in this area in future iterations.
「バッチ」モードの話題は何らかの注意に値します。 ファイル操作命令のように、より多くの相談が堅い仕様に必要です。 しかしながら、私は、ログインする「バッチ」コントロール議論がServerによるバッチ・モード処理を開始するべきであると疑います、そして、呼び出しと特定コマンドを考えて、次に私たちが必要とするかもしれないすべてが、「仕事」自体におけるコピーコマンドでそれを返す(出力がServerに保存されるよりむしろ返すことであるなら)ために出力ファイルを指定するためのコンベンションです。 もちろん、バッチはたぶんパスワードとタイミングの件に関して何らかの基礎を必要とするでしょう。 その他の詳細は今後の繰り返しにおけるこの領域に現れるでしょう。
An admittedly fictionalized scenario might look like this:
明白に脚色されたシナリオはこれに似るかもしれません:
login Me -batch -pw xxx -shift 3 copy *452<me>source.text source.pl2 call -pl2 source call source input output identify Me2 yyy copy output *555>root>Me>output452 logout
ログインMeバッチ-pw xxxシフト3が*452<をコピーする、私、ソース入出力がMe2 yyyコピー出力*555>根の>Me>output452を特定するという>source.text source.pl2呼び出し-pl2ソース要求はログアウトします。
Padlipsky [Page 14] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[14ページ]RFC666
where user "Me" wants the Server receiving the commands (either directly from him at a TIP or perhaps from some other Server on which he has created a file containing them) to set up a batch job for him, with password "xxx", to be run on Shift 3 (whenever that is). The job first copies file "source.text" from directory "<me>" on Host 452 into local file "source.pl2", then compiles it with the local PL2 compiler, executes it (assuming a "Not found" response would go into a known file if compilation had failed) with specified arguments (presumably the names of files for input and output), then copies the "output" file to Host 555's file hierarchy at the indicated place, using the user identifier "Me2" and the password "yyy". It's not elegant, but it ought to work.
どこ、ユーザ、「私、」 ServerにShift3に実行される(それがそうであるときはいつも)ために、彼のために"xxx"というパスワードでバッチ・ジョブをセットアップするコマンド(恐らくある他のServerからの直接TIPの彼、または、彼がそれらを含むファイルを作成した)を受け取って欲しいか。 仕事の第一刷がディレクトリから"source.text"をファイルする、「<、私、>、」、ローカルファイルへのHost452、「source.pl2"、その時がローカルのPL2コンパイラでそれをコンパイルして、指定された主張(おそらく入出力のためのファイルの名前)でそれ(編集が失敗したなら、aが応答を「見つけなかった」と仮定するのが知られているファイルを調べる)を実行して、Host555のファイルの階層構造への「出力」ファイルはその時、「Me2"とパスワードの"yyyする"です。」ユーザ識別子を使用する示された場所にコピーされます。 上品ではありませんが、それは働くべきです。
Finally, on the topic of logging out, the UULP command is "logout". The Server must close the Telnet connection after doing whatever is appropriate to effect a logout. To retain the Telnet connection, "logout -save". Having the Server close is viewed as a convenience for the user, in that it spares him the necessity of causing his User Telnet to close. It is also desirable for program-driven applications, so as not to leave the connections "dangling" and not to require possibly complex negotiations with the User side to break the connection.
最終的に、ログアウトする話題に関して、UULPコマンドは「ログアウトしてください」です。 必須がaに作用するのが適切であることなら何でもしながらTelnet接続を終えるServerはログアウトします。 Telnet接続を保有するために「ログアウト、-節約してください、」 近くにServerを持っているのはユーザのための便利として見なされます、彼のUser Telnetが閉じることを引き起こすという必要性から彼を開放するので。 また、プログラム駆動のアプリケーションに、それも接続が「ぶらぶらしている」ままにしないように望ましいです、そして、Userとのことによると複雑な交渉を必要としないのに、電話を切るために面があります。
APPENDIX 1. THE COMMON COMMAND SUBSET
付録1。 一般的なコマンド部分集合
Syntax Opt
構文は選ばれます。
I. "Set-up" Commands
I.「セットアップ」コマンド
login id arg The id may be Network-wide or Host-specific. "*free" is reserved. The arg may be "-mail", "-who", "-concom", "-batch", or may be absent. Result is to be either logged in or passed off to appropriate daemon.
ログインイドはイドをargします。Network全体である、またはHost特有であるかもしれません。 「自由な*」は予約されています。 または、argが「メール」であるかもしれない、「-、だれ、」、"-concom"、「バッチ」、休むかもしれません。 結果は、デーモンを当てるためにログインされるか、またはそらされることです。
prompt char Specifies that char is to become or precede the normal prompt message. Acceptable prior to login.
焦げる迅速な炭のSpecifiesは正常な迅速なメッセージになることになっているか、または先行することになっています。 ログインの前に許容できます。
erase char X Specifies that char is the erase character. Invocation with no argument reverts to default.
焦げる抹消炭のX Specifiesは消去文字です。 議論のない実施は、デフォルトとするために戻ります。
kill char X
炭Xをだめにしてください。
Padlipsky [Page 15] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[15ページ]RFC666
Specifies that char is the kill character. Invocation with no argument reverts to default.
炭が獲物キャラクタであると指定します。 議論のない実施は、デフォルトとするために戻ります。
eol char X Specifies that char is the newline character. Invocation with no argument reverts to default.
焦げるeol炭のX Specifiesはニューラインキャラクタです。 議論のない実施は、デフォルトとするために戻ります。
local Enter the local command environment.
地方の地方のEnterは環境を命令します。
ftp Enter the FTP environment.
ftp Enter、FTP環境。
rje Enter the RJE environment. logout Logout and sever the Telnet connection.
そして、rje Enter、RJE環境、ログアウト、Logout、Telnet接続を断ち切ってください。
logout -save Logout but keep the Telnet connection.
ログアウトしてください。Telnetが接続であることを保つのを除いて、Logoutを取っておいてください。
map Apply the case-mapping conventions of Appendix 2. Required on Hosts to which case is significant.
地図ApplyはAppendix2のケースを写像するコンベンションです。 ケースが重要であるHostsでは、必要です。
identify id arg X Specifies that id is to be used as the user identifier in any "fanout" logins required. If arg is specified, it is to be either the password to be used in such logins or "-pw", in which case the Server will furnish a mask or negotiate the Hide Your Input Telnet option; if no arg, then no password is to be furnished on fanout logins. Default id is "*free".
どんな"fanout"ログインでもユーザ識別子が必要であったように使用されるためにイドがあるイドarg X Specifiesを特定してください。 argが指定されるなら、それがそのようなログインに使用されるべきパスワードか"-pw"のどちらかであることになっている、その場合、Serverはマスクを提供するか、またはHide Your Input Telnetオプションを交渉するでしょう。 argでないなら、どんなパスワードもfanoutログインのときに提供されないことです。 *を有でない「デフォルトイドはそうです」、」
II. Communications Commands
II。 コミュニケーションコマンド
readmail Type out "mailbox".
readmail Typeの出かけている「メールボックス。」
readmail (id) -at host X Type out "mailbox" on remote Host host. Multiple Hosts may be specified, separated by spaces (blanks).
readmail(イド)、-、リモートHostホストの上でX Typeの出かけている「メールボックス」を接待してください。 空間(空白)によって、複数のHostsが指定されて、切り離されるかもしれません。
Padlipsky [Page 16] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[16ページ]RFC666
Implies ability to change working directory at host to directory implied by known user identifier, or (optionally) by id.
イドは知られているユーザ識別子によって含意されたディレクトリへのホストにおいて、または、(任意に)働くディレクトリを変える能力を含意します。
readmail -all XX
readmail、-すべて、XX
Search for mail. Extremely optional.
メールを検索してください。 非常に、任意です。
mail id
Collect input until line consisting of
only a period (".") for mailing to local
user specified by id.
期間だけから成る系列までイドCollect入力を郵送してください、(「」、)、イドによって指定された地元のユーザへの郵送のために。
mail -f file id Send contents of specified file to specified local user.
指定されたファイルの-fファイルイドSendコンテンツを指定された地元のユーザに郵送してください。
mail id -at host
Collect input until line consisting of
only a period (".") for mailing to remote
user(s) at specified Host(s). Both id and
host may be multiple, separated by spaces.
(If multiple, they should be taken pairwise.)
メールイド、-、期間だけから成る系列まで入力されたCollectを接待してください、(「」、)、指定されたホストのリモート・ユーザーへの郵送のために。 イドとホストの両方が、空間によって複数であって、切り離されるかもしれません。 (複数なら、それらは取られた対状であるべきです。)
mail -f file id -at host Send contents of specified file to specified remote user(s).
メール-fファイルイド、-、指定されたファイルのSendコンテンツを指定されたリモート・ユーザーに接待してください。
who The generic who's logged in command.
だれ、中にコマンドを登録したジェネリック。
who id Is id logged in? Constrained responses.
イドIsイドはだれにログインしましたか? 強制的な応答。
who id -at host Is the specified user logged in at the specified host. Constrained responses.
だれ、イド、-、指定されたユーザが指定されたホストでログインしたIsを接待してくださいか。 強制的な応答。
concom -on Enable console to console communications.
concomにオンである、コンソールコミュニケーションへのEnableコンソール。
concom -off Disable console to console communications.
オフDisableがコンソールコミュニケーションに慰めるconcom。
concom id
Send messages to specified local user
until line consisting of only a period (".").
指定された地元の期間だけから成る系列までのユーザへのconcomイドSendメッセージ、(「」、)。
Padlipsky [Page 17] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[17ページ]RFC666
concom id -at host Send messages to specified remote user.
concomイド、-、指定されたリモート・ユーザーにSendメッセージをホスティングしてください。
III. File Commands
III。 ファイルコマンド
type path Type out the contents of the specified file. Pathname may be local or Network-wide. Default to current working directory.
指定されたファイルのコンテンツから経路Typeをタイプしてください。 パス名は、ローカルである、またはNetwork全体であるかもしれません。 現在の働くディレクトリをデフォルトとしてください。
listdir List the contents of the current working directory. (Local format acceptable.)
listdir List、現在の働くディレクトリのコンテンツ。 (許容地方の形式。)
listdir path List the contents of the specified directory.
listdir経路List、指定されたディレクトリのコンテンツ。
rename old new Change the specified file's name as indicated.
示されるように古い新しいChangeを指定されたファイルの名前に改名してください。
addname old new X Give the specified file the specified extra name.
addnameの古い新しいX Give、指定は指定された付加的な名前をファイルします。
delete path
Get rid of the specified file.
("Expunge" if necessary.)
指定されたファイルが取り除かれた経路Getを削除してください。 (必要なら、「梢消します」。)
copy from to Make a copy of the file specified by the first pathname at the second pathname.
ファイルのコピーが2番目のパス名における最初のパス名で指定したMakeに模造してください。
link from to X If your file system has such a concept, make a "link" between the two pathnames. If no second argument, use same entry name in working directory.
X Ifへのあなたのファイルシステムからのリンクには、そのような概念があって、2つのパス名の間の「リンク」を作ってください。 2番目の議論でないなら、働くディレクトリで同じ入口名を使用してください。
status path st X If your file system has such a concept, give status information about the specified file or directory.
状態経路、X第If、あなたのファイルシステムには、そのような概念があって、指定されたファイルかディレクトリの状態情報をお願いします。
changewd path X If no argument, return to the "home" directory.
changewd経路X If、議論がない、「ホーム」ディレクトリへのリターン。
typewd Type out the pathname of the current working directory.
現在の働くディレクトリのパス名からのtypewd Type。
neted path
経路をnetedしました。
Padlipsky [Page 18] RFC 666 Unified User-Level Protocol November 1974
ユーザレベルプロトコル1974年11月に統一されたPadlipsky[18ページ]RFC666
See Appendix 3.
付録3を見てください。
IV. Invoking "Native" Programs
IV。 「ネイティブ」のプログラムを呼び出します。
call name (args) Invoke the specified program with the specified arguments (if any). The following names are reserved to indicate the invocation of the corresponding language processor: "-pl1", "-basic", "-fortran", "-lisp". (If no source file indicated, invoke "interpretively" if possible.)
指定された主張(もしあれば)に(args)が指定されたプログラムを呼び出す名前に電話をしてください。 以下の名前は対応する言語プロセッサの実施を示すために予約されます: 「-pl1"、「基礎」、"-fortran"を「舌たらずに話されます」。」 (どんなソースファイルも、できれば、"解釈的"を呼び出すように示さなかったなら。)
V. On-line Documentation
V.のオンラインドキュメンテーション
help name Type out information about the specified UULP command. If name is "-sys", type out information about how to use the local system's help mechanism; if "uulp", about the local system's UULP implementation. If no name given, describe the command itself.
指定されたUULPコマンドの情報から名前Typeを助けてください。 名前が"-sys"であるなら、どうローカルシステムの助けメカニズムを使用するかの情報をタイプで打ってください。 ローカルシステムのUULP実装の周りの"uulp"であるなら。 名前当然のことでないなら、コマンド自体について説明してください。
APPENDIX 2. MAP COMMAND CONVENTIONS
付録2。 地図コマンド規約
This appendix will eventually contain the case-mapping conventions detailed in RFC 411.
この付録は結局、RFC411で詳細なケースを写像するコンベンションを含むでしょう。
APPENDIX 3. EDIT COMMAND REQUESTS
付録3。 編集コマンド要求
This appendix will eventually contain descriptions of the neted command requests (a draft of which now exists), or a reference to the Resource Notebook version, if that gets published first. For now, it should be sufficient to point out that the requests are basically locate, next, top, change, save, and quit -- i.e., it's the "old- fashioned" flavor of context editor.
この付録は結局netedコマンド要求(それの草稿は現在、存在する)の記述、またはResource Notebookバージョンの参照を含むでしょう、それが最初に発行されるなら。 当分、要求がやめてください--次に基本的に場所を見つけてください、先端、変化が節約されて、すなわち、それが文脈エディタの「作成された老人」特色であるということであると指摘するのは十分であるべきです。
[Optical character recognition and initial proofreading performed 11/20-21/04 by The Author. A few original typos were corrected; some may remain.]
[光学文字認識と初期の校正はAuthorで11/20-21/04に働きました。 いくつかのオリジナルの誤植が修正されました。 或るものは残るかもしれません。]
Padlipsky [Page 19]
Padlipsky[19ページ]
一覧
スポンサーリンク
