[nos-bbs] The UPLOAD command in sysop and user meu

[Barry Siegfried]

["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:

> HMMM Barry, all your questions cause me to re-read the document and
> help files.
>
> I am left with the reality:
>
>   1) UPLOAD does not perform it's task in accordance with my original
> note.
>   2) so - WHERE in cyberspace is the content of <file> sent in response
> to UPLOAD?

Again, I'll ask:  Do you mean the 'upload' command at the system prompt
of the console?  I presume that you do.

> On Tue, 2007-04-03 at 15:33 -0400, Barry Siegfried wrote:
>
> > ["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:
> >
> > > I believe to have stumbled into something like a bug...
> > > Both myself and N1OXH are focusing on UPLOAD documentation detail.
> > >
> > > This is not the first time for the UPLOAD/DOWNLOAD subject on this
> > > reflector in the past year.
> >
> > I recall a discussion about UPLOAD/DOWNLOAD on the mailbox menu.
>
> The documentation change has worked out well.
>
> > > The previous go-round worked itself out nicely with a change to
> > > documentation and help files.
> > > This time I favor a change to the jnos vocabulary.
> > >
> > > The sysop menu contains UPLOAD (but not DOWNLOAD) as an ascii
> > > transport vehicle.
> >
> > When you say "sysop menu" are you talking about a human sitting
> > at the net> prompt on the console, or are you talking about going
> > to the remote net> prompt from inside a mailbox connection (for
> > which you *do* normally need "sysop" privileges)?
>
> Nope Barry - I'm talking about a terminal screen full of data not the
> person reading it, and the consequence of issuing the command UPLOAD to
> jnos.

I honestly still don't completely understand to what you're referring,
although I am now believing you are referring to being inside a system
console client session and not inside a mailbox connection.

> The prompt options are never "net>" but are:
>   sysop: "...jnos>"

Ok.  "jnos>" is what I referred to as "net>".  Some NOSs still display
"net>".  :)

>   user: "Area: k8rra (#3) >"

That is a user prompt in a mailbox connection.

> And the chain of commands leading to the jnos> prompt doesn't really
> matter...

Right.  But when the sysop is sitting at the remote jnos> prompt, he
is in effect sitting at the jnos> prompt of the system console (via
another process) and can execute many system commands that the human
sitting at the jnos> prompt of the system console can execute.  Some
of them which normally open client session screens or act upon client
sessions are (or should be) locked out to prevent them from executing
for the sysop at the remote jnos> prompt.

> > > Usage is pretty clear as documented,
>
> Boy - did I blow that observation...
>
> > > but jnos does not perform as documented on my host.
> > > "UPLOAD FILE" gives error messages in the context of "DOWNLOAD"
> > > errors.
> > > "UPLOAD FILE" does not toggle into a mode of accepting ascii data
> > > and placing it into a file.
> >
> > If you're talking about a human sitting at the net> prompt on the
> > console, then UPLOAD means "send ASCII from a file to a session".
>
> OK, so which session?  <session #> is not a parameter and the sysop
> console supports many sessions simultaneously.  And to what purpose?
> Like SOURCE command?

No.  The 'source' command is used to read system commands for JNOS
which are executed at the jnos> prompt of the system console.

Rather, an 'upload' goes to the "current" client session.  This is the
client session that was last visited by the human sitting at the jnos>
prompt of the system console.  It is the client session that will have
the asterisk in front of its number in the display produced by the
'session' command at the jnos> prompt of the system console (or the
jnos> prompt for the remote sysop).

> > I don't understand what you mean mean by "mode of accepting ascii
> > data".
> >
> > The RECORD command implements a DOWNLOAD mechanism.
>
> Not so much as RECORD supports a terminal stream "trace" mechanism.

No.  It supports a terminal client session stream "capture" mechanism.
When you 'record <filename>', you *capture* the client session ASCII
data into a file called <filename>.

> Great for debugging research or for making examples of operation for
> whatever purposes.

No.  'trace' is great for debugging research.  'record' is great for
capturing ASCII output from a terminal client session into a file for
later reading.

> Rotten for file content host-to-host transfer.

Yes, but good for simple ASCII operations, like cutting and pasting,
etc.

> AGAIN I make the same point for RECORD as I did for UPLOAD --> what
> <session #> is recorded?

Again, 'upload' goes to the "current" client session.  This is the
client session that was last visited by the human sitting at the jnos>
prompt of the system console.  It is the client session that will have
the asterisk in front of its number in the display produced by the
'session' command at the jnos> prompt of the system console (or the
jnos> prompt for the remote sysop).

And you're right.  The 'upload' (and 'record') commands *should* be
disabled at the remote jnos> prompt.

> > >>SNIP<<  I'm so confused.  :\
>
> So - I was confused too.  Under those conditions you don't have a
> prayer as staying on track...;-)
>
> If you have real life proper (intended?) use examples for UPLOAD
> please bring them on!

Let's say I am in a system console client session that is connected
to my favorite Net/Rom node.  I would like to sysop the node, reset
it and then connect again to load my initialization parameters.
Instead of typing all the initialization parameters manually, I can
instead have them stored in a file which I can then 'upload' to that
client session.  The Net/Rom node command processor will receive them
line by line from my client connection and assign the values I want
to use for node initialization.

Does this make sense to you?

73, de Barry, K2MF >>
           o
          <|>      Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net              |
| HomePage | http://www.mfnos.net/~bgs  |
+----------+----------------------------+
| Amprnet  | k2mf at k2mf.ampr.org         |
| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+