uploading

Dec 24 22:27 UTC 1992

What is the procedure for uploading files to grex?

response 2 of 81:

Dec 24 23:56 UTC 1992

To use (batch) Ymodem, the command is "rb" instead of "rz".  To use Xmodem,
"rx filename".  I haven't used Kermit on this system or for a long time,
myself.

Use "rz -?" to get more info.

response 4 of 81:

Dec 25 23:24 UTC 1992

Well, this is indeed an example; I will not attempt to cover all the
permutations.  For something I recently entered, I created a file on my
PC (called "DL.TP", following naming conventions from somewhere else
entirely).  Then, on Grex, I got to a shell prompt.  I entered "rb" to
start a Ymodem batch receive, and then with my emulator (Procomm shareware
version) started the send.  (In my case, I pressed PgUp, chose #6 for
Ymodem batch, and told it the filename.)

If the system is quite busy (umudos is sending usenet, say), I've had even
a tiny Ymodem transfer like this fail - the 1024-character packets overload
the system.  In that case, use Xmodem.

In about a minute my file was completely sent.  Because I used batch Ymodem,
there was no garbage at the end - zmodem will do this too.  (Xmodem usually
will pad to a multiple of 128 characters.)

I had CRs still in my file, since I hadn't bothered to suppress them in the
transfer (not sure if I could, but I think so).  So (again from my shell
prompt) I entered "flip -u dl.tp".  (The file transfer had converted the
uppercase DOS filename into a lowercase name - may not with another setup.
So you may want to check that after the transfer, using ls.)  The flip -u
removed the CRs.


Then I got back into Picospan and (at the "respond or pass" prompt) said "r"
for respond.  At the entry prompt (">") I entered ":r dl.tp", and it read it
in.  To check everything, I next did a ":p"; this could have been stacked with
the read command as ":r dl.tp;p".  I entered control-D to terminate the
response.


Um.  I see I forgot to delete the file later.  At a shell prompt I will
(as soon as I finish this) enter "rm dl.tp" and do that.

response 6 of 81:

Dec 27 08:52 UTC 1992

Somewhere recently I had to NOT use Kermit and tthen the question
arose on how to energize the (bunny ...hehehe) er, uh, the x/y/z/modem
protocols. 
  
From the answers I got inmail (thankxx all) it seems that if there
are no arguments following    sx     sy     sz     rx   ry   rz    that
the instructions are flopped onto your screen. Don't try    man    , it
fails. Basically, x/y/z are the protocols; s means send and r means
receive. There are a couple of other switches and/or tricks, but
it works just fine. Oh, tell Grex what you want Grex to do, +then+ go
to your machine and satisfy Grex.   
  
   <did he really say *that?*>

response 8 of 81:

Dec 29 05:45 UTC 1992

     If you feel like using Kermit, issue the command
kermit (!kermit from a Picospan prompt)
then wait for the prompt.  To upload a file type:
r <filename>
to download a file type:
s <filename>
In either case, Kermit will tell you to escape back to
your local Kermit system and do the opposite.
It's actually quite intuitive, as long as you do the
Grex half first.  At least that's how it
worked on EMUNIX.  I can verify that uploading to
Grex works this way as I've tested it, but I've
not tried downloading.

response 10 of 81:

Dec 29 16:58 UTC 1992

(For help with rz or rb, use -h not -?.  The ? is a shell wildcard
character.)

response 12 of 81:

Dec 30 01:12 UTC 1992

tsty is right...at least a version of y-modem that I have on another
Unix box has sy and ry, and I have seen rb around, too.

response 14 of 81:

Oct 30 17:20 UTC 1993

I have been trying to upload a text file to grex with Y-modem, but I
get an "unsuccessful" response almost immediately. I had it going last
night, but it was extremely slow, so I aborted. Therefore I was surprised
to not to be able to even get it started, today. Where should I look for
a problem? (I signed on with 7E1 but changed to 8N1 before beginning
upload procedure.)

response 16 of 81:

Oct 30 21:32 UTC 1993

I used rb with ymodem batch a few minutes ago, BTW.  It worked fine, got one
bad block and it aborted (but after my small file was entirely sent).
When the system is slow, particularly if unetmeg is on, it may be better to
use xmodem or something else with smaller blocks.

response 18 of 81:

Oct 31 00:05 UTC 1993

Um, yes, if you are going to a system which doesn't support long filenames,
it's up to the comm program you're using there to decide what to do about
it - and refusing to proceed is a *very* common (and mostly reasonable)
choice on the programmer's part.  (I'd like to see this made configurable,
say, to prompt you for a replacement name - but I'm sure they're afraid you'll
start a long batch & go out to dinner.  They could generate a name for you,
making sure it doesn't conflict with any existing filenames, but then what
would you think when you couldn't find it?)

Ymodem can take longer than xmodem if there are problems - either system-load
related (not *normally* a problem on the sender's end) or noise-related.
If an xmodem packet errors out, not only do you find out faster, but only
128 bytes have to be resent - and if there's noise, you're much likelier to
affect any given 1K packet than any given 128-byte packet.

Anyway, glad you found out, Rane!

response 20 of 81:

Oct 31 05:19 UTC 1993

I don't have Z-modem in my version of Versaterm. I guess its upgrade
time....That file is text (.hqx). What did Z-modem in binary mode do
about that? I suppose the test is in the conversion and extraction. 
I finally looked at the font. BONE is the best of the three - our
daughter thinks. She has already made a poster with in, in MacPaint.

response 22 of 81:

Oct 31 05:44 UTC 1993

Would you expand a little on that, Steve? Do I gather that some character
for <lf> in unix *also* results in a line feed, as a property of the OS?
(And similarly for <cr> => <cr+lf>, and DOS wants both?) Then, what
happens when the mac sees <lf>s instead of <cr>? Finally, is "Zap
gremlins" a BBedit command? I have BBedit Lite, but use it for just
text finds, at the present.

response 24 of 81:

Oct 31 15:23 UTC 1993

Thanks, davel, that's what I would have said.

What happens on a mac, as is the case on other OSes, depends on the 
program looking at the text file. A <lf> generally is not used to 
terminate the line. It is pretty much just treated as an unknown control
character. If you moved a binary text file from a Dos system to a Mac,
you would get little squares (representing the <lf>) at the left end of
each line (i.e. right after each <cr>).

If you look at a unix-originated text file in this manner, the whole file
will seem to be one line (as there is no <cr>). This may cause the program
to complain, or may cause the line to extend to the right ad infinitum.
There will be little squares where each line *should* have ended.
These are the <lf>s.

Zap Gremlins is indeed a BBEdit Lite Command. Find it on the Text menu.
It changes <lf> and <cr><lf> to <cr> and makes other changes like
converts smart quotes back to ascii (dumb) ones, etc.

For completeness, btw: If you move a text file from Dos to Unix in
binary mode, you will see the <cr>s at the end of each line
(i.e. just before the <lf>) as a ^M . You may have seen this from time
to time. A Mac text file, when moved to unix, will result in a file
which is all one line with embedded ^M 's .

The reason, rcurl, that I suggested you go ahead and try dehqxing 
your file is that the dehqxing program you are using might be
forgiving enough to understand <lf> even though it's on a mac
(some do, I think).