[Metacard] Digest metacard.v004.n529
metacard-errors at www.runrev.com
metacard-errors at www.runrev.com
Fri Nov 23 18:48:01 EST 2001
-------------- BEGIN metacard.v004.n529 --------------
001 - Dave Cragg <dcragg at lacsce - Re: Darwin question again...
002 - Rolf Kocherhans <rolfk at ve - detailed files function
003 - Dave Cragg <dcragg at lacsce - Win XP: a new dawn
004 - Richard MacLemale <rmacle - Re: Darwin, CGI Question
005 - andu <undo at cloud9.net> - Re: detailed files function
006 - andu <undo at cloud9.net> - Re: Win XP: a new dawn
007 - andu <undo at cloud9.net> - Re: Darwin, CGI Question
008 - "Phil Davis" <phildavis at h - Re: Win XP: a new dawn
009 - "Phil Davis" <phildavis at h - Re: Darwin, CGI Question
010 - Dave Cragg <dcragg at lacsce - Re: Win XP: a new dawn
This is the MetaCard mailing list.
Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send any bug reports to <bugs at metacard.com>, not this list.
--------------- MESSAGE metacard.v004.n529.1 ---------------
From: Dave Cragg <dcragg at lacscentre.co.uk>
Subject: Re: Darwin question again...
Date: Fri, 23 Nov 2001 09:24:35 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
References: <200111222324.SAA11897 at www.runrev.com>
In-Reply-To: <200111222324.SAA11897 at www.runrev.com>
At 6:24 pm -0500 22/11/01, Richard MacLemale wrote:
>Here's what I think I know:
>1. You can download the darwin metacard engine and it will run under OS X.
>2. This will allow you to write scripts and save them as .mt files which
>can be placed in the CGI folder.
>3. An example of such a file is echo.mt, included with MetaCard.
>
>I downloaded the darwin engine, I double-clicked it and it uncompressed (via
>Stuffit). This created a folder with two files - gunzip and mc.gz.
>
>If you double-click the mc.qz file, it unzips and you have a file named mc.
>Putting that file into the CGI directory is NOT enough to make it work. OS
>X doesn't know that it's an application. I surmise that the directions that
>tell OS X about mc being an app are contained in the gunzip file.
>
>Finally, the question - How do you DO this? What are the step by step
>instructions for installing the darwin mc engine? I've got the darwin.tar
>file from the MC web site, and I know where the CGI folder is
>(Library/WebServer/CGI-Executables).
I've had it working before, so it is possible. Make sure execute
permissions are set on both the darwin engine and the mt script
files. (chmod 755)
If the engine is named "mc", and is in the CGI-Executables folder,
your scripts should start with #!mc
Call the script from a browser with the address:
serverName/cgi-bin/yourscript.mt
(I think Apache is pre-configured to run CGI scripts on OS X, but you
might want to check in the http.conf file if things aren't working.)
Also, from memory, I think the script files may require unix-style
line endings. (Or is that for Perl scripts!!!) One way to do this is
to write them in a Metacard field and save the contents of the field
using binary write so no conversion is done (put field x into url
"binfile:myfilepath.mt")
Good luck.
Dave Cragg
--------------- MESSAGE metacard.v004.n529.2 ---------------
From: Rolf Kocherhans <rolfk at vetvir.unizh.ch>
Subject: detailed files function
Date: Fri, 23 Nov 2001 10:36:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
I am playing with the detailed files function:
-- put the detailed files into field "Current Files"
Is it possible to get the detailed files of a remote file ala:
put "http://www.myserver.ch/test.mc.gz" into href
put the detailed files of URL href into field "Current Files"
What I need of the file /test.mc.gz is only the creation or the
modification date, based on a comparison with a local date I would
then download the file or not.
Any help ?
Cheers
Rolf
--------------- MESSAGE metacard.v004.n529.3 ---------------
From: Dave Cragg <dcragg at lacscentre.co.uk>
Subject: Win XP: a new dawn
Date: Fri, 23 Nov 2001 10:10:49 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Hi all
Be warned! The new dawn is what you'll see after working all night
to see if your old apps still run on XP. :)
First, Metacard seems to run fine. I've had no "engine trouble" so
far. But XP's new security enforcement may catch you out. (It caught
me out.)
Two main problems so far: running an installer and writing files to
places you shouldn't.
But there's an extra twist. If you install XP over a previous OS (NT
for exmple) it retains the basic security setup of the old OS. This
is what I did at first, and everything seemed to run as before. I
told my client that it performs fine under XP (we'd had a report of a
user not being able to run the app with XP), and he went away happy.
A day later, I re-installed XP following some hardware problems. This
time I made a clean install. I tried to run the client's app again,
and things were different. After starting the installer ( older
version of Wise), I was greeted with a very pretty system message
that an Administrator password should be used to install applications
(I was logged in as a plain user). But it gave the option to install
under the current user account. I tried with the user account, and
the installer failed with an error about access restrictions. I'm
guessing it was when writing to the registry.
I installed again, this time giving an Administrator password, and it
installed fine. But when I ran the installed app from the user
account, I immediately hit problems. The app writes a file locally in
the same directory where the standalone is. This is mainly
configuration data, and I think a number of users on the list use
this technique. Anyway, this was a no-no. No writing to the Program
Files directory for plain users.
However, I found that by copying the complete directory that contains
the standalone and other stacks out of the Program Files directory,
it would run fine.
I'm now trying to work out what you can and can't do, and also find a
better strategy for running and deploying the application. But I
can't find any clear documentation on this, only a number of
references to thing being different depending on environment: XP
Home, XP Pro, installed on a workgroup network, installed on a
domain, etc. So far, it looks like security through obscurity to me,
but I guess there's a method to it. If someone knows a good reference
for this, could you let us know.
Cheers
Dave Cragg
--------------- MESSAGE metacard.v004.n529.4 ---------------
From: Richard MacLemale <rmaclemale at earthlink.net>
Subject: Re: Darwin, CGI Question
Date: Fri, 23 Nov 2001 09:37:01 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <200111230500.AAA13865 at www.runrev.com>
Andu wrote,
> The more empirical way: put home, tools and help stacks in the same
> folder with the engine and do ./mc and see if metacard starts in gui.
> Also try .cgi instead of .mt for the cgi file.
> Test with a cgi known to work just in case the server may not have the
> proper settings.
That works. I wrote a text file named "test.mt" with a simple script which
created a text file and put it in the same directory (in this case
CGI-Executables) as mc and the other stacks. The first line of the file is
"#!mc" followed by "on startup" and then the script. Then in command line,
I typed ./mc test.mt, and wonder of wonders, the script was instantly run
and the text file was created. Cool!
Making the jump to being able to active the test.mt script via CGI, however,
is not working. Both the test.mt file and mc have proper permissions (755).
I've got a test shell script which works fine when called from a browser.
But when I attempt to hit the test.mt script, no dice. Renaming the script
to test.cgi does not help.
One thing - I can run my test shell script (named echo.sh) by typing:
sh echo.sh
in the command line. But typing
mc test.mt
in the command line will not run the test.mt script, yet typing
./mc test.mt
in the command line does. Being a UNIX newbie, I don't know what the ./
does, but you can't execute without it. So perhaps this has something to do
with not being able to execute a script from a browser?
I gotta believe that at least one MetaCard developer has already done all
this. I can't be the first person to try to run MetaCard Darwin engine on
OS X as a replacement for Perl, can I? :)
This is SOOOOOOOOO close and yet so far. The idea of, on OS X, being able
to run METACARD scripts is so cool I can hardly sleep at night.
Anyone have any further suggestions, or is this the end of the line?
:)
Richard MacLemale
Instructional Technology Specialist
James W. Mitchell High School
--------------- MESSAGE metacard.v004.n529.5 ---------------
From: andu <undo at cloud9.net>
Subject: Re: detailed files function
Date: Fri, 23 Nov 2001 10:42:54 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <200111230937.EAA18020 at www.runrev.com>
Rolf Kocherhans wrote:
>
> I am playing with the detailed files function:
>
> -- put the detailed files into field "Current Files"
>
> Is it possible to get the detailed files of a remote file ala:
>
> put "http://www.myserver.ch/test.mc.gz" into href
> put the detailed files of URL href into field "Current Files"
>
> What I need of the file /test.mc.gz is only the creation or the
> modification date, based on a comparison with a local date I would
> then download the file or not.
Not like that. "put "http://www.myserver.ch/test.mc.gz" into href"
downloads the text of the file. Best you can do is use ftp to get a
listing of the directory your file is in and that listing will include
the date the file was modified.
Something like:
put url "ftp://ftp.myserver.ch/directory/" into temp
put line lineOffset("test.mc.gz",temp) of temp into fld "Current Files"
...and get your date from there.
>
> Any help ?
>
> Cheers
> Rolf
>
Andu
--------------- MESSAGE metacard.v004.n529.6 ---------------
From: andu <undo at cloud9.net>
Subject: Re: Win XP: a new dawn
Date: Fri, 23 Nov 2001 10:54:07 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <200111231015.FAA18491 at www.runrev.com>
Dave Cragg wrote:
>
> Hi all
>
> Be warned! The new dawn is what you'll see after working all night
> to see if your old apps still run on XP. :)
>
> First, Metacard seems to run fine. I've had no "engine trouble" so
> far. But XP's new security enforcement may catch you out. (It caught
> me out.)
>
> Two main problems so far: running an installer and writing files to
> places you shouldn't.
>
> But there's an extra twist. If you install XP over a previous OS (NT
> for exmple) it retains the basic security setup of the old OS. This
> is what I did at first, and everything seemed to run as before. I
> told my client that it performs fine under XP (we'd had a report of a
> user not being able to run the app with XP), and he went away happy.
>
> A day later, I re-installed XP following some hardware problems. This
> time I made a clean install. I tried to run the client's app again,
> and things were different. After starting the installer ( older
> version of Wise), I was greeted with a very pretty system message
> that an Administrator password should be used to install applications
> (I was logged in as a plain user). But it gave the option to install
> under the current user account. I tried with the user account, and
> the installer failed with an error about access restrictions. I'm
> guessing it was when writing to the registry.
>
> I installed again, this time giving an Administrator password, and it
> installed fine. But when I ran the installed app from the user
> account, I immediately hit problems. The app writes a file locally in
> the same directory where the standalone is. This is mainly
> configuration data, and I think a number of users on the list use
> this technique. Anyway, this was a no-no. No writing to the Program
> Files directory for plain users.
>
> However, I found that by copying the complete directory that contains
> the standalone and other stacks out of the Program Files directory,
> it would run fine.
>
> I'm now trying to work out what you can and can't do, and also find a
> better strategy for running and deploying the application. But I
> can't find any clear documentation on this, only a number of
> references to thing being different depending on environment: XP
> Home, XP Pro, installed on a workgroup network, installed on a
> domain, etc. So far, it looks like security through obscurity to me,
> but I guess there's a method to it. If someone knows a good reference
> for this, could you let us know.
Microsoft is rewarding its users for buying their new OS the way it
knows best ;-). But then, what else did you expect?
I read about this and other goodies of the wonderful XP on
www.theregister.co.uk.
>
> Cheers
>
> Dave Cragg
>
Andu
--------------- MESSAGE metacard.v004.n529.7 ---------------
From: andu <undo at cloud9.net>
Subject: Re: Darwin, CGI Question
Date: Fri, 23 Nov 2001 11:11:25 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <200111231437.JAA20357 at www.runrev.com>
Richard MacLemale wrote:
>
> Andu wrote,
> > The more empirical way: put home, tools and help stacks in the same
> > folder with the engine and do ./mc and see if metacard starts in gui.
> > Also try .cgi instead of .mt for the cgi file.
> > Test with a cgi known to work just in case the server may not have the
> > proper settings.
>
> That works. I wrote a text file named "test.mt" with a simple script which
> created a text file and put it in the same directory (in this case
> CGI-Executables) as mc and the other stacks. The first line of the file is
> "#!mc" followed by "on startup" and then the script. Then in command line,
> I typed ./mc test.mt, and wonder of wonders, the script was instantly run
> and the text file was created. Cool!
>
> Making the jump to being able to active the test.mt script via CGI, however,
> is not working. Both the test.mt file and mc have proper permissions (755).
> I've got a test shell script which works fine when called from a browser.
> But when I attempt to hit the test.mt script, no dice. Renaming the script
> to test.cgi does not help.
>
> One thing - I can run my test shell script (named echo.sh) by typing:
> sh echo.sh
>
> in the command line. But typing
>
> mc test.mt
>
> in the command line will not run the test.mt script, yet typing
>
> ./mc test.mt
>
> in the command line does. Being a UNIX newbie, I don't know what the ./
> does, but you can't execute without it. So perhaps this has something to do
> with not being able to execute a script from a browser?
No, if you are in a directory (cd /dir) ./ means you want to execute
stuff from *that* directory. If you put mc in a directory listed in
$PATH (probably /usr/bin or /bin) it will do the same like sh.
>
> I gotta believe that at least one MetaCard developer has already done all
> this. I can't be the first person to try to run MetaCard Darwin engine on
> OS X as a replacement for Perl, can I? :)
>
> This is SOOOOOOOOO close and yet so far. The idea of, on OS X, being able
> to run METACARD scripts is so cool I can hardly sleep at night.
>
> Anyone have any further suggestions, or is this the end of the line?
>
> :)
> Richard MacLemale
> Instructional Technology Specialist
> James W. Mitchell High School
>
Andu
--------------- MESSAGE metacard.v004.n529.8 ---------------
From: "Phil Davis" <phildavis at home.com>
Subject: Re: Win XP: a new dawn
Date: Fri, 23 Nov 2001 08:25:00 -0800
References: <200111231015.FAA18491 at www.runrev.com>
Have you looked at Fred Langa's stuff? (http://www.langa.com/) From
there you may find links to groups discussing XP security and the like.
HTH.
Phil
----- Original Message -----
From: "Dave Cragg" <dcragg at lacscentre.co.uk>
To: <metacard at www.runrev.com>
Sent: Friday, November 23, 2001 2:10 AM
Subject: Win XP: a new dawn
> Hi all
>
> Be warned! The new dawn is what you'll see after working all night
> to see if your old apps still run on XP. :)
>
> First, Metacard seems to run fine. I've had no "engine trouble" so
> far. But XP's new security enforcement may catch you out. (It caught
> me out.)
>
> Two main problems so far: running an installer and writing files to
> places you shouldn't.
>
> But there's an extra twist. If you install XP over a previous OS (NT
> for exmple) it retains the basic security setup of the old OS. This
> is what I did at first, and everything seemed to run as before. I
> told my client that it performs fine under XP (we'd had a report of a
> user not being able to run the app with XP), and he went away happy.
>
> A day later, I re-installed XP following some hardware problems. This
> time I made a clean install. I tried to run the client's app again,
> and things were different. After starting the installer ( older
> version of Wise), I was greeted with a very pretty system message
> that an Administrator password should be used to install applications
> (I was logged in as a plain user). But it gave the option to install
> under the current user account. I tried with the user account, and
> the installer failed with an error about access restrictions. I'm
> guessing it was when writing to the registry.
>
> I installed again, this time giving an Administrator password, and it
> installed fine. But when I ran the installed app from the user
> account, I immediately hit problems. The app writes a file locally in
> the same directory where the standalone is. This is mainly
> configuration data, and I think a number of users on the list use
> this technique. Anyway, this was a no-no. No writing to the Program
> Files directory for plain users.
>
> However, I found that by copying the complete directory that contains
> the standalone and other stacks out of the Program Files directory,
> it would run fine.
>
> I'm now trying to work out what you can and can't do, and also find a
> better strategy for running and deploying the application. But I
> can't find any clear documentation on this, only a number of
> references to thing being different depending on environment: XP
> Home, XP Pro, installed on a workgroup network, installed on a
> domain, etc. So far, it looks like security through obscurity to me,
> but I guess there's a method to it. If someone knows a good reference
> for this, could you let us know.
>
>
> Cheers
>
> Dave Cragg
>
> Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
> Info: http://www.xworlds.com/metacard/mailinglist.htm
> Please send bug reports to <bugs at metacard.com>, not this list.
>
--------------- MESSAGE metacard.v004.n529.9 ---------------
From: "Phil Davis" <phildavis at home.com>
Subject: Re: Darwin, CGI Question
Date: Fri, 23 Nov 2001 08:49:30 -0800
References: <200111231437.JAA20357 at www.runrev.com>
Hi Richard,
Partial answer...
----- Original Message -----
From: "Richard MacLemale" <rmaclemale at earthlink.net>
To: <metacard at www.runrev.com>
Sent: Friday, November 23, 2001 6:37 AM
Subject: Re: Darwin, CGI Question
>
> in the command line does. Being a UNIX newbie, I don't know what the
./
> does, but you can't execute without it. So perhaps this has something
to do
> with not being able to execute a script from a browser?
"./" before a filename means "use the current directory as the relative
path for the filename". So if your 'pwd' is:
/export/home/rmaclemale/cgi-bin
and you type on the command line:
./somescript.mt
the OS will look for (and try to execute) a file named:
/export/home/rmaclemale/cgi-bin/somescript.mt
Similarly, "../" means "use the 'parent' directory of the current
directory (the next directory up) as the relative path..."
Since you're a self-proclaimed Unix newbie, I'll venture one more thing:
I don't know specifically about your system, but Unix normally has a
built-in technical "manual" (aka "man pages") that you can use to learn
what a command means. So if you type this on a command line:
man pwd
You'll be shown the 'man page' describing the 'pwd' command.
Phil
--------------- MESSAGE metacard.v004.n529.10 ---------------
From: Dave Cragg <dcragg at lacscentre.co.uk>
Subject: Re: Win XP: a new dawn
Date: Fri, 23 Nov 2001 22:24:19 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
References: <200111231015.FAA18491 at www.runrev.com>
<200111231628.LAA21425 at www.runrev.com>
In-Reply-To: <200111231628.LAA21425 at www.runrev.com>
At 8:25 am -0800 23/11/01, Phil Davis wrote:
>Have you looked at Fred Langa's stuff? (http://www.langa.com/) From
>there you may find links to groups discussing XP security and the like.
Thanks for the link, Phil.
My initial frustration was mainly due to the "default" installation
varying depending on circumstances: upgrading or a clean install, on
a local network or a domain. This affects the options that are
presented and parts of the user interface, which makes it difficult
to track down problems that another user is having. The lack of
documentation doesn't help, but I went out and bought a book
(remember those?) to see if I can get get some kind of overview.
I'm still not sure whether I've bumped into something new (compared
to NT, 2000) , or whether it's just different default settings. But I
think I may need a new strategy for storing configuration data.
So far, my overall impression of XP is the usual mix of impressive
engineering and "we-know-what's-good-for-you" interface design.
(nagging you to Activate every 10 minutes, or get a Passport Account
every time the cursor gets near Messenger icon).
Cheers
Dave Cragg
PS Metacard's visual effects, without QuickTime, work as smooth as silk. :)
--------------- END metacard.v004.n529 ---------------
More information about the metacard
mailing list