You want to build a web site? Do a little e-commerce? You're Mac and HyperCard proficient?
But your internet knowledge is limited to shopping at Amazon and using a search engine?
Then this is a story of what you may likely run onto and have to overcome along the way. ~Circa 1999

Updated 4/24/08

Notes are added to alert you to things you're going to find out down the road. Such as this one: Unless you have a compelling reason to do this and a high tolerance for failure, you'd might rethink the whole endeavor. That being said, you're a Mac and HyperCard user, which makes you a little sharper than the average park bear. When the going gets tough, keep this in mind. First and foremost is jargon (highlighted in red throughout). Wade through the jargon and most of the fight is won. There is a conceptual component, but it's tiny compared to the jargon jungle.

Browser --The software you use to surf the Web. Netscape's Navigator, Microsoft's Explorer.

ISP --Internet Service Provider. The people and/or place where websites live. Those who charge you a monthly fee for being attached to the WWW and delivering your email.

Sever -- Somewhat synomous with ISP, but refers also to the hardware/software involved in 'serving' the WWW.

I had an email account with a local ISP and went to see them about expanding into a website. They were friendly enough but when I mentioned HyperCard they started speaking CGI and there our conversation faltered.

CGI -- Common Gateway Interface It isn't actually a language but a set of procedures or protocols. Its usually spoken of as if it were a language. Languages which do CGI are Perl, etc.

I was sent off to see a CGI/website wizard and the gist of what I found out is that websites are dumb as a pound of sand. You want something that would seem natural in HyperCard, like a button which generates a new little poem and sticks it in a field? Fat chance. Much eye rolling and hand waving. Turns out what you want is a dynamic site and that's a big problem. All that must be specially scripted AND scripted in CGI. Dynamic basically means CGI. And CGI means leaving HyperCard behind. So what do you do if you don't really want to learn another programming language?

Dynamic and Static --websites which automatically change when you poke at them (dynamic) or flip pages like a book (static). Want a new quote every day? --Dynamic. This page is static --unchanging, not need for any CGI scripting.

You go through several website designers (I particularly liked the one who wanted to do a feasibility study. He was a website 'architect' and would have the CGI done by Dr. Somebody in Memphis. That and the nose rings.) before deciding to try doing the whole thing yourself.

Feeling like the three-legged dog living behind the pop cooler at the last gas station on the way to Reno? Then you happen to find MetaCard. You get the demo and mess with it. A little stiff, but workable.

You understand HyperCard, an ability which can be transferred to MetaCard and MetaCard can run on your ISP server and do the CGI. The logic is breathtaking. So you go back to your ISP and talk about using MetaCard as the CGI component of your website. They won't know what you're talking about. They'll snicker and scoff at you. Have them call MetaCard and talk to somebody. They all speak the same non-Mac language. Threaten to take your business elsewhere. MetaCard knows other ISPs who'll be happy to host your website. Your ISP will relent and agree to let you use MetaCard, if only for the amusement value of watching you fail. They personally wouldn't EVER do anything in less that C++.

Finally, taking the plunge you buy MetaCard. And hope, at those prices, that the people at the company are somewhat stable, will stick around and come through with a version which will make your work and life much easier. You're now married --you and MetaCard.

And you're in the soup. It's day one. Here's what you're going to find out. Basically, you're a Mac user for a very good reason. You've forgotten the reason, but it'll come back to you. You think computers should work for you--not the other way around. You're about to enter a pre-Mac world, where you work for the computer. You'll do it's thinking for it, you'll remember things for it, address it the right way -- pre-chew it's food. You'll hand-feed it, change it's diapers and it'll spit up on you. There are two cultures (in case you've forgotten): Mac and the rest. And web development is for the rest. They will treat you with something between contempt and vague amusement. Get used to it. They've got you now. All those years you had it easy. Now you'll pay, they'll make sure. Now you're going to work for the computer, just like they've been doing all along. Which is to say that filenames and that kind of thing become a BIG deal. In some kind of way, the whole deal, and don't mess up a single character or you're toast.

You know that text stuff that appears in an upper window of your browser when you surf around? That disgusting .//arnarp.tr_iq/ looking stuff that somebody didn't have the decency to place behind the scenes? Left it out there for children to see? Well Bucky, you're going to learn to read it. And beyond that, you're going to learn to speak it. It's called HTTP.

HTTP --Hyper Text Transfer Protocol That nasty looking text stuff you see in the location (upper) window of your browser. At one level it's pretty simple, just a set of directions--but written by an autistic on speed.

So instead of saying: go to South Hampton, to the public library, the fourth floor, the 37th stack, the second self, the 12th book, the seventh page, copy it and bring it back, we now say http://www.southhampton.org/pub-lib/fo.fl/a37_stk/seco.sf/b12-bok/sev-pg. Or something like that. This is a pathname. And don't capitalize anything or leave any spaces--you're now working for the man. All web directions are given in http. At this point you'll be wondering what happened to the rest of the world since 1984? They've been working for the man--now it's your turn.

What's your address? No, not your mailing address, that'd be too simple. Your URL.

URL --Universal Resource Locator Think address. What's your mailing address? What's your URL? URL's are written in HTTP.

Domain Name --The Whatever.com your website will be known as. And it will be spoken in http.

Search on the web (plenty of places want to sell you one) or have somebody get it for you. Secure your domain name. Go out and celebrate, it'll be the last time you do for awhile. Tell your ISP about your domain name. They need to fiddle with it, plug it in or something.

Now all you have to do is create your site, upload it and you're in business. Let's solve the create part first. Get Adobe's GoLive. It should come with a video. On it you'll watch Lynda speed-build a site. Included in the video box is a time schedule for the tape. Save it. Tape it on the box so you won't lose it. You'll need it, as you'll watch the tape many times. How did Lynda create forms?? Let's see, it's at 1:03:25. Hit the fast forward!

HTML --Hyper Text Markup Language THE language browsers speak. <if this> <seems> <normal to> <<you, you'll>> <be a> <<natural at the html>> It lives in text files at the server. It's just very screwy looking text. Want to see a page of it? Next time you're on the web do Page Source (in Navigator). The view is disheartening.

OK. Here's the deal, it's quite simple really. The whole web exists as files on hard disks distributed on servers and ISPs around the world all connected to the phone line. Exactly where is a specific file? Ahhh, this is where HTTP comes in. And what's in that specific file? HTML. So by specifying the correct URL (written in HTTP) you can download a HTML text file into your browser which by using the HTML instructions makes a screen. See, you're understanding already. HTTP is directions to somewhere, HTML is instructions to do something along with the content to fill it in. HTTP is where and HTML is how and what. Understand this piece and you've got most of the conceptual part.

Next, you'll need to upload the work you and Lynda create and while GoLive had a dandy utility to do this you may need more. You're about to learn more about FTP than you ever wanted to know.

FTP --File Transfer Protocol You'll need FTP software to up/download files to/from your website. Get Fetch 3.0.3 (or whatever version it is now). It's free.

1) Server: Whatever.com (Fetch calls this Host instead of Server)
2) Directory: public_html (or maybe not. Depends on your ISP and how it's configured)
3) Your USER ID: (the name/phrase you'll be known as at your ISP)
4) Your password: (comes with the USER ID)

With FTP you can go look at your spot at your ISP, see the folders, etc. This is where your site lives. You get to see what you rented from your ISP. It'll be mostly empty. No plants, furniture, or drapes. These you'll create and install (upload to your site).

Finally, by shear will and determination you get a really dumb, mostly empty page uploaded to your site. It'll be called index.html. You'll be proud. You should be, for when you type http://www.whatever.com into your browser the page will appear. Now you'll be worried others will see it before you get it fixed up right. Then you'll complete a second empty dumb page and have buttons so you can go back and forth between pages. You're a genius.

All this time there's been that folder at your site called cgi-bin. This is what got you into trouble in the first place--the whole CGI business. Can you say cgi-bin? Can you type it (without error) about 500 times? I knew you could.

You have to get your ISP to download (from MetaCard) whatever flavor of MC engine your ISP can run. (If you're advanced enough, you can do this part yourself) They should unpack it and put it into your cgi-bin folder. From MetaCard you should download two files: echo.mt and survey.mt Stick them into your cgi-bin folder. Save a copy and read them, they're just simple MetaCard scripts. Now the fun begins.

Form and/or Forms -- I don't know what this really is. Some kind of designation HTML apparently needs to know about so it has some idea what kind of information it's messing with.

What you want is to create a Submit button which when clicked will send to the echo.mt folder which is sitting there, waiting in your cgi-bin folder. You talk to stuff in your cgi-bin folder by way of actions and sending a form is an action. The GoLive manual specifies different types of actions. Get this all uploaded, start the browser, on your site will be the forms stuff. Click the button and it send forms information to your echo.mt file, triggering it.

You may get back some manner of FORBIDDEN message. This means your message didn't get through to echo.mt. Bummer. You ask around and it's probably a permissions problem. echo.mt doesn't have permission to talk (listen and respond) to anybody. It isn't executable. Lest you forgot, you're still workin' for the man. This is what you need Fetch for, with Fetch you can change permissions at your site. Do so. Set the permissions of echo.mt to executable. (along with everything else in your cgi-bin folder for the time being) Then fire up the browser, go to your site and click the echo button again and this time you may get back a screen full of INTERNAL SERVER ERROR. You made it to echo.mt, but then things went wrong. One step closer. Did you change anything (even one character and particularly one in the first line) in echo.mt? Got caught didn't you? Your server is VERY fussy about the way it's talked to--as you'll find out. Download echo.mt again, install it again, set the permissions again and try again. Did you happen to install it as binary instead of text? Start over.

A note on Fetch: When uploading you're given a choice of options. Only two will apply here:RAW DATA (which is binary) and TEXT (which is text). Everything you upload to your site with Fetch will go RAW DATA except text files. GoLive is smarter about these things and does them automatically.

Should you begin to doubt your form-building acumen, echo to http://www.metacard.com/cgi-bin/echo.mt to be sure things are working correctly on your end.

By this time, you're wondering about the rules of http, the syntax. Here's a little bit:

1) Most web servers are case senitive--no capitals
2) Don't use a forward slash (/), empty space, or ampersand (&) as any part of a name
3) Don't use a period (.) except as part of a name (index.html)
4) Don't use the hyphen (-) as the first character of a name
5) Forward slashes denote hierarchy or levels. cgi-bin/echo.mt means the echo.mt file is
inside the cgi-bin folder. But they aren't called folders, instead they're called Directories which will get you into trouble more than once with Fetch.

By now you've probably figured out that you can activate it (echo.mt) by just entering it's full pathname through the location window of your browser. And anything else on the web for that matter, that's how it works. Pathname, pathname, pathname.

Let's recap:

Permissions: For the time beginning at least, set all the READs to true. (you, the group and the world) Same with EXECUTABLE but keep the WRITE function just for yourself.

Getting a screen full of important looking stuff back from echo.mt is the goal. Persist until you see that magic screen.

To achieve this requires ALL of the following:

1) the correct flavor of mc is installed (matches your ISP server software) in your cgi-bin folder
2) echo.mt is installed in your cgi-bin folder
3) the script of echo.mt is unchanged.
4) the permissions for echo.mt and mc are both set to executable
5) echo.mt is a text file and mc a binary file
6) the pathname you're using to reach echo.mt is correct

Do all the above and any problem isn't on your end. My difficulties could all be traced to the last four items.

I still haven't quite figured out the pathname business.
I actually use http://www.navaching.com/"myusername"-bin/echo.mt --rather than cgi-bin. I don't know if this is specific to my ISP or not.
Too many things to find out, so little time to do it.

When you finally get the word to echo.mt and echo wakes up MetaCard it will send back a screen full of stuff you won't understand but it looks pretty darned impressive. Be overjoyed, at least you can now talk to MetaCard at your site. Look closely and you'll notice any text you entered in your forms coming back. It took me two weeks to get to this point. I hope to make it easier for you. Prepare to be a CGI God. You can now write all the CGI you please.

How to do so? Finally, your honed and polished scripting ability comes into play. Now it's your game, in your hands. No more working for the man. You build a MetaCard stack (which must be suffixed like: mystack.mc). To a large degree, it's going to be a text editor. It's going to edit HTML text, take orders, do bookkeeping, check credit cards, send email and about anything else you want it to do.

The first thing it's got to do is put the incoming info (HTTP ) into an understandable form. You need to write a parsing handler. Open survey.mt. Read the code until you start to get the hang of what it has in mind. Not terribly difficult, just messing with text. Rewrite the survey.mt code to suit your purposes.

One more small but ALL IMPORTANT detail. You'll need a script in a text file placed in your cgi-bin folder to wake up MetaCard and get it going. Three things it will have:

1) A name suffixed by .mt (perhaps call it start.mt) The mt part is more convention than anything else.
2) The very first line must read: #!mc (this alerts ...something... to get MC cookin')
3) It must have a startup handler

#!mc
on startup
send "WakeUp" to stack "mystack.mc"
end startup

on WakeUp
--maybe the parser goes here or any of the stuff you want to happen upon and with Incoming
end WakeUp

Remember that little poem you wanted to generate and stick on your website every time a page changes? Or a thought for the day, or proverb? Here's how to do it. Put the html for the first page of your website in a cd fld (call it Page1) in your stack. When you created the page you put the word "poem" in the field where you want it to appear, didn't you? So now when you take the html in cd fld Page1 and put in a cd fld called WorkingPage (cuz you want to do this to a copy, not the original) you can FIND the word "poem" and REPLACE it with the text of your new little poem. Yes, html is just text. (Where'd the new little poem come from? Well, you have a clever button in your stack that whips up new little poems on demand.) Now you PUT cd fld WorkingPage as if you were sending it to the message box, but at the cgi-bin folder there is no message box so the thing gets sent across the web to your browser where your first page appears with a new original little poem in the 'poem' field. Examine echo.mt's code, you'll get the logic of how to take incoming http and use it to create the http address to send back to. Pathnames, pathnames, pathnames.

Create a button or use linked text which sends to start.mt (http://www.whatever.com/cgi-bin/start.mt) and put it in your index.html. Every time you want your CGI/MetaCard stuff activated, you'll go through start.mt or something like it..

You'll need to modify the addressing code from echo.mt to fit your purposes. Change "text/plain" to "text/html" and you're in business. At least for a simple 'see how it works' kind of thing.

Now upload mystack.mc and start.mt to your cgi-bin folder and the revised index.html (with the link to start.mt), use your browser to look at your site and click the link and a new poem appears. You do it again (not the upload part, just the click the link part) and again and again. Your site is now very dynamic because you have control of the CGI. Your stack is now modifying the html for the page every time it's sent out. Get the FIND AND REPLACE concept as a method for generating new html? I knew you would. Not workin' for the man anymore are we?

The above just changes the content of a field on your website, but applying the FIND AND REPLACE principle you can change anything. Colors, locations, etc. It's just a matter of your cleverness in creating the original html for the page so you can FIND it and what you REPLACE it with. Well, kind of. The trouble is that FIND doesn't work in this circumstance so you'll switch over to OFFSET.

You now have a dynamic website, are in control of the CGI and about ready to commit commerce in public.
Take a break, take out the trash, take a shower and then a nap. You deserve it.

Now that you're rested, you're ready to write some code. Intricately woven handlers--it'll be great. But then something strange happens when you upload your stack and run it, you start getting screen 500 (Internal Sever Errors)--repeatedly. The code looks good, it runs on your machine, but won't run at your ISP. So the debugging starts. You put in an EXIT line, upload, run, 500. Move the EXIT line, upload, run, 500. Again and again. Until you get to the part of the script which isn't tricky at all--just putting a variable (which is text) along with some other text into a cd fld. No big deal. But this is the bad line. Delimit it and your stack runs. Let it run and your stack crashes. You delve deeper, taking the line apart. If you change a word--it runs. And then a character and finally just a space. Sit back in your chair and take a deep breath. You've come upon a circumstance where the code runs or not depending on its content. No, this can't be true! This negates the whole concept of computing. It takes a couple more days messing around until you're firmly convinced. This isn't just some idiot mistake on your part. There's no question about it--the code responds to its content. Now for the hard part.

Remember back when you bought MetaCard......when was it?......seems like a year ago. And remember about the promise of unlimited email support? Well, there is a limit. You've been peppering them with questions right along that any third grader could answer. Their patience is wearing thin. And now you are going to tell them their product doesn't compute. The usually speedy replies suddenly dry up. They've suspected that you're a twit for some time now. Lean in a little bit, lay it out as simply as you can. Send the scripts, stripped to just what's essential to create the crash. They'll get a little peckish, but answer. They're interested now, it's a problem they can understand.

I'll spare you the ugly details and just say it will be a problem with the Linux your local ISP is using. It's some version from one of the Croatias and nobody can remember which one. Your 'support local businesses' ethic dissolves into a puddle of warm milk as your naivety crumbles. You switch to a different ISP. It could be in China for all you know. Global takes on a whole new meaning. Welcome to the Web!

In the back of your mind there's been that nagging worry about cookies (what are they about anyway?), environmental variables, hidden fields, $other $important $things and lord knows what else. So some time back you went to Amazon and searched for something about CGI didn't you, and settled on Elizabeth Castro's Perl and CGI for the World Wide Web. Perl?? Isn't that what got us into all this trouble in the first place? Well, yes. But the only other book (on what appeared to be just CGI) looks like an academic tome, costs $60 and was published in 1912. Beside that, Elizabeth is a good explainer. She'll tell you about a lot of stuff. You're in the Unix world now and need a guide. Elizabeth recommends you get BetterTelnet, it's free.

As you get closer to the Unix world you may start having free floating thoughts about the attraction bare-handed computing has for some. How it seduces people to devote their lives to serving the machine. Kind of like fishing by hand. And you'll realize there is an immense fortune waiting to be made by freeing people from computer bondage. But for now (and the foreseeable future) you'll be indentured. You're learning an archaic system that one day your children will look on as barbaric. Owning and operating a car today doesn't depend on your being a mechanic. And that only took us a hundred years to accomplish. One day the slivers of silicon (or their progeny) will serve themselves. Until then you'll need people like Elizabeth.

You'll need to know a little bit (more than you imagined) about Unix. Remember that screen full of stuff you got back from echo.mt? They're called environmental variables. Some of the variables are somewhat obvious and others not.

$SCRIPT_NAME = /cgi-bin/echo.mt
$REQUEST_URI = /cgi-bin/echo.mt
$REQUEST_METHOD = GET
$SERVER_PROTOCOL = HTTP/1.0
$GATEWAY_INTERFACE = CGI/1.1
$SERVER_SOFTWARE = Apache/1.3.9 (Unix) PHP/3.0.12 FrontPage/4.0.4.3 Rewrit/1.1a
$SERVER_PORT = 80
$SERVER_NAME = navaching.com
$SERVER_ADMIN = webmaster@navaching.com
$SCRIPT_FILENAME = /home/navach/navaching-www/cgi-bin/echo.mt
$REMOTE_PORT = 1984
$REMOTE_ADDR = 206.183.203.153
$HTTP_USER_AGENT = Mozilla/4.51 (Macintosh; U; PPC)
$HTTP_HOST = 208.56.21.65
$HTTP_CONNECTION = Keep-Alive
$HTTP_ACCEPT_LANGUAGE = en
$HTTP_ACCEPT_ENCODING = gzip
$HTTP_ACCEPT_CHARSET = iso-8859-1,*,utf-8
$HTTP_ACCEPT = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
$DOCUMENT_ROOT = /home/navach/navaching-www
$PATH = /usr/local/bin:/usr/bin:/bin

Since you're intending to do some e-commerce you'll need some kind of page at your site for orders. And on that page you have a form--call it OrderForm. You're going to want to POST OrderForm rather than GETing it. If you GET it, all the field and btn info will be added to the URL in the location field when it's sent. If nothing else it doesn't look very professional. The world already has enough clutter.

on WakeUp
read from stdin until empty
put it after buffer
put "Content-Type: text/plain" & cr
put "Content-Length:" && the length of buffer & cr & cr
put buffer
end WakeUp

It will just bounce back the content of OrderForm--in a strange, almost indecipherable string.

Once you're gotten this to work, it's time for a parser--a bit of code which makes sense out of the content of OrderForm (that which you bounced back, that long string of gibberish). But before you start building your parser, give some thought to your OrderForm. You can make it work by giving the flds and btns distinct and separate names and even prefix the names with numbers--makes them easy to sort/refer to in handlers/etc. Any cleverness, you will apply first to OrderForm and then your parser. With it you can replace those ='s, +'s, ?'s, &'s, etc. Those pesky %2f's and %40's with their equivalents.

There's another way to 'parse'. Just use the MetaCard function urlDecode. (look up 'decode' in the MetaCard index, it's not listed under 'url') Depending on what form you want the final parsed string to take, you also might want to use some replaceText's. (listed in the index under repaceText)

So you have some parser code uploaded (which runs fine on your machine) but it does funny things at your site. A lot of the time nothing happens when you click the Submit button on your order form at the site. You start debugging, uploading, trying again--you know the drill by now. You'll be getting somewhere, but slowly. You get ready to go offline and eat dinner--time for a break and check your email before dropping off. You've gotten email from somebody called ABUSE AND SECURITY--no subject. Sounds ominous. Vaguely S&M. It's your new ISP writing to say that your site is now eating up over 30% of the processor time and they're about ready to shut you down. Dinner doesn't sound so good anymore. But the email explains why in the middle of your debugging, start.mt suddenly changed its name--the ISP did it in an attempt to cool off your site. You (not knowing this) had had to track that one down (all the while the specter of hackers looming in your mind) and set the name back to what it was. Time to go watch the news and chill out. Maybe somebody else in the world is having a bad day.

All along the folks at MetaCard have be nattering on about the glories of having something called a shell account so you can go in (somehow?) and run your the code at your site by command line. Haven't wanted to listen to them have you? Means you'll have to learn more Unix and telnet. Trudging off to Amazon again. Which, by the way, may be the one bright spot in the story so far. Amazon will pay you 5% of what they sell to anybody sent to them by you. 15% of any sales you direct to a specific item. For the time being at least you can learn a little bit about links, html, etc. by becoming an Amazon Associate. Just go to Amazon and follow the links. If nothing else, you can recoup 5% of your mounting book bill by using a link from your own site. Anyway, it seems that this 'shell' deal can corral your code and keep it from bothering your neighbors at the ISP. Maybe you'll have to do it. Either that or start looking for another new ISP.

With BetterTelnet (you did listen to Elizabeth, didn't you?) you log on to your website and get a screen where your ISP says they'll do the cyber equivalent of breaking your arms if you try any monkey business. At this point you'd be thrilled to have any ability to hack or snoop.

Along about here, it will slowly dawn on you that the MetaCard people are Unix people. MetaCard is HyperCard for Unix and Linux and all the other uckses. This explains the odd feel and look of MetaCard, it comes from a different philosophy than HyperCard.

Unix retains much of the ethic and experience of programmers of the 50's, where computer memory and speed were in short supply. So efficiency was paramount. Also, it was believed that 'the public' would never program. Programming would remain an eclectic activity of the anointed. Entrance to this programming cult required, among other things, mastery of an arcane language--which can be thought of as resulting from a type of mental shorthand. Basic chemistry remains saddled with elemental names and symbols from the time of alchemy. There is an overwhelming preponderance of Arabic star names dating back to the Dark Ages when objectivity and rationality died in Europe but survived in Arabia. So the antiquity of Unix shouldn't be surprising. That this antiquity is still actively revered is. The problem with Unix is that it still embodies the presupposition that one shouldn't burden the machine with something a human could do. A significant portion of modern computing is increasingly devoted to having the machine do things we would rather not be bothered with. Keeping an address book, for example or spellchecking. To have used a computer for such purposes in the 50's would have been considered a sacrilege. Unix hasn't shaken that vestige of righteous outrage--people are expendable, machines aren't. Much, MUCH better to confuse a person than a machine.

Unix originates, in part, from the feeling that man must accommodate the machine. It's time is more valuable than yours. In 1961 perhaps this was true, but as we approach the millennium the roles have switched. Personal computers are now expected to be assistants and do a good bit monotonous grunt and memory work. Unix considers the machine more important than you--when things come down to a matter of convenience, the machine will get the nod. Get this straight and your relationship with Unix will go much easier. The future survival of any individual software company, etc. will depend to a significant degree on their deep unconscious belief about who should get the nod. Who's convenience should be served? But that's another discussion.

In any event, if you could do this part (all!) of your site with HyperTalk instead of Unix (it's OK to dream, maybe someday) there'd be no need for this section. But you're a native speaker of HyperTalk aren't you and that's a partial source of the prejudice. Anyway, by the time you're down the road a ways, your appreciation for HyperTalk and Mac will be even deeper.

So in keeping with this digression, it's back to Amazon to rack up another 5%. Get: Learning the Unix Operating System by Jerry D. Peek (has a nice owl on the cover) and The Complete Idiot's Guide to Unix by Bill Wagner.

OK. After about a month of head-banging and general consternation you will have come to several conclusions.

1) Skip the whole Unix/commandline business. Can you say: enter % ls -a -l? With a straight face? Other adults can. If you're one of them then by all means proceed. Otherwise, it'll just make you crazier than you were before. You'll begin having dark thoughts about computers and the humans who tend them, hoping for a Y2K meltdown, thinking thoughts like, "They'll get what they deserve."

2) MetaCard is perhaps not the easiest place to get useful information about running its product as cgi. SPECIAL CHARACTERS will be mentioned as a possible source of your troubles. You'll search for SPECIAL CHARACTERS, line by line, character by character. And never find any. The news is this: What MetaCard means by SPECIAL CHARACTERS includes not-equal-to, greater-than-or-equal-to, less-than-or-equal-to. Use <> or 'is not', >=, <= and most of your troubles will go away. You've lived in Mac Land far too long to consider them SPECIAL, but apparently they are in the Unix world. MetaCard isn't know for its excess in either explanations or examples.

3) Get the whole Unix-pathname-level-thing drilled in your head. (/) is down, (../) is up. Code only runs in cgi-bin (alongside MetaCard) not up or down a level. Now you know what the Finder does in Macintosh.

4) Upload your code as text files (instead of stacks) and use an ISP where you can open/read/edit files onscreen. That's the fastest way to do debugging.

#!mc
----- test.mt Tests bits of code.
on startup
generate some bit of data
put it into buffer
----------------- return to screen
put "Content-Type: text/plain" & cr
put "Content-Length:" && the length of buffer & cr & cr
put buffer
end startup

to get a handle on how things work. Use 'favorite' buttons in your browser to trigger your tiny programs.

If it's text say: put "Content-Type: text/plain" & cr
When returning html, say: put "Content-Type: text/html" & cr

6) Get an error-log installed by your ISP (ask them for one) and write some code in a text file, write a tiny program, call it elog.mt, put it into your cgi-bin, set or create a 'favorite' button in your browser with a URL pointing to elog.mt and you can display the error-log onscreen at any time. (I left in the part about emailing the error-log to wherever you want so you can see how to email.) Get the permissions set so you can write to the error file, otherwise it'll grow indefinitely. Sometimes the error-log gives clues as to what's wrong, sometimes it doesn't

#!mc
----- elog.mt Displays the error-log on screen. And can email it home.
on startup
-----------------------------phoneHome
put "zink@newmex.com" into eAddress
put "NavErrors" into eFrom
put empty into eTo
-----------
put url "file:seconds.mt" into temp
set numberformat to "0.00"
put temp-86400 into temp
put (the seconds-temp)/3600 into temp
put "ErrorLog"&&the short date&&temp into eSubject

------------------------ read error-log
open file "../../navaching-logs/error-log" for read
read from file "../../navaching-logs/error-log" until eof
put it into eMessage
close file "../../navaching-logs/error-log"

--------------------------------- send error-log home as email
--put "/usr/sbin/sendmail" && eAddress into mprocess
--open process mprocess for write
--write "From:" && eFrom & cr to process mprocess
--write "To:" && eTo & cr to process mprocess
--write "Subject:" && eSubject & cr & cr to process mprocess
--write eMessage to process mprocess
--close process mprocess
--wait until the openprocesses is empty

------------ erase the error log
--open file "../../navaching-logs/error-log" for write
--write the short date&&"MT " to file "../../navaching-logs/error-log" at 0
--close file "../../navaching-logs/error-log"

----------------- send error log to screen
put "Error Log "&&temp&&"hrs."&cr &cr into buffer
put emessage after buffer
put "Content-Type: text/plain" & cr
put "Content-Length:" && the length of buffer & cr & cr
put buffer
end startup

and everyone will roll their eyes because the whole internet concept is based on sending something back, even if it's an empty gray screen (what Navajos think of as the Death Screen)--the very thing you want to avoid. Basically, every time CGI runs 'something' needs to be sent back to the browser or a server error will occur.

#!mc
------- update.mt Update html pages
on startup
-----------------checkdate
put url "file:seconds.mt" into it

if the seconds>it then
put the short date into temp
convert temp to seconds
put (temp+86400) into temp --the daily seconds
open file "seconds.mt" for write
write temp to file "seconds.mt" at 0
close file "seconds.mt"

----------------prepare data for updating site pages
makedate
loadpoem
-------------------------------------update pages
put "index1.html" into tranz
updatepage
--------------------send back the 'Update' Page
put url "file:../update.html" into buffer
put "Content-Type: text/html" & cr
put "Content-Length:" && the length of buffer & cr & cr
put buffer
else put "Status: 204 No Content" & cr --This line is the trick for sending back 'nothing'! The user will be unaware that anything happened.
end startup

8) EVERY TIME you upload a new code file, REMEMBER to set the permissions to executable. More than enough time will be squandered fighting the internet ghosts otherwise. Getting an INTERNAL SERVER ERROR is the same as saying IT DIDN'T WORK with no clue as to why. The machine had a headache. So permissions problems are reported the same way as code problems and everything else for that matter. Technically correct, but not particularly useful.

9) Just because your code runs perfectly on your machine don't expect it to at your web site. Your home environment has little bearing on that other world. Run your code on your home Mac machine only to find the obvious bugs. The rest is detective work.

10) MetaCard/Unix have strange ideas about time and dates. If they're important to you, you'll end up writing your own code to handle them.

11) Credit card numbers aren't random. They're generated by special means such that when run through a verification algorithm they either pass or fail. Not terribly difficult to write, but a bit tedious. Again, if you have need for Credit Card verification code email NavaChing.

12) As Robert W. Service wrote: "Strange things are done in the land of the midnight sun." MetaCard in combination with Linux isn't the most stable of programs. Odd things happen. Change letters to lower case, change the number of spaces, change how you say things and in what order, etc. and often your problem goes away; i.e. sometimes Metacard wants THE long date, and 5 lines later it doesn't.

And that's where we are, Bucky. If problem solving doesn't have an underlying satisfaction for you, then the whole thing is an uphill climb. There will be days however, when you find out (by checking your site usage statistics) the someone using a browser know as 'RepoMonkey Bait & Tackle/v1.' came to your site. That makes it all worth it. Netscape's Navigator is known as 'Mozilla'.

I probably know less about Java than you do, it's pretty snarly looking stuff. But there's a lot of free code around--kind of like HyperCard used to be. Examine the page source of sites that appear to have something happening automatically and look for SCRIPT tags. Save the page source and look it over at your leisure off-line. You'll get the hang of it. Many of the downloadable files with free Java Scripts have instructions for installation. Basically, the script lives somewhere (head or body) and a 'handler' to call it is placed in your html at the place in the sequence of page-loading you want the script triggered. That's the general idea. So, I'm just saying to learn from the wealth of examples around. (Note: Java scripts don't run (but applets do) on Internet Explorer for Macintosh--and may never).

And finally at long last, on to the commerce part. Turns out that security isn't that big of a problem. Your ISP should have a certificate which means that they're paying somebody for something. And the upshot of this is that if you write your links using your ISP's certificate address (if that's what's it's called) then 'security' is automatically turned on. What you're looking for is the 's' as in https:/whatever/whatever, which we might as well assume stands for 'security'. Ask your ISP how to engage security at your site--how to write the links. We're just talking nomenclature here. That's all you have to do. Then your site will slow down, sometimes dramatically, which I suppose is reasonable. At least one gets the impression that a lot of important, time consuming stuff is going on. Encrypting, decrypting, whispering back and forth. With security engaged your browser encrypts and the server decrypts and so on.

Now for the money part. In the beginning, I went to my bank to get a merchant's account, one for credit card deposits. And they panicked when I mentioned I'd be doing business on the internet. They didn't want anything to do with it. Apparently, banker's magazines were full of ominous articles about 'internet thieves' and 'internet fraud'. They were serious about no internet credit card monkey business. We talked for some time and in the end I moved my accounts to another bank. Well, Time's Person of the Year for 1999 was Jeff Bazos of Amazon.com fame and in these few months the mentality of the banking community has shifted.

Anyway, what you need is the aforementioned merchant's account (somewhere the money can be wired to) and a credit card processor, someone who turns the credit card numbers you supply into little electronic bits that magically turn into money in your account. The processor almost never is the bank. Banks use independent processors, and the number of them is growing by leaps and bounds as the internet grows. Search online for 'credit card processors' and start winnowing through the thousands of entries.

The thing to watch out for is the charges, fees and rates. Set up, site inspection, sign up, monthly, percentage (1.5 to 5%), cost per transaction (15 to 40 cents), etc., etc. If you thought you knew about sharks, wait to you get to internet based credit card processors. And they'll all tell you how bad the other guy is and to watch out for him. Hopefully, you can use the same processor your bank uses and be done with it until your gross climbs to the point it makes sense to go shopping for better rates.

Generally, there are 4 ways you'll get the CC numbers to your credit card processor:

1) Online validation. You link (at your site) to the processor and they do real time validation. Costly and time consuming at the site.
2) You use special software to batch-send the numbers from your home or office. The software isn't cheap.
3) You get (from your bank) one of those keypad terminals you see in all places of business. Cheaper and personally time consuming.
4) Some banks and/or processors have a deal where you enter CC numbers through your phone keypad. Very cheap and personally time consuming.

Get a merchant's account, get hooked up with a credit card processor, get a way to transmit the CC numbers to your processor and you're in business.

This story started in July when I made the first inquires at my bank and the first of the web site 'designers'. I finally took the project over and started learning to build a site at the beginning of November. It's now December 30, 1999. Two months and some perseverance and you can do the same thing. In fact, I'm hoping that by not making the mistakes I made, you can do it in far less time. I didn't learn anymore than the most elementary Java or HTML or Perl or Unix, it's all HyperTalk.

The only general advice I can give is to ask questions. Ask questions until people won't talk to you anymore. Ask those really dumb questions, those questions that reveal how unbelievably ignorant you are about the whole thing. In the end, I found out that e-commerce (and everything required for it) is poorly understood by a huge number of people associated with the web--so don't be intimidated. This Christmas revealed a surprisingly large number of meltdowns, crashes and general foul-ups in the CGI of the nation's major online retailers. Early figures indicate that fully one quarter of all orders were messed up somehow. So don't feel bad when you get your first or 10th or 50th screen 500--INTERNAL SERVER ERROR. Just keep working on it until you understand the reason and then fix it. In the end, computers are vaguely logical beasts or at least can be bribed that way.