What is the procedure for uploading files to grex?

81 responses total.

If you have Zmodem on your PC, enter "rz" at the grex% prompt, then
kick out to your transfer program.  If you have a DOS machine, make
that "rz -a" to strip the linefeeds, or your file will have lots of
control characters and look silly.  (Assuming it's a text file.)

It's been so long since I used Kermit, I can't remember the commands.
Anyone else?

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.

Tell me more - in words of (about) one syllable. Maybe some examples.
How does one specify the file to upload goes to in grex, and then how
does one enter that as a response? Maybe an example (in a couple of
different modes)?

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.

Thanks for the help.

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?*>

Not quite, on two counts.  First, it's rb/sb not ry/sy for Ymodem, presumably
the "b" being for batch - I don't think it supports non-batch Ymodem.  Second,
rb and rz don't accept (filename) arguments, so you can't get help for them
that easily.  Use rb -? or rz -?.  (If there are no arguments, they just
start waiting for a send to start up.)
Yes to the rest, including (emphatically) starting things up on Grex before
starting your local system.  (And depending on your terminal type, if you
do sz to send using Zmodem, Procomm and possibly some others may even start
your local receive without your having to do anything.)

     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.

I think, (look out here) tat Y-Modem can operate in BOTH batch
and non-batch modes, so most of what davel says are accurate, and
infact an extention of the ?-modem options.

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

True.  I didn't know (remember) that -h works.  (But, at least with sh,
this is only a problem if you have a two-character filename in your dir
whose first character is "-".)

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.

After an email "reality check," the s/ry is not applicable here
on Grex. Only the sb commmand works in the Y-Modem model, again, 
any of the s/r? commands - without a file name -  give the
options for all three varieties.

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.)

The only thing that comes to mind is this: there are two protocols called
"ymodem".  One is merely xmodem with 1K blocks; the other is often called
"ymodem batch" and is what Grex's rb program uses.  (This supports multiple
files and includes filename information in the transfer.)  My own comm
program supports both, and at least once I've picked the wrong one, leading
to problems.

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.

I tried again in Ymodem (yes, "batch"), and it would not go. So I uploaded
OK in Xmodem, which took a few minutes (for 46K). Then I thought that
maybe Ymodem didn't like the filename (halloweenfonts1.1.cpt.hqx), so I
shortened it to halloween, and *Ymodem worked*! However it took ca. 12
minutes, much longer than Xmodem. Is there something here I should know?
I used just the default protocols on each, not knowing any better.

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!

  I just downloaded that very file in less than 3 minutes, using z modem
I used sz- b for a binary transfer, and it went at 96% effeiciency, 
so if I were Rane, I would try using z modem instead of x or y modems.

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.

If you transfer a text file in binary mode between two computers running
like OSes, no harm will come. If you transfer between unlike OSes,
problems may or may not arise, depending on what you do with the file.
In text mode, the various end-of-line conventions are converted to the
appropriate OS. <lf> for unix, <cr><lf> for DOS and <cr> for Mac
(and VMS files in stream-cr mode). SO (for example) if you download
a text file from grex (unix) to your mac in binary mode, you will
get linefeeds instead of <cr>s at the end of each line. I agree that
you'll have to test it with whatever de-hqxer you're using to see if
it matters. (It probably won't.) If it does, you can fix it in BBEdit
Lite (Zap gremlins).

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.

To answer the first part: close, but not quite.  "results in a line feed"
isn't the issue.  What happens on your screen when these characters are
encountered depends on your terminal type.  But the convention, assumed by
**lots** of programs (commands) on Unix, is that lines are separated by
the <lf> character (whose ASCII value is 10).  On some other operating
systems, a <cr> character (ASCII 13) is used.  On DOS both are used, but
a lot of programs read text in a way that just throws away the <cr>.
But under DOS, if you just type to the screen a file downloaded in a binary
transfer from a Unix system, the text will stairstep:
the first line will be
                      followed like this
                                        by subsequent lines.
(When the <lf> character is sent to the monitor, it moves the cursor
down without returning it to the beginning of the line, which is handled
by the <cr>.)

Under Unix, you tell the system your terminal type, and things are supposed
to be translated by the OS in such a way that when a <lf> is displayed it
moves the cursor down & also homes it - unless you change your settings to
something that behaves differently.  You have lots of control.

The point is that, if you specify that files are text files, your comm program
may be smart enough to fix things up automatically.  If you specify a binary
transfer, it has to assume that those <lf>s have some deep, secret meaning
that it knows nothing about, and it leaves you to fix it up yourself.

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).

I am going to have to read the above umpteen times. Let's get specific.
Dave wrote a draft response for the 501c3 form, which I saved to file,
and then downloaded with Y-modem (text mode). I did not specify any
protocol codes. The document, when opened with Teach Text on the mac
had longer lines than did the unix file, and there were numerous
joined words, which I took to have occurred at <cr>/<lf> points. I
opened the document in WORD, and by changing the right margin, could get
things (like tables) to line up better, but could not split those joined
words. Please tell me what happened, and what I should have specified
for that download.

Rane, someone with a Mac & your comm program will have to answer further on
this one.  Hope someone will be able to help you.  When I use ymodem
protocol it's always binary mode, but I think there are options to
change this.  I believe  sb -a  changes linefeed to cr-linefeed pair on
the send, & I suspect your Mac software is expecting you to do this and
then is straining out the linefeeds, leaving nothing at all, & that you
*didn't* specify the -a, but I really don't know.

This response has been erased.

There are other editors that do the same, but also others that don't.  Try
it and see.  (And, of course, it's not LF->CR but LF->CR/LF.)

Right, rcurl. I believe you're using Versaterm on your Mac and I
can't help with that. I am at a loss why "(text mode)" on the file
transfer wouldn't handle all of these conversions for you. As you
know, I use Kermit, and it certainly does.

Once downloaded without the proper conversions, your file could
(I'll bet) be saved. Turn those <lf>s into <cr>s with BBEdit Lite's
Zap Gremlins. Then your stuck-together words would be readable.

I found a couple scripts that do the conversion on the Unix system
prior to transfer (or after receipt): atou and utoa.  They are
quite short, and I have no doubt one of our Unix gurus around here
could cook up something equally useful (or does it already exist
on Grex?).

For conversions to the DOS standard, there's a program   flip   around
Grex.  I believe that flip -u converts CRLF->LF and flip -m goes the other
way; there are other options.  And I think that there are a couple of aliases
toix  and   toms   which go the way you'd expect.  Do man on it for more
information.

Yes, we have flip and toix/toms.

Are those the same as  dos2unix  and  unix2dos?

Not here, since dos2unix and unix2dos aren't here.  toix and toms are
aliases for flip.  Since such a program is no big job, and fills a real
need, lots of people have done them.

I put utoa and atou on my account if anyone wants to look at them.
They do the conversions between Unix and Apple (both Mac and Apple II).
They're just short scripts.

Last night I uploaded a 300K binary file via Xmodem. I eventually
succeeded, but it required some 7 attempts, due to interruptions from
somewhere. This was between ca. 10 and 12 pm. Fortunately, I was doing
something else, and could restart the transfer when it bombed and bleeped
at me. Are there any known problems that caused this failures? At one
point, all modems were in use (and does the appended "msdos" line mean
that someone was on the machine directly?); it got all the way through
the upload during a period of light use.

{There is a known problem.
You were logged into tty02 last night from 22:18 to 22:43
{tty02 has been extremely noisy.{ As you can see
I am on it now. It keeps getting breaks and lots{
of random line noise{q.  This would mess up a file
transfer big time.
{:p

This response has been erased.

This response has been erased.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss