RFC569 日本語訳

Network Working Group                                   Mike Padlipsky
RFC 569/ NET-USING Memo 1                                    NET-USING
NIC # 18972                                           October 15, 1973

1973年10月15日のネットを使用するネットをネットワークワーキンググループマイクPadlipsky RFC569/使用するメモ1NIC#18972

             NETED: A Common Editor for the ARPA Network

NETED: アーパネットのための一般的なエディタ

BACKGROUND

バックグラウンド

At the recent Resource Sharing Workshop, there was a somewhat
surprising degree of consensus on what I had anticipated would the
least popular aspect of the my "Unified User-Level Protocol" proposal:
A number of the attendees agreed without argument that it would be
a good thing to have "the same" context editor available on all
Servers -- where "the same" refers, of course, to the user interface.
We even agreed that "NETED" seemed to be a plausible common name.  In
view of the fact that the rest of the proposal didn't seem to capture
anybody's imagination, though, it seemed to be a useful notion to
separate out the common editor and make it the subject of a
stand-alone proposal.

いくらか驚異的な度の最も最少にポピュラーな状態でそうする私が予期したことに関するコンセンサスが最近のResource Sharing Workshopに、あった、局面、私の「統一されたユーザレベルプロトコル」提案: 多くの出席者がすべてのServersに手があいている「同じ」文脈エディタがいるのが、もちろん「同じくらい」が参照されるところの良いものであるだろうという主張なしで同意しました、ユーザーインタフェースに。 私たちは、"NETED"が、もっともらしい一般名であるように思えたのに同意さえしました。 もっとも、提案の残りがだれの想像をも得るために思えなかった事実から見て、一般的なエディタを分離して、それをスタンドアロンの提案の対象にするのが、役に立つ概念であるように思えました。

My resolve to come up with the following was further strengthened at
the the organizing meeting of the Network User Interest Group, which
followed the Workshop.  Being primarily concerned with user issues,
this group was downright enthusiastic about the prospect of a common
editor.  Indeed, this proposal has been reviewed by the group and is
endorsed by it.

以下を思いつく私の決心はNetwork User Interest Groupの結団ミーティングでさらに強化されました。(Network User Interest GroupはWorkshopに続きました)。 主としてユーザ問題に関係があるので、このグループは一般的なエディタの見通しに関して全く熱心でした。 本当に、この提案は、グループによって見直されて、それによって是認されます。

REASONS

理由

The need for a common editor might well be obvious to many readers.
They are encouraged to skip this section, which is for the benefit of
those who don't already see the light.

多くの読者には、一般的なエディタの必要性はたぶん明白でしょう。 彼らがこのセクションをスキップするよう奨励されます。(セクションは既に光を見ない人の利益のためのものです)。

In the first place, it's almost axiomatic that to use a time-sharing
system, you have to be able to create files (/"datasets"/"segments").
Even if you're only using the Network to send "mail", you'd still like
to be able to create a file separately, so as to be able to edit it
before sending.  And if you want to write a program -- or even make a
"runoff" source file -- you simply must be able to use some editor
command on the system at hand.

第一に、時分割システムを使用するために、あなたがファイル(/「データセット」/「セグメント」)を作成できなければならないのは、ほとんど自明です。 「メール」を送るのにNetworkを使用しているだけであっても、あなたは、発信する前にそれを編集できるように別々にまだファイルを作成していたがっています。 そして、プログラムを書きたい、または「決勝戦」ソースファイルを作っても、あなたは単に手元のシステムにおける何らかのエディタコマンドを使用できなければなりません。

Unfortunately, there are even more editors than there are systems;
and each one has it own conventions and peculiarities.  So "Network
users" (who use several Servers, as opposed to those who use the
Network only to access a particular system all the time) are faced
with the unpleasant chore of developing several sets of incompatible
reflexes if they want to get along.  This can certainly be done.  It
has been by a number of members of the Network Working Group.


残念ながら、システムがあるよりさらに多くのエディタがいます。 そして、各々はそれにコンベンションとユニークさを所有させます。 それで、くらしていきたいなら、「ネットワーク利用者」(Networkを使用する絶えず特定のシステムにアクセスする人と対照的に数個のServersを使用する)は展開している数セットの両立しない反射能力の人が嫌がる仕事に直面しています。 確かに、これができます。 Network作業部会の会員数に従って、それはありました。

NETED SPEC                                                        p.2

NETED SPEC p.2

The real kicker, however, comes when we consider the needs of those
users -- who are coming into the Network community in ever-increasing
numbers -- who are not professional programmers.  They just want to
get some work done, "on the Net" (that is, irrespective of which
operating system they might be talking to).  They are likely to be
appalled rather than amused by having to learn a dozen ways of getting
to first base.  Therefore, it seems clear than not only do we need a
common editor, but we also need a simple common editor.

しかしながら、私たちがそれらのユーザ(絶えず増加する数(職業プログラマでない)でNetwork共同体に入っています)の必要性を考えるとき、本当の蹴る人は来ます。 彼らはいくらかの仕事をただ完了させたいです、「ネット」(すなわち、彼らがどのオペレーティングシステムと話しているかもしれないかの如何にかかわらず)で。 一塁に着く1ダースの方法を学ばなければならないことによって喜ぶというよりむしろそれらは驚きそうです。 したがって、それはまた、私たちが一般的なエディタを必要とするだけではなく、純真な一般的なエディタを必要とするより明確に見えます。

CHOICES

選択

Simplicity is not the only criterion for rejecting the apparently
"obvious" choice of either TECO or QED.  (That it is a strong factor
is indicated by the old test of "Consider explaining it to a naive
secretary -- now consider explaining it to a corporation president.")
Perhaps even worse is the problem of "dialects".  That is, features
vary across implementations, and settling on a common set of features
(or dialect) is likely to be a very hard task, for programmers tend to
get very fond of their familiar goodies.  Besides, both TECO and QED
have their own strong (/fanatic) advocates, who's probably never be
willing to settle for the other one.  Further, not every system has
both, and implementing the other is a fairly large job even if the NWG
could agree on which (and how much).

簡単さは、TECOかQEDのどちらかの明らかに「明白な」選択を拒絶するための唯一の評価基準ではありません。 (それが強い要素であることは「ナイーブな秘書にそれについて説明すると考えてください--今、会社の社長にそれについて説明すると考えてください」の古いテストで示されます。) 恐らくさらに悪いのは、「方言」の問題です。 すなわち、特徴は実現の向こう側に異なります、そして、一般的なセットの特徴(または、方言)について決めるのは非常に確実なタスクである傾向があります、プログラマが、彼らのなじみ深いうまいものが非常に好きになる傾向があるので。 そのうえ、TECOとQEDの両方には、それら自身の(/熱狂者)強い支持者がいます。(その支持者は、もう片方を受け入れることをたぶん決して望まないことです)。 あらゆるシステムには、さらに、両方があるというわけではありません、そして、NWGがどれに同意できても、もう片方を実行するのは、かなり大きい仕事です。(どれくらい多く。)であるか。

At any rate, the difficulties seem overwhelming when it comes to
choosing a high-powered editor as the common editor.  Therefore, I
tried to think of a nice low-powered editor, and it suddenly occurred
to me that I not only knew of one, but it was even fairly well
documented (!).  The editor in question is known on Multics as "eds"
(the same member of the "ed" family of editors which started on
CTSS), a line-oriented context editor (no "regular expressions", but
also no line numbers).  It is used as an extended example of
programming in the Multics environment in Chapter 4 of the Multics
Programmers' Manual, which gives an annotated PL/I listing of the
actual working program.  It is simple to learn and should be quite
easy to implement,  PL/I version serves as a detailed model with only
equivalent system calls and choice of language to worry about.  I urge
its adoption as the common Network editor, to be known on all
participating Servers as "NETED" and/or "neted".

いずれにせよ、一般的なエディタとして有能なエディタを選ぶこととなると、困難は圧倒的に見えます。 したがって、私は親切な低く動力付きのエディタを思おうとしました、そして、突然、私が1を知っていただけではありませんが、それが公正によく記録された(!)でさえあった思い出しました。 問題のエディタは"eds"(CTSSを始動したエディタの「教育」家族の同じメンバー)としてMulticsで知られています、線指向の文脈エディタ(「正規表現」でないのにもかかわらず、また行番号がでもありません)。 それは実際のワーキング・プログラムの注釈されたPL/Iリストを与えるMultics ProgrammersのManualの第4章のMultics環境でプログラムを作る拡張例として使用されます。 PL/Iバージョンは、同等なシステムコールと言語の選択だけがある詳細なモデルとして学ぶのが簡単であり、実行するのがかなり簡単であるはずであることを心配するのに勤めます。 私は、"NETED"としてすべて参加しているServersで知られている、そして/または、"netedする"であるために一般的なNetworkエディタとして採用を主張します。

DOCUMENTATION

ドキュメンテーション

In view of the fact that if "eds"/NETED is adopted only perhaps a
dozen members of the NWG will actually have to implement one, it seems
wasteful to distributed some 30 pages of the MPM to everyone --
especially since most of the parties concerned have access to an MPM
already.  (Another problem solved by not including it here is that of
whether I'd be violating copyright by doing so.)  The exact reference
is pp. 24-54 of Chapter 4 of Part I of the Multics Programmer's
Manual.


"eds"/NETEDが採用されるとNWGの恐らく1ダースのメンバーだけが実際に1つを実行しなければならないという事実から見て、特に関するパーティーの大部分が既にMPMに近づく手段を持つので、それは皆へのMPMのおよそ30ページで分配されるのに無駄に見えます。 (ここにそれを含んでいないことによって解決された別の問題は私がそうすることによって著作権を侵害するだろうかどうかに関するそれです。) 正確な参照はページです。 24-54 Multicsプログラマのマニュアルの一部Iの第4章について。

NETED SPEC                                                        p. 3

NETED SPEC p。 3

Anybody who needs a copy can let me know.  Although the emphasis in
the document is, naturally enough, on the Multics-specific aspects, I
believe that the listing is clear enough to serve as a model to
implementors without any great difficulty.  If we do get to the
implementation stage, I'll be glad to try to explain any non-obvious
system calls, either individually or in a follow-up memo.  But even
though we "initiate" where you "open", or we " call los_$read_ptr"
where you "IOT TTY" (or something), it shouldn't cause much trouble.
For that matter, some implementers might prefer to ignore the existing
program and simply work from the function specifications (below).

コピーを必要とするだれでも私に知らせることができます。 ドキュメントにおける強調がありますが、Multics特有の局面では、十分当然、私は、リストが少しも大きな困難なしで作成者に手本になるほど明確であると信じています。 私たちが実現ステージに着くと、個別か督促のメモにおけるどんな非明白なシステムコールについても説明しようとするでしょう。 呼び出しlos_$は_ptrに」 どこにあなたを読み込むか。しかし、私たちがどこを「開始するか」、しかし、あなたが「開く」、私たち、「それは、"IOT TTY"(例えば)と多くの問題を引き起こすべきではありません。 さらに言えば、いくらかのimplementersが既存のプログラムを無視して、機能仕様(below)から単に働くのを好むかもしれません。

LIMITATIONS

制限

It became abundantly clear during the course of the review of this
document by the User Interest Group that the limitations of NETED must
be acknowledged (even insisted upon) and explained here.  In the first
place, it must be emphasized that it is not being proposed as "THE"
Network editor.  Rather, it is an insistently simple-minded editor for
two major reasons:  1) it is meant for use mainly by non-professional
programmers, and 2) more important still, it is meant to be extremely
easy to implement.  Therefore, it seems far more important to go with
the published program, with all its warts, than to specify the
addition of new, undebugged features.  The idea is to make it
implementable in man-days by an average to average-plus programmer
instead of in man-weeks by a superstar programmer.

それは承認されていて(言い張られさえします)、ここで説明されて、NETEDの限界がそうしなければならないUser Interest Groupによるこのドキュメントのレビューのコースの間、はっきりと豊富になりました。 第一に、“THE"がエディタをネットワークでつなぐときそれが提案されていないと強調しなければなりません。 むしろ、2つの主要な理由でそれはあくまで純真なエディタです: 1) 使用のために、主に非職業プログラマ、および2で、)まだより重要です、実行するのが非常に簡単であることが意味されることが意味されます。 したがって、発行されたプログラムを伴うのははるかに重要に思えます、すべてのいぼで、新しくて、非デバッグされた特徴の添加を指定するより。 考えは男性週の代わりにスーパースタープログラマで-そのうえ、プログラマを平均するのを平均による人日で実行可能にすることです。

In the second place, the very act of adding new features is fraught
with peril.  To take some examples from the comments I received during
the review phase:  In the first draft, I inadvertently failed to
document the mechanism by which the ability to "go backwards" (i.e.,
to reverse the direction of the current-line pointer described below)
is actuated.  Several reviewers argued strongly for the inclusion of
such a mechanism; but, not knowing it was already "in" the code I
argued -- successfully -- for leaving it out, on the grounds that we
should stick to what's in the existing code, which is known to work as
published.  Even what to call such a new request would have been
debatable -- should it be "-" and become the only non-alphabetic name?
should it be "b" for "bottom"?  should "n" (for "next") become "+"?
And so on.  Although this particular issue turned out be a false
alarm, I've left it in to emphasize the sort of pitfalls we can get
into by haggling over particular "features".  Another familiar feature
is some sort of "read" request so that the file name need not be
specified as an argument to the command.  Then, of course, one would
also want a "create" or "make" request.  And perhaps a file delete
request?  It keeps going on and on.  The point, I think, is that if we
allow ourselves to go into "tinker mode" we could spend as many years
striving to achieve consensus on what features to add as we've spent
on Telnet or FTP ... and still not please everyone.  Therefore, I urge
the NWG to accept the contention that having a working model to use as

第二に、新機能を加えるまさしくその行為は危険について悲惨です。 コメントからいくつかの例を取るために、私はレビュー段階の間、受信しました: 最初の草稿では、私はうっかり、「後方に行く」(すなわち、以下で説明された現在行ポインタの指示を逆にする)能力は作動させられるメカニズムを記録しませんでした。 数人の評論家が強くそのようなメカニズムの包含について賛成の議論をしました。 しかし、それを知らないで、私たちが既存のコードにはあるものに執着するべきであって、既に“in"は私がそれを省くために首尾よく論争したコードでしたか?(発行されるように働くのが知られています) そのような新しい要求を呼ぶべきことは論争の余地がありさえしたでしょう--それは、「-」であり、唯一の非アルファベットの名前になるべきですか?「下部」への「b」であるべきですか?「n」(「次に」のための)が「+」になるべきであって、 など。 この特定の問題は判明しましたが、間違い警報になってください、そして、私は、私たちが特定の「特徴」について値段を交渉することによって強い興味をもつことができる落とし穴の種類を強調するために中にそれを残しました。 別の身近な特徴は、ファイル名が議論としてコマンドに指定される必要はないためのある種の「読んでください」要求です。 もちろん、そして、1つはまた、「作成」が欲しい、または要求を「作成するでしょう」。 そして、恐らく、ファイルは要求を削除しますか? それは絶え間なく続き続けます。 私は、ポイントが自分達を「鋳掛け屋モード」に入らせるなら私たちがTelnetかFTP…に費やしたとき加えるどんな特徴でコンセンサスを達成するか、そして、まだ皆を喜ばせていないように努力するのに私たちが同じくらい何年も費やすかもしれないということであると思います。 したがって、私は主張を受け入れる働きを持っているのが使用にモデル化するNWGを主張します。

NETED SPEC                                                     p. 4

NETED SPEC p。 4

a pattern is more  important than any particular additional features
(even  though I myself find "=" for "what's the current line's
number?" annoying to live without).

パターンはどんな特定の付加的な機能よりも重要です(私自らですが、生きるために煩わしい「現在行の番号は何ですか?」に関して「=」を見つけてください)。

RESPONSES

応答

For the benefit of those who don't want to plow through the functional
spec, this seems to be a good spot to indicate what appropriate
responses to this proposal would be.  Ideally, I'd like to hear from a
responsible system programmer at, say, TENEX, CCN, UCSD, UCSB,
AMES-67, one of the DEC 10/50 Hosts, and from any of the experimental
Servers who happen to be interested, that they think it's a fine idea
and why don't I log in next week to try their NETEDs.  Next most
desirable would be agreement in principle followed by specific
inquiries about "eds".  I would hope that haggling over specific
features wouldn't occur (as we're not trying to do a definitive
editor, just an easy, commonly implemented one based on an existing
implementation), but unfortunately I can't legislate such haggles out
of existence.  At the very least, I'd hope to either hear or see
reasoned arguments why it's not worth doing.  As usual, phone, mail
"mail" ("map.cn" in sndmsg, or "map cn" in "mail" on Multics) or RFC's
are the assumed media for responding.

機能的な仕様を骨折って進みたがっていない人の利益に関しては、これはこの提案への適切な応答が何であるかを示す良いスポットであるように思えます。 理想的に、たとえば、TENEXの責任があるシステム・プログラマ、CCN、UCSD、UCSB、エームズ-67、12月の10/50のものの1つからHostsを聞きたいと思います、そして、彼らがそれを考えるのは、たまたま興味を持っている実験的なServersのどれかからの、すばらしい考えです、そして、私はなぜ来週、彼らのNETEDsを試みるためにログインしませんか? 次に、最も望ましいのは、"eds"に関する特定の問い合せがいうことになった原則的合意です。 特定の特徴について値段を交渉するのが起こらないことを望んでいるでしょうが(私たちが決定的なエディタ、まさしく既存の実現に基づく簡単で、一般的に実行されたことをしようとしていないとき)、残念ながら、私は存在からそのような値切るのを制定できません。 少なくとも、私は、それがする価値がない推論された議論を聞くか、または見ることを望んでいるでしょう。 いつものように、電話、「メール」(sndmsgの"map.cn"、またはMulticsの「メール」による「地図cn」)またはメールのRFCのものが、応じるための想定されたメディアです。

USAGE

用法

(The following is intended to serve double-duty, as both a functional
spec now and -- with the addition of some examples -- a "users'
manual" later.  So if it seems to "tutorial", I'm sorry.  And if it
doesn't seem tutorial enough -- assuming the addition of examples --
please let me know.)

(そして、以下が現在両方としての二つの任務に機能的な仕様に役立つことを意図する、--、いくつかの例の添加--後での「ユーザのマニュアル。」 それで、「チュートリアル」に見えるならすみません。 --例の添加を仮定して、十分家庭教師に見えないならそして、私にお知らせください。)

As is typical of "context editors," the NETED command is used both for
creating new files and for altering already existing files -- where
"files" are named collections of character encoded data in the storage
hierarchy of a time-sharing system.  Consequently, NETED operates in
two distinct "modes" -- called "input mode" and "edit mode".

「文脈エディタ」の典型です、NETEDコマンドがともに新しいファイルを作成するのに使用されるということであり、「ファイル」がキャラクタの収集と命名されるところで既に既存のファイルを変更するために時分割システムの記憶階層でデータを暗号化するように。 その結果、NETEDは2異なった「モード」で作動します--「入力モードと編集モード」と呼ばれます。

When NETED is used to create a file (that is, when it is invoked from
command level with an argument which specifies the name of a file
which does not already exist in the user's "working directory"), it is
automatically in input mode.  It will announce this fact by outputting
a message along the lines of "File soandso not found.  Input."  Until
you take explicit action to leave input mode, everything you type will
go into the specified file.  (Actually, it goes into a "working copy"
of the file, and into the real file only when you indicate a desire to
have that happen.) To leave input mode, type a line consisting of only
a period and the appropriate new-line character:  ".<NL>", where <NL>
is whatever it takes to cause a Telnet New-Line to be generated from
your terminal

NETEDがファイルを作成するのに使用されるとき(すなわち、それはいつユーザの「働くディレクトリ」に既に存在しないファイルの名前を指定する議論でコマンドレベルから呼び出されますか)、それは中で自動的に入力されたモードです。 それは、「soandsoが見つけなかったファイル」の線に沿ってメッセージを出力することによって、この事実を発表するでしょう。 「入力します」。 あなたが入力モードを残すために明白な行動を取るまで、あなたがタイプするすべてが指定されたファイルを調べるでしょう。 (実際に、ファイルの「働くコピー」に入って、それを持つ願望を示すだけときには実際のファイルの中に、起こってください。) 入力モードを残すには、期間だけから成る線と適切な改行文字をタイプしてください: <NL>がTelnet New-線があなたの端末から発生することを引き起こすのに要することなら何でもであるか「. <NL>」

NETED SPEC                                                        p. 5

NETED SPEC p。 5

After leaving input mode, you are in edit mode.  Here, you may issue
various "requests" which will allow you to alter the contents of the
(working) file, re-enter input mode if you wish, and eventually cause
the file to be stored.  Note that edit mode is entered automatically
if the argument you supplied to NETED specified an existing file.
Regardless of how it was entered, being in edit mode is confirmed by
NETED's outputting a message of the form "Edit".  Editing is performed
relative to (conceptual) pointer which specifies the current line, and
many requests pertain to either moving the pointer or changing the
contents of the current line.  (When edit mode is entered from input
mode, the pointer is at the last line input; when entered from command
level, the pointer is at the "top" of the file.)

入力モードを残した後に、あなたは編集モードでいます。 ここで、あなたはあなたに(働いていること)のファイルのコンテンツを変更して、あなたが願うなら入力モードに再入して、結局ファイルが格納されることを引き起こさせる様々な「要求」を、発行できます。 あなたがNETEDに供給した議論が既存ファイルを指定したなら編集モードが自動的に入られることに注意してください。 それがどう入られたかにかかわらず、NETEDがフォーム「編集」に関するメッセージを出力することによって、編集モードであるのは確認されます。 編集は現在行を指定する(概念的)のポインタに比例して実行されます、そして、多くの要求がポインタを動かすか、または現在行のコンテンツを変えながら、どちらかに関係します。 (編集モードが入力モードから入られるとき、最終ライン入力にはポインタがあります; コマンドレベルから入られると、ポインタがファイルの「先端」にあります。)

NETED's edit mode requests follow, in order intended to be helpful.
Two important reminders:  the requests may only be issued from edit
mode, and each one "is a line" (i.e., terminates in a new line /
carriage return / linefeed is appropriate to the User Telnet being
employed).  SYNTAX NOTE:  If the request takes an argument, there must
be at least one space (blank) between request's name and the argument.

NETEDの編集モード要求は役立っていることを意図するオーダーで続きます。 2つの重要な注意点: すなわち、要求が編集モードから出されるだけであるかもしれなく、各々が「線である」、(終わり、aでは、復帰改行/復帰/ラインフィードがUser Telnet就職に適切である、) 構文注意: 要求が議論を取るなら、要求の名前と議論の間には、少なくとも1つのスペース(空白の)があるに違いありません。

1.  n m

1. n m

For unsigned m, the n(ext) request causes the pointer to be moved
"down" m lines.  If m is negative, the pointer is moved "up" m lines.
If m is not specified, the pointer is moved one line.  If the end of
the file is reached, an "End of file reached by n m" message is output
by NETED; the pointer is left "after" the last line.

無記名のm、動く(ext)がポインタを要求するnに関しては、“down"mは立ち並んでいます。 mが否定的であるなら、ポインタはmが裏打ちする動く“up"です。 mが指定されないなら、ポインタは1つの動く線です。 ファイルの端に達しているなら、「n m達したファイルの終り」メッセージはNETEDによって出力されます。 ポインタはそうです。“after"を最終ラインに発ちました。

2.  l string

2. lストリング

The l(ocate) request causes the pointer to be moved to the net line
containing the character string "string" (which may contain blanks);
the line is output.  If no match is found, a message of the form "End
of file reached by l string" will be output (and the pointer will
have returned to the top of the file).  The search will not wrap
around the end of the file; however, if the string was above the
starting position of the pointer, a repetition of the locate request
will find it, in view of the fact that the pointer would have been
moved to the top of the file.  To find any occurrence of the string --
rather than the next occurrence -- it is necessary to move the pointer
to the top of the file before doing the locate (see following
request).

l(ocate)要求で、ポインタを文字列「ストリング」(空白を含むかもしれない)を含むネットの線に動かします。 線は出力です。 マッチが全く見つけられないと、「lストリングで達したファイルの終り」というフォームに関するメッセージは出力(ポインタはファイルの先頭に戻る)でしょう。 検索はファイルの端を巻きつけないでしょう。 しかしながら、ストリングであるなら上がポインタ、反復の開始位置であった、意志がそれを見つける要求の場所を見つけてください、ポインタがファイルの先頭に動かされただろうという事実から見て。 ストリングの次の発生よりむしろどんな発生も見つけるのに、する前にポインタをファイルの先頭に動かすのが必要である、場所を見つけます(次の要求を見ます)。

3.  t

3. t

Move the pointer to the top of the file.

ポインタをファイルの先頭に動かしてください。

NETED SPEC                                                       p. 6

NETED SPEC p。 6

4.  b

4. b

Move the pointer to the bottom of the file and enter input mode.

ポインタをファイルの下部に動かしてください、そして、入力モードを入れてください。

5.  "."

5. "."

Leave the pointer where it is and enter input mode.  (First new line
goes after current old line.)

それがそうであるポインタを残してください、そして、入力モードに入ってください。 (最初に、復帰改行は現在の古い線を追いかけます。)

6.  i string

6. iストリング

The i(nsert) request cause a line consisting of string (which will
probably contain blanks) to be inserted after the current line.  The
pointer is moved to the new line.  Edit mode is not left.

i(nsert)要求で、現在行後にストリング(たぶん空白を含む)から成る線を挿入します。 ポインタは復帰改行に動かされます。 編集モードが左にありません。

7.  r string

7. rストリング

The r(eplace) request causes a line consisting of string (probably
containing blanks) to replace the current line.

r(eplace)要求で、ストリング(たぶん、空白を含んでいる)から成る線は現在行を置き換えます。

8.  p m

8. p m

The p(rint) request causes the current line and the succeeding m - i
lines to be output.  If m is not specified, only the current line will
be output.  End of file considerations are the same as with "n".

p(rint)要求は現在行と続くmを引き起こします--iは、出力になるように立ち並んでいます。 mが指定されないと、唯一の現在行は出力でしょう。 ファイルの終り問題は「n」と同じです。

9.  c /s1/s2/ m g

9. c/s1/s2/m g

The c(hange) request is quite powerful, although perhaps a bit complex
to new users.  In the line being pointed at, the string of characters
s1 is replaced by the string of characters s2.  If s1 is void, s2 will
be inserted at the beginning of the line; if s2 is void, s1 will be
deleted from the line.  Any character not appearing within either
character string may be used in place of the slash (/) as a delimiter.
If a number, m, is present, the request will affect m lines, starting
with the one being pointed at.  All lines in which a change was made
are printed.  The pointer is left at the last line scanned.  If the
letter "g" is absent (after the final delimiter) only the first
occurrence of s1 within a line will be changed.  If "g" (for "global")
is present, all occurrences of s1 within a line will be changed.  (If
s1 is void, "g" has no effect.)  NOTE WELL:  blanks in both strings
are significant and must be counted exactly.  End of file
considerations are the same as with "n".

恐らく新しいユーザには少し複雑ですが、c(hange)要求はかなり強力です。 指し示される線では、キャラクタs1のストリングをキャラクタs2のストリングに取り替えます。 s1が空であるなら、s2は線の始めに挿入されるでしょう。 s2が空であるなら、s1は線から削除されるでしょう。 どちらの文字列の中にも現れないどんなキャラクタもデリミタとしてのスラッシュ(/)に代わって使用されるかもしれません。 数(m)が存在していると、要求は立ち並んでいて、指し示されるものから始まるmに影響するでしょう。 変更が行われたすべての線が印刷されます。 ポインタはスキャンされた最終ラインに残されます。 文字「g」が欠けると(最終的なデリミタの後の)、線の中のs1の最初の発生だけを変えるでしょう。 「g」(「グローバル」のための)が存在していると、線の中のs1のすべての発生を変えるでしょう。 (s1が空であるなら、「g」は効き目がありません。) 以下によく注意してください。 両方のストリングの空白を重要であり、まさに数えなければなりません。 ファイルの終り問題は「n」と同じです。

10.  d m

10. d m

The d(elete) request causes m lines, including the current one, to be
deleted from the working copy of the file.  If m is not specified, only
the current line is deleted.  The pointer is left at a null line above
the first undeleted line.  End of file considerations are the same as
with "n".

ファイルの働くコピーから削除されるために現在のものを含んでいて、mを引き起こす(elete)が、要求するdは立ち並んでいます。 mが指定されないなら、現在行だけが削除されます。 ポインタは最初の非削除された線の上の空行に残されます。 ファイルの終り問題は「n」と同じです。

NETED                                                           p. 7

NETED p。 7

11.  w

11. w

Write out the working copy into the storage hierarchy but remain in
NETED.  (Useful for those who fear crashes and don't want to lose all
the work performed.)

働くコピーを記憶階層に書き上げなさい、ただし、NETEDに残ってください。 (クラッシュを恐れて、仕事が実行したすべてを失いたがっていない人に役に立つ。)

12.  save

12. 節約してください。

Write out the working copy into the storage hierarchy and exit from
NETED.

NETEDから働くコピーを記憶階層と出口に書き上げてください。

Additional specs:

追加眼鏡:

a.  On Multics, type-ahead is permitted.  This approach is recommended
for all versions of NETED, but is of course not required as various
Servers' NCP Implementations may prohibit it; however:

a。 Multicsでは、先のタイプは受入れられます。 このアプローチは、NETEDのすべてのバージョンのために推薦されますが、様々なServersのNCP Implementationsがそれを禁止するかもしれないので、もちろん必要ではありません。 しかしながら:

b.  If an error is detected, the offending line is output, and pending
typeahead (if any) must be discarded (to guard against the possibility
of the pending request's being predicated on the success of erroneous
request).

b。 誤りが検出されるなら、怒っている線は出力です、そして、未定のtypeahead(もしあれば)を捨てなければなりません(未定の可能性に対して誤った要求の成功で叙述された要求の存在を警備する)。

c.  The command is not reinvokable, in the sense that work is lost if
you "quit" out of it via the Telnet Interrupt Process command or its
equivalent; indeed, quitting out is the general method of negating
large amounts of incorrect work and retaining the original file
intact.

c。 コマンドは「再-呼び出-可能」ではありません、あなたがTelnet Interrupt Processコマンドかその同等物でわかっていない状態で「やめる」なら仕事が無くなるという意味で。 本当に、やめて、多量の不正確な仕事を否定して、完全な状態で元のファイルを保有する一般的な方法が外にあります。

(When the time comes, I'll be glad to furnish examples for the users'
manual version; but for now, that's all there is.)

(時間が来るとき、ユーザの手動のバージョンのための例を提供するでしょう; しかし、当分、それによるすべてあるということです。)

NOTE

注意

It really does work, unsophisticated though it may be.  I think that
it's sufficient to get new users going, and necessary to give them a
fighting chance.  It would even be of utility within the NWG, for
those of us who don't like having to learn new editors all the time.
If anybody wants to try it, I'll make a version available to
"anonymous users" (see the Multics section in the Resource Notebook if
you don't already know how to get in our sampling account), under the
name "neted".  (*) (If you do try it, please delete files when done
with them.)

世慣れていないかもしれませんが、それは本当に働いています。 私は、勝ち目を彼らに与えるのが新しいユーザを開始させることができるくらい必要であると思います。 それはNWGの中のユーティリティのものでさえあるでしょう、絶えず新しいエディタを学ばなければならないのが好きでない私たちの人のために。 だれかがそれを試みたいなら、私はバージョンを「匿名のユーザ」に利用可能にするつもりです(既に私たちの標本抽出アカウントに入る方法を知らないなら、Resource NotebookのMultics部を見てください)、「netedした」という名前の下で。 (*) (それを試みるなら、それらでしたら、ファイルを削除してください。)

______________

______________

(*)  Knowledgeable Multics users with their own accounts can instead
link to >udd>cn>map>neted.  It is also there under the names "eds" if
you want to save typing a couple of characters.

(*) それら自身のアカウントをもっている博識なMulticsユーザは代わりに>地図>がnetedした>udd>cnにリンクできます。 あなたが2、3文字をタイプしながら節約したいなら、それがそこ、"eds"という名前の下にもあります。