running shell scripts from Filemaker Pro

I find allusions to OSX Filemaker 8 having the ability to run
Unix shell scripts directly.

But I've looked in various places for the specifics, to no avail.
My attempts to ask the Filemaker KBase always brings up zillions of
"script" responses where it refers to FPM scripts, not bash scripts.

Can someone point me in the right direction? Thank you.

--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro

David Lesher wrote:

> I find allusions to OSX Filemaker 8 having the ability to run
> Unix shell scripts directly.
>
> But I've looked in various places for the specifics, to no avail.
> My attempts to ask the Filemaker KBase always brings up zillions of
> "script" responses where it refers to FPM scripts, not bash scripts.
>
> Can someone point me in the right direction? Thank you.

A FMP script can run an AppleScript which can do shell scripts


--
erik

Re: running shell scripts from Filemaker Pro

wez@invalid.mac.com (Erik Wessel-Berg) writes:

>David Lesher wrote:

>> I find allusions to OSX Filemaker 8 having the ability to run
>> Unix shell scripts directly.
>>
>> But I've looked in various places for the specifics, to no avail.
>> My attempts to ask the Filemaker KBase always brings up zillions of
>> "script" responses where it refers to FPM scripts, not bash scripts.
>>
>> Can someone point me in the right direction? Thank you.

>A FMP script can run an AppleScript which can do shell scripts
>

Thanks; it looks like I misunderstood the FMP8 Techbrief. I thought
it implied a direct route.
--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro SERVER

I just realized this won't work anyhow; some clients are still
running M$ not OSX. No bash scripts there!

How hard is it to get a client to invoke a script on the server?
[It's running Server 8 on OSX.]
--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro SERVER

David Lesher wrote:
> I just realized this won't work anyhow; some clients are still
> running M$ not OSX. No bash scripts there!
>
> How hard is it to get a client to invoke a script on the server?
> [It's running Server 8 on OSX.]

You can SCHEDULE shell scripts to run on Server 9. And I imagine there
are probably ways of triggering such things on the server from a client
using AppleScript.

Re: running shell scripts from Filemaker Pro SERVER

On Oct 10, 9:24 am, Howard Schlossberg
wrote:
> David Lesher wrote:
> > I just realized this won't work anyhow; some clients are still
> > running M$ not OSX. No bash scripts there!
>
> > How hard is it to get a client to invoke a script on the server?
> > [It's running Server 8 on OSX.]
>
> You can SCHEDULE shell scripts to run on Server 9. And I imagine there
> are probably ways of triggering such things on the server from a client
> using AppleScript.

You can schedule regular scripts on Server 9 if I understand it right.
And there is certainly a way of triggering those from a client within
filemaker, and since a regular script can run a shell script your home
free... on server 9.

Re: running shell scripts from Filemaker Pro SERVER

Howard Schlossberg writes:

>> How hard is it to get a client to invoke a script on the server?
>> [It's running Server 8 on OSX.]

>You can SCHEDULE shell scripts to run on Server 9. And I imagine there
>are probably ways of triggering such things on the server from a client
>using AppleScript.

Don't want to schedule; do need to trigger.

Our FMP developer is not sure either; no one's ever asked her that before.

--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro SERVER

d-42 writes:


>You can schedule regular scripts on Server 9 if I understand it right.
>And there is certainly a way of triggering those from a client within
>filemaker, and since a regular script can run a shell script your home
>free... on server 9.

Any hints on the 'way of triggering'? I'm not a FMP programmer, and
while ours is good on many things, she did not know this.

Specifically: we want to is [do several other things in FMP..] then kick
off a script that creates two export XML files. Then we'll scp them off
the box to elsewhere.

But the Kbase Answers 5496, 6443 & 6223 all discuss Server Admin type
things. Do we need to do the above FMP export on a server-local copy of
8.5; or can they be done on Server itself?


--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro SERVER

David Lesher wrote:
> we want to is [do several other things in FMP..] then kick
> off a script that creates two export XML files. Then we'll scp them off
> the box to elsewhere.
>
> But the Kbase Answers 5496, 6443 & 6223 all discuss Server Admin type
> things. Do we need to do the above FMP export on a server-local copy of
> 8.5; or can they be done on Server itself?

The export of data can only be done from a client machine. Exports can
not be done from FM Server. This could be something that is part of the
local client routine for whatever triggers it. Or it might be that the
client routine flags records as ready to export and then you have a
standalone 'bot' machine running every 15 minutes (or every two minute
or whatever) to find the flagged records, export and upload. Whether
the export is done immediately on the client machine or a few minutes
later on the bot machine, the FileMaker script would then use the Send
Event step to send a command line to scp to offload the files. The only
real trick to this is the timing between export and scp trigger, and
then the capturing of any error messages from scp back into your FMP
script. But it can all be done without too much extra work.

Re: running shell scripts from Filemaker Pro SERVER

Howard Schlossberg writes:

>> we want to is [do several other things in FMP..] then kick
>> off a script that creates two export XML files. Then we'll scp them off
>> the box to elsewhere.
>>
>> But the Kbase Answers 5496, 6443 & 6223 all discuss Server Admin type
>> things. Do we need to do the above FMP export on a server-local copy of
>> 8.5; or can they be done on Server itself?

>The export of data can only be done from a client machine. Exports can
>not be done from FM Server.


Bummer. Thanks for clearing this up.

The issue is; while most of the clients are OSX, a few are alas running
XP. An Appletalk call to a shell script will not work very well in XP.

Even if our FMP programmer knew how to make the client run the Mac script
on Macs, vs a Windoze one on XP; I have no desire to learn how to build
such scripts in XP for those few users.

Triggering is not a problem. The "Update Push" will be a FMP
pushbutton, I'm told. It will export, than scp the xml files.


--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro SERVER

Howard Schlossberg writes:

>Or it might be that the client routine flags records as ready to export
>and then you have a standalone 'bot' machine running every 15 minutes
>(or every two minute or whatever) to find the flagged records, export
>and upload. Whether the export is done immediately on the client
>machine or a few minutes later on the bot machine, the FileMaker script
>would then use the Send Event step to send a command line to scp to
>offload the files.

>The only real trick to this is the timing between export and scp
>trigger, and then the capturing of any error messages from scp back into
>your FMP script. But it can all be done without too much extra work.


Rereading:

A) OK, suppose we leave FMP8.5 running on the server box.
Or can it be cron'ed?

[Issues; how will it startup & login to server? I guess it could
have a no-password account if such could be bound to 1.27.0.0.1?]


B) It wakes up and looks for some kind of flag in FMP's tables that the
client set. We really want it operator-instigated; you might sit down
make changes for an hour and THEN push the results.

[Here, I have no idea what, but suspect you can suggest how. A field of
some kind gets a non-zero entry, a datestamp? Or is there a "something
in Tablename X has changed" function from FMP?]


C) The local-client then does the exports, and then does a Send Event
to start up its scp job. Can't this script wait for the export creation?

[Not clear what Send Event does vice "Perform Applescript - sh" but OK for now.]

Capturing error logs would be nice but not sure how generic clients
would see 'em. Should show up in the Console log, however.




--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro SERVER

On Oct 11, 9:32 pm, David Lesher wrote:
> Howard Schlossberg writes:
> >Or it might be that the client routine flags records as ready to export
> >and then you have a standalone 'bot' machine running every 15 minutes
> >(or every two minute or whatever) to find the flagged records, export
> >and upload. Whether the export is done immediately on the client
> >machine or a few minutes later on the bot machine, the FileMaker script
> >would then use the Send Event step to send a command line to scp to
> >offload the files.
> >The only real trick to this is the timing between export and scp
> >trigger, and then the capturing of any error messages from scp back into
> >your FMP script. But it can all be done without too much extra work.
>
> Rereading:
>
> A) OK, suppose we leave FMP8.5 running on the server box.
> Or can it be cron'ed?
>
> [Issues; how will it startup & login to server? I guess it could
> have a no-password account if such could be bound to 1.27.0.0.1?]
>
> B) It wakes up and looks for some kind of flag in FMP's tables that the
> client set. We really want it operator-instigated; you might sit down
> make changes for an hour and THEN push the results.
>
> [Here, I have no idea what, but suspect you can suggest how. A field of
> some kind gets a non-zero entry, a datestamp? Or is there a "something
> in Tablename X has changed" function from FMP?]
>
> C) The local-client then does the exports, and then does a Send Event
> to start up its scp job. Can't this script wait for the export creation?
>
> [Not clear what Send Event does vice "Perform Applescript - sh" but OK for now.]
>
> Capturing error logs would be nice but not sure how generic clients
> would see 'em. Should show up in the Console log, however.
>
> --
> A host is a host from coast to coast.................wb8...@nrk.com
> & no one will talk to a host that's close........[v].(301) 56-LINUX
> Unless the host (that isn't close).........................pob 1433
> is busy, hung or dead....................................20915-1433

David,

'Send Event' is the Windows counterpart of the Perform AppleScript
script step. It lets you perform a batch script, trigger a vb script,
a batch script or open any program or document.

Anyhow, if using a plug-in is any option and you have someone familiar
with PHP, I would strongly recommend using the SmartPill PHP plug-in
or Schubec PHP plug-in. This let's you do all things you can do with
PHP (like interact witht the filesystem, FTP, ...) and would suit in a
multi-platform environment, as you don't have to create a different
scripts for Mac and Windows (there have to be differences, but they
can be passed as parameters to the PHP scripts).

HTH

Jeroen Aarts

Re: running shell scripts from Filemaker Pro SERVER

On Oct 10, 12:37 pm, David Lesher wrote:
> d-42 writes:
> >You can schedule regular scripts on Server 9 if I understand it right.
> >And there is certainly a way of triggering those from a client within
> >filemaker, and since a regular script can run a shell script your home
> >free... on server 9.
>
> Any hints on the 'way of triggering'? I'm not a FMP programmer, and
> while ours is good on many things, she did not know this.
>
> Specifically: we want to is [do several other things in FMP..] then kick
> off a script that creates two export XML files. Then we'll scp them off
> the box to elsewhere.

If you want the fm script to trigger a script on the server, and you
are running FM server 9 you define a utility table with no records.
Then the client machine creates a record in the utility table when it
wants to trigger the script.

The server is set to run an FM script every minute, or 5 minutes, or
as often as need be. That script checks if there are any new records,
and if there are, performs the export etc. You can use the fields in
the utility table to pass parameters to the server script operation.
It deletes the records (or marks them as completed, or stores the
result, or whatever you need.)

As you can see the clients don't need anything special. They work
entirely in filemaker so client platform is not an issue.

If you don't have server 9, you can get close to the same
functionality by running a fmpro client dedicated to this task.

-Dave

Re: running shell scripts from Filemaker Pro SERVER

d-42 writes:


>If you want the fm script to trigger a script on the server, and you
>are running FM server 9 you define a utility table with no records.
>Then the client machine creates a record in the utility table when it
>wants to trigger the script.

>The server is set to run an FM script every minute, or 5 minutes, or
>as often as need be. That script checks if there are any new records,
>and if there are, performs the export etc. You can use the fields in
>the utility table to pass parameters to the server script operation.
>It deletes the records (or marks them as completed, or stores the
>result, or whatever you need.)

That's triggering, but from what Howard said, we can't run the
export/XML creation step on Server anyhow.

>As you can see the clients don't need anything special. They work
>entirely in filemaker so client platform is not an issue.

Provided the export/XML is done by Server... but it can't.
If we do the export to XML on clients, they must cope with
two platforms to move the XML..

>If you don't have server 9, you can get close to the same
>functionality by running a fmpro client dedicated to this task.

We could move from 8->9 [unless that requires we change all the clients
as well..] But that raises some new issues. We have to have a way to
start that client at boot; restart if it loses connection, etc.

--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro SERVER

On Oct 12, 10:11 am, David Lesher wrote:
> d-42 writes:
> >If you want the fm script to trigger a script on the server, and you
> >are running FM server 9 you define a utility table with no records.
> >Then the client machine creates a record in the utility table when it
> >wants to trigger the script.
> >The server is set to run an FM script every minute, or 5 minutes, or
> >as often as need be. That script checks if there are any new records,
> >and if there are, performs the export etc. You can use the fields in
> >the utility table to pass parameters to the server script operation.
> >It deletes the records (or marks them as completed, or stores the
> >result, or whatever you need.)
>
> That's triggering, but from what Howard said, we can't run the
> export/XML creation step on Server anyhow.

Ah, he's right. Only web compatible script steps are supported. Import/
Export are sadly excluded.

That said, maybe if you could expose a shared folder on the server,
and export from the clients into it? And then schedule a shell script
to handle the contents of the folder?

> >As you can see the clients don't need anything special. They work
> >entirely in filemaker so client platform is not an issue.
>
> Provided the export/XML is done by Server... but it can't.
> If we do the export to XML on clients, they must cope with
> two platforms to move the XML..

> >If you don't have server 9, you can get close to the same
> >functionality by running a fmpro client dedicated to this task.
>
> We could move from 8->9 [unless that requires we change all the clients
> as well..]

Fortunately they wouldn't have to upgraded.

> But that raises some new issues. We have to have a way to
> start that client at boot; restart if it loses connection, etc.

Starting a dedicated client at startup is relatively easy. You create
a 'launcher database' and drop that into your startup items. The
launcher is basically little more than fm database that does little
more than run a start up script that opens the remote database under a
specified account, and then closes.

Restart after loss of connection is harder. But in my experience not
usually necessary. Make restarting that client part of the procedure
for restarting the server. And unless something is wrong with your
install/network it shouldn't ever lose connection otherwise.



All that said, lets take a step back ... what do you -actually- need
to accomplish? I mean maybe exporting, and then scp isn't the best
solution?

Alternatively handling it on both XP and OSX while more work, than
just one platform, isn't as bad as you might think in many cases.

-cheers
Dave

Re: running shell scripts from Filemaker Pro SERVER

d-42 writes:

>On Oct 12, 10:11 am, David Lesher wrote:

>All that said, lets take a step back ... what do you -actually- need
>to accomplish? I mean maybe exporting, and then scp isn't the best
>solution?

>Alternatively handling it on both XP and OSX while more work, than
>just one platform, isn't as bad as you might think in many cases.



We have a FMP database updated by <10 people. They are the only people
with direct access.

We take some of that data, export it as multiple XML files, and load that
data into a PHP-driven public site. There, the data is viewed but not
altered. [1]

This way, there's an airgap between the two databases [as well as 300
miles..]. Murphy himself could strike down the web site with lightning
bolts and FMP won't know or care.

PHP holes gets your website "had"? Wipe space, reload from program BU,
and export data again. Further, the site is up even when the FMP server
is not.

So the FMP programmer has written a script to create the XML files on the
client's local storage. We presently have a item on the website maint.
page to "Point & Upload" those files, one at a time.

We want a better way. We can use scp to push the files up. We can trigger
the PHP update when the scp ends. The site takes it from there.

But the Windoze boxes can't accept a bash script. That means jumping
through M$ hoops, not to mention a FMP script that tests environment so it
know if it should use a bash script or a M$ one, etc.

So my bright idea was to get the FMP client to instigate the export process
on the server. When that idea tanked, I started thinking about doing it
on the client copy installed on the server box.

That's how I got here...




1] Actually, we will soon want to snarf some logging data for analysis, but
that's separate.

--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro SERVER

I don't recommend running a copy of any application, including FM Pro,
on your FM server. Put it on another server perhaps. If instead of a
2-minute (or whatever time) schedule, you can have the machines actually
trigger ech other using the Troi Activator plugin for FileMaker. But
then, if you're going to put plugins on all 10 user machines, you might
as well ditch the bot and just use the FTPit plugin on each client machine.

David Lesher wrote:
> d-42 writes:
>
>> On Oct 12, 10:11 am, David Lesher wrote:
>
>> All that said, lets take a step back ... what do you -actually- need
>> to accomplish? I mean maybe exporting, and then scp isn't the best
>> solution?
>
>> Alternatively handling it on both XP and OSX while more work, than
>> just one platform, isn't as bad as you might think in many cases.
>
>
>
> We have a FMP database updated by <10 people. They are the only people
> with direct access.
>
> We take some of that data, export it as multiple XML files, and load that
> data into a PHP-driven public site. There, the data is viewed but not
> altered. [1]
>
> This way, there's an airgap between the two databases [as well as 300
> miles..]. Murphy himself could strike down the web site with lightning
> bolts and FMP won't know or care.
>
> PHP holes gets your website "had"? Wipe space, reload from program BU,
> and export data again. Further, the site is up even when the FMP server
> is not.
>
> So the FMP programmer has written a script to create the XML files on the
> client's local storage. We presently have a item on the website maint.
> page to "Point & Upload" those files, one at a time.
>
> We want a better way. We can use scp to push the files up. We can trigger
> the PHP update when the scp ends. The site takes it from there.
>
> But the Windoze boxes can't accept a bash script. That means jumping
> through M$ hoops, not to mention a FMP script that tests environment so it
> know if it should use a bash script or a M$ one, etc.
>
> So my bright idea was to get the FMP client to instigate the export process
> on the server. When that idea tanked, I started thinking about doing it
> on the client copy installed on the server box.
>
> That's how I got here...
>
>
>
>
> 1] Actually, we will soon want to snarf some logging data for analysis, but
> that's separate.
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Professional Solutions, Inc. Los Angeles

FileMaker 8 Certified Developer
Associate Member, FileMaker Solutions Alliance

Re: running shell scripts from Filemaker Pro SERVER

On Oct 13, 1:46 am, Howard Schlossberg
wrote:
> I don't recommend running a copy of any application, including FM Pro,
> on your FM server. Put it on another server perhaps. If instead of a
> 2-minute (or whatever time) schedule, you can have the machines actually
> trigger ech other using the Troi Activator plugin for FileMaker. But
> then, if you're going to put plugins on all 10 user machines, you might
> as well ditch the bot and just use the FTPit plugin on each client machine.
>
>
>
>
>
> David Lesher wrote:
> > d-42 writes:
>
> >> On Oct 12, 10:11 am, David Lesher wrote:
>
> >> All that said, lets take a step back ... what do you -actually- need
> >> to accomplish? I mean maybe exporting, and then scp isn't the best
> >> solution?
>
> >> Alternatively handling it on both XP and OSX while more work, than
> >> just one platform, isn't as bad as you might think in many cases.
>
> > We have a FMP database updated by <10 people. They are the only people
> > with direct access.
>
> > We take some of that data, export it as multiple XML files, and load that
> > data into a PHP-driven public site. There, the data is viewed but not
> > altered. [1]
>
> > This way, there's an airgap between the two databases [as well as 300
> > miles..]. Murphy himself could strike down the web site with lightning
> > bolts and FMP won't know or care.
>
> > PHP holes gets your website "had"? Wipe space, reload from program BU,
> > and export data again. Further, the site is up even when the FMP server
> > is not.
>
> > So the FMP programmer has written a script to create the XML files on the
> > client's local storage. We presently have a item on the website maint.
> > page to "Point & Upload" those files, one at a time.
>
> > We want a better way. We can use scp to push the files up. We can trigger
> > the PHP update when the scp ends. The site takes it from there.
>
> > But the Windoze boxes can't accept a bash script. That means jumping
> > through M$ hoops, not to mention a FMP script that tests environment so it
> > know if it should use a bash script or a M$ one, etc.
>
> > So my bright idea was to get the FMP client to instigate the export process
> > on the server. When that idea tanked, I started thinking about doing it
> > on the client copy installed on the server box.
>
> > That's how I got here...
>
> > 1] Actually, we will soon want to snarf some logging data for analysis, but
> > that's separate.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Howard Schlossberg (818) 883-2846
> FM Professional Solutions, Inc. Los Angeles
>
> FileMaker 8 Certified Developer
> Associate Member, FileMaker Solutions Alliance- Hide quoted text -
>
> - Show quoted text -

I have done this in the past, setting up a robot client (on a
dedicated client machine), using the ScriptFire plug-in to run a
script every so often.

- Jeroen

Re: running shell scripts from Filemaker Pro SERVER

> > But the Windoze boxes can't accept a bash script.

True, although depending on what you need, Cygwin might cover your
needs for bash on Windows.

> > That means jumping
> > through M$ hoops, not to mention a FMP script that tests environment so it
> > know if it should use a bash script or a M$ one, etc.

That last is easy: see Get(SystemPlatform) in Filemaker Help.

> > So my bright idea was to get the FMP client to instigate the export process
> > on the server. When that idea tanked, I started thinking about doing it
> > on the client copy installed on the server box.
>
> > That's how I got here...

The first thought that springs to mind is to look at a pull based
solution instead of a push. Maybe have your remote website pull the
data it needs. (create a read-only account to FM), and write a php/
ODBC or pull it via XML from FM Server using that read-only account,
or even via custom webpublishing. (ie don't use filemaker to host your
remote website, but use it to host the files you want your remote site
to access; and then pull them when you need to update them. That keeps
your airgap and separation.

To trigger the update, you visit the remote site and press a link to
trigger the pull. (The link would be behind some admin login or
something, not on the public face of the site of course.) You could
even configure the FM client to "OpenURL" on the webserver to trigger
it.

Note: to get there you'd need to upgrade to FM Server Advanced to get
ODBC/JDBC/XML/Web access to the filemaker data.

Anyhow, its a completely different way of approaching your problem.
And food for thought if nothing else.

I'd also recommend checking into Cygwin to see if that gets you where
you need to go.

-cheers,
Dave

Re: running shell scripts from Filemaker Pro SERVER

d-42 writes:


>> > But the Windoze boxes can't accept a bash script.

>True, although depending on what you need, Cygwin might cover your
>needs for bash on Windows.

I'd rather NOT try to script anything on Windoze. There are few machines,
but no two are the same. They are hundreds to thousands of miles away.


>The first thought that springs to mind is to look at a pull based
>solution instead of a push. Maybe have your remote website pull the
>data it needs. (create a read-only account to FM), and write a php/
>ODBC or pull it via XML from FM Server using that read-only account,
>or even via custom webpublishing. (ie don't use filemaker to host your
>remote website, but use it to host the files you want your remote site
>to access; and then pull them when you need to update them. That keeps
>your airgap and separation.

Sounds likes lots of programming for that person. More things that
are somewhat complex. The beauty of the scp solution is it is simple.

>Note: to get there you'd need to upgrade to FM Server Advanced to get
>ODBC/JDBC/XML/Web access to the filemaker data.

More $$$....

>Anyhow, its a completely different way of approaching your problem.
>And food for thought if nothing else.

Thanks, but it's way too much of a solution for a smallish
problem. If this was a bigger operation, maybe...

--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro SERVER

Howard Schlossberg writes:

>I don't recommend running a copy of any application, including FM Pro,
>on your FM server. Put it on another server perhaps. If instead of a
>2-minute (or whatever time) schedule, you can have the machines actually
>trigger ech other using the Troi Activator plugin for FileMaker. But
>then, if you're going to put plugins on all 10 user machines, you might
>as well ditch the bot and just use the FTPit plugin on each client machine.


Interesting... Why is that? I have no other box to put it on, even if
I could afford to 'waste' a Dual MDD stuffed with drives and RAM on one
sole app.

The LAST thing I want to do is put plugins on 10 boxes in 8 states.

The beauty of the FMP script approach is it is in effect no installation.
If M$ 2K/XP had a builtin scp, I might see a dual-headed script. But
AFAIK, it does not.

We'll likely stick with the current website upload push.



--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro SERVER

On Oct 13, 7:32 pm, David Lesher wrote:
> d-42 writes:
> >> > But the Windoze boxes can't accept a bash script.
> >True, although depending on what you need, Cygwin might cover your
> >needs for bash on Windows.
>
> I'd rather NOT try to script anything on Windoze. There are few machines,
> but no two are the same. They are hundreds to thousands of miles away.

Cygwin is a linux/bash environment for "windoze". With cygwin
installed you can likely run very nearly the same bash script on both
OSX and windows. Granted, debugging any problems that do crop up (even
on an a remote OSX box) would be a hassle. Ideally you want your
client side stuff to exist entirely in filemaker.

> >The first thought that springs to mind is to look at a pull based
> >solution instead of a push. Maybe have your remote website pull the
> >data it needs. (create a read-only account to FM), and write a php/
> >ODBC or pull it via XML from FM Server using that read-only account,
> >or even via custom webpublishing. (ie don't use filemaker to host your
> >remote website, but use it to host the files you want your remote site
> >to access; and then pull them when you need to update them. That keeps
> >your airgap and separation.

> Sounds likes lots of programming for that person. More things that
> are somewhat complex. The beauty of the scp solution is it is simple.

It should actually be less work than the solution you are proposing,
and has fewer 'moving parts'. We don't have to trigger an export on
the server at all (something that is proving exceedingly hard). We
don't have to scp anything.

The remote site is just grabbing what it needs directly out of
filemaker and saving it directly at the remote location. Its a far
cleaner scenario, I think.

> >Note: to get there you'd need to upgrade to FM Server Advanced to get
> >ODBC/JDBC/XML/Web access to the filemaker data.
>
> More $$$....

Yes, I realized that. And I can understand you not wanting to go that
route. Especially as you may not be able to upgrade to server 8
advanced easily given that 9 is out now.

Again, talking about Server Advanced, you could trivially build your
'push' system, by having a bash script on the server run an odbc query
to pull the data that you want from the server to files, and then scp
those files to your remote web server. Against, we're pulling via ODBC
instead of pushing from Filemakers Export function, but its still
pretty simple.

Really, the more I think about this, and your desire, fundamentally,
to move data directly from filemaker server 'elsewhere', the more I
come to beleiving that FMS Advanced is the most logical solution.

That said, from server 8 to server 9 advanced is $2499. not having to
upgrade the clients is helpful at least, but that, i agree, is pretty
high for someone in your circumstances.

But, thinking in other directions...

Do you have the ability to install filemaker pro on the remote
webserver? If so you could triggered that to launch (trivial), and on
launch run a local database [ie local to your remote server] that
connected to your database and exported the requisite data [right onto
the remote web server], and then shutdown until it was triggered
again. Or some variation on that theme. Basically its the 'dedicated
client' idea, but co-located on your remote web server, and only
running on-demand.

Finally, and thinking again, on the 'cheap' side of things. I'd
consider setting up the whole bash/export/scp script on just one OSX
box locally...

And then "wire it up" one of two ways.

a) whenever any remote client needs to update they call that person or
send a message or whatever, and that person runs the script manually.
This is obviously a 'poor mans' solution, but it gets the job done,
and is suitable if updates are infrequent enough.

b) whenever *any* remote client needs to update the website, it gets
logged in a utility table in the database. Then attach a script to all
your most common database buttons that only runs if the one dedicated
computer runs it. (simply wrap the script in a Get(Hostname) check).
This script will checks the utility database and run the export/upload
script whenever needed. So any machine can request the update, and
eventually the machine that actually does the updates will process it.

I've done 'b' type solutions; I attached the script that needed to get
run on the 'dedicated computer' to common buttons like 'go to main
menu', 'complete order', 'go to customers', etc. The idea is that the
'check if work needs to be done' script gets run every few minutes on
the computer that can actually do the exports just through normal
usage, and does them when ever it notes work is needed. Obviously this
solution is only suitable if you've got someone actively using the
'dedicated' machine all day, so that the various triggers will get hit
often enough.

You can optionally also add a plugin to run the check script on a
regular basis whether the user 'triggers' it or not. In this case its
a plug in on one machine, so the cost is minimal. There is
inconvenience to that one user of occasionally being interrupted by a
scheduled script that switches to filemaker and checks if updates are
needed.

Ideally, if this is the route your taking your going to want to
shedule it every hour or so, rather than every two minutes, and
ideally, locate it on a machine that doesn't get heavy use to minimize
the annoyance.

-cheers,
Dave

Re: running shell scripts from Filemaker Pro SERVER

d-42 writes:


>That said, from server 8 to server 9 advanced is $2499. not having to
>upgrade the clients is helpful at least, but that, i agree, is pretty
>high for someone in your circumstances.

The customer would not go that way, period. [Even though we have
FMS9 undeployed.

>Do you have the ability to install filemaker pro on the remote
>webserver?

I doubt FMP will run under NetBSD.....

[Add dedicated FMP client box]

>And then "wire it up" one of two ways.

>a) whenever any remote client needs to update they call that person or
>send a message or whatever, and that person runs the script manually.
>This is obviously a 'poor mans' solution, but it gets the job done,
>and is suitable if updates are infrequent enough.

They will be frequent. Say several times/day.

>b) whenever *any* remote client needs to update the website, it gets
>logged in a utility table in the database. Then attach a script to all
>your most common database buttons that only runs if the one dedicated
>computer runs it. (simply wrap the script in a Get(Hostname) check).
>This script will checks the utility database and run the export/upload
>script whenever needed. So any machine can request the update, and
>eventually the machine that actually does the updates will process it.


Not sure if I follow that [my thinking is under attack by an allegy
attack today...] But one thing we want is near-realtime results. We
want to require a SOP that "After making a change; look at the site
and be sure they are shown correctly..."


>I've done 'b' type solutions; I attached the script that needed to get
.....

Interesting. But for now it's clear the web file push scheme we now have
has as many advantages as other approaches... It would be nicer to have a
one-step, not two, solution; but it's far from bad.

--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: running shell scripts from Filemaker Pro SERVER

On Oct 14, 4:46 pm, David Lesher wrote:
> d-42 writes:
> >That said, from server 8 to server 9 advanced is $2499. not having to
> >upgrade the clients is helpful at least, but that, i agree, is pretty
> >high for someone in your circumstances.
>
> The customer would not go that way, period. [Even though we have
> FMS9 undeployed.

Given you have FMS9 undeployed, the cost to upgrade drops to $1499.00.

I'm curious why the 'customer would not go that way'.

Is it simply the money overall (e.g. cost of software upgrade plus
cost of deployment plus of developing new scripts) or is it something
else, like 'risk of problems (e.g. upgrading to S9, etc)'?

> Interesting. But for now it's clear the web file push scheme we now have
> has as many advantages as other approaches... It would be nicer to have a
> one-step, not two, solution; but it's far from bad.

Yes I agree. The solution you have now is probably the 2nd best over
all as a techical solution, given what you want and what you have. And
given that you've already got this solution in place and working the
value of changing it is debatable especially given the cost whether
'upgrading' to S9A is worth it.

Re: running shell scripts from Filemaker Pro SERVER

d-42 writes:

>> >That said, from server 8 to server 9 advanced is $2499. not having to
>> >upgrade the clients is helpful at least, but that, i agree, is pretty
>> >high for someone in your circumstances.
>>
>> The customer would not go that way, period. [Even though we have
>> FMS9 undeployed.

>Given you have FMS9 undeployed, the cost to upgrade drops to $1499.00.

>I'm curious why the 'customer would not go that way'.

>Is it simply the money overall (e.g. cost of software upgrade plus
>cost of deployment plus of developing new scripts) or is it something
>else, like 'risk of problems (e.g. upgrading to S9, etc)'?

All of the above. That's a lot of money that buys very little.

>> Interesting. But for now it's clear the web file push scheme we now have
>> has as many advantages as other approaches... It would be nicer to have a
>> one-step, not two, solution; but it's far from bad.

>Yes I agree. The solution you have now is probably the 2nd best over
>all as a techical solution, given what you want and what you have. And
>given that you've already got this solution in place and working the
>value of changing it is debatable especially given the cost whether
>'upgrading' to S9A is worth it.

A friend claims XP has a scp builtin; if so, we might later try that
as a dual-platform script.


--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Default file locations/behaviour

I'm back with all new dumb questions.

The FMP programer [who speaks M$ about as well as I do; ie we run in
fear..] needs to script writing the XML files to local storage.



THEN, a fileviewer will point to the web site's maint page & prompt
for upload.

The hassle is: WHERE on the local box? Per the above FMP defaults
to the APPLICATION's subdirectory; grr..

In OSX, it can be written as /tmp/sample.xml or ~/sample.xml.

But in M$? A guru who works in Redmond tells me:

>No, there's no environment variable, built in junction, or built-in
>cmd shortcut to it (not that any but the junction would help you)




....

>%USERPROFILE% is the current user's profile folder. The current user's
>document folder is one folder underneath that [1], either "My Documents"
>or just "Documents" [2] depending on the system.

He added:

>I don't speak FMP, but it looks like there's some sort of variable
>support, and a function called "Get(DocumentsPath)" that seems like
>it'll give you a FMP friendly path to the My Documents folder that you
>should be able to feed to the path you store the target file in.


Now; the XML need not go on th desktop, and there is
TMP=C:\DOCUME~1\[blah-user]\LOCALS~1\Temp
that might work.

But I'm not conversant in either M$ internals or FMP's to know what best/works at all.

tmp would be ideal except for one gotcha; when you spawn a webviewer, and it pops
up a CHOOSE-A-FILE box; what directory does IT start in? In OSX, at least, it does
not allow easy [if at all..] Finder browsing to /tmp.

1) How do you write FMP scripts that specify a known-writeable/findable destination
independent of client type/configuration?

2) And... Will a new write automatically overwrite the existing file of that name,
or should we erase it first?


--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: Default file locations/behaviour

On Oct 18, 11:49 am, David Lesher wrote:
> I'm back with all new dumb questions.
>
> The FMP programer [who speaks M$ about as well as I do; ie we run in
> fear..] needs to script writing the XML files to local storage.
>
>
>
> THEN, a fileviewer will point to the web site's maint page & prompt
> for upload.
>
> The hassle is: WHERE on the local box? Per the above FMP defaults
> to the APPLICATION's subdirectory; grr..
>
> In OSX, it can be written as /tmp/sample.xml or ~/sample.xml.
>
> But in M$? A guru who works in Redmond tells me:
>
> >No, there's no environment variable, built in junction, or built-in
> >cmd shortcut to it (not that any but the junction would help you)
>
>
>
> ...
>
> >%USERPROFILE% is the current user's profile folder. The current user's
> >document folder is one folder underneath that [1], either "My Documents"
> >or just "Documents" [2] depending on the system.
>
> He added:
>
> >I don't speak FMP, but it looks like there's some sort of variable
> >support, and a function called "Get(DocumentsPath)" that seems like
> >it'll give you a FMP friendly path to the My Documents folder that you
> >should be able to feed to the path you store the target file in.
>
> Now; the XML need not go on th desktop, and there is
> TMP=C:\DOCUME~1\[blah-user]\LOCALS~1\Temp
> that might work.
>
> But I'm not conversant in either M$ internals or FMP's to know what best/works at all.
>
> tmp would be ideal except for one gotcha; when you spawn a webviewer, and it pops
> up a CHOOSE-A-FILE box; what directory does IT start in? In OSX, at least, it does
> not allow easy [if at all..] Finder browsing to /tmp.

Typically, they open in the last place they were pointed at, and
usually default to the users desktop or documents folder.

> 1) How do you write FMP scripts that specify a known-writeable/findable destination
> independent of client type/configuration?

The temporary folders in windows are not generally great places to
have user interact with.

I'd recommend for the windows users to just write to a specific folder
off the root c: drive. It will be easy to navigate to in the file
browser. (Just create a dedicated folder for that purpose... e.g. c:
\filemaker export\; this would have to be done in advance of using the
script.)

You culd define the variable you use for the file path to be dependant
on the platform version.

set variable $myfilepath =
if ( get(platform)=Mac (i think its 0 for mac 1 for windows);
"filemac:\somewhereonthemac";
"filewin:\c:\filemaker export\")

Actually I *think* you don't even need a variable or "if", if you just
define a filewin:\ and a filemac:\ llocation in the export dialog box
filemaker automatically will use the appropriate one... but I havent'
tested this yet on exports. Also If you define multiple filewin:\
entries filemaker apparently is supposed to use the first valid one it
can find... but again I haven't tested this on exports (just imports).

> 2) And... Will a new write automatically overwrite the existing file of that name,
> or should we erase it first?

It will overwrite the existing file.

-dave

Re: Default file locations/behaviour

d-42 writes:


>> tmp would be ideal except for one gotcha; when you spawn a webviewer, and it pops
>> up a CHOOSE-A-FILE box; what directory does IT start in? In OSX, at least, it does
>> not allow easy [if at all..] Finder browsing to /tmp.

>Typically, they open in the last place they were pointed at, and
>usually default to the users desktop or documents folder.

I've found it to be unpredictable at best....


>> 1) How do you write FMP scripts that specify a known-writeable/findable destination
>> independent of client type/configuration?

>The temporary folders in windows are not generally great places to
>have user interact with.

>I'd recommend for the windows users to just write to a specific folder
>off the root c: drive. It will be easy to navigate to in the file
>browser. (Just create a dedicated folder for that purpose... e.g. c:
>\filemaker export\; this would have to be done in advance of using the
>script.)

BUT Rule 1 on this aspect is: All they have to install is FMP. We don't
want to start installing myrid {OSX/M$} scripts on people's machines,
because we don't know anything about them.

Some of them don't keep user directories on C: at all, for example.

>You culd define the variable you use for the file path to be dependant
>on the platform version.

>set variable $myfilepath =
> if ( get(platform)=Mac (i think its 0 for mac 1 for windows);
> "filemac:\somewhereonthemac";
> "filewin:\c:\filemaker export\")

>Actually I *think* you don't even need a variable or "if", if you just
>define a filewin:\ and a filemac:\ llocation in the export dialog box
>filemaker automatically will use the appropriate one... but I havent'
>tested this yet on exports. Also If you define multiple filewin:\
>entries filemaker apparently is supposed to use the first valid one it
>can find... but again I haven't tested this on exports (just imports).

The FMP programmer thought that as well. But we'll have to test.


>> 2) And... Will a new write automatically overwrite the existing file of that name,
>> or should we erase it first?

>It will overwrite the existing file.

That's good news.



--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: Default file locations/behaviour

> BUT Rule 1 on this aspect is: All they have to install is FMP. We don't
> want to start installing myrid {OSX/M$} scripts on people's machines,
> because we don't know anything about them.
>
> Some of them don't keep user directories on C: at all, for example.

1) I never suggested anything that required myriad osx/ms scripts?!

2) Fundamentally, if you are going to save files to a local folder on
the users desktop, and you want to automate it, and you want them to
interact with those files, you either have to TELL them where the
files are going to be stored, or let them tell you.

If you want to dictate where that folder be I'd suggest either off c:\
or off their documents folder. Even if they aren't using c:\ for 'user
settings' they still probably have a c: system drive. For the latter,
you can use the get function to obtain their documents folder path,
and then append the dedicated subfolder name.

If you don't want to dictate where and let them decide, then you'll
have to create a table of hostnames and filepaths, so each computer
can have its own unique filepath. Use the FM get function to look up
which hostname its on, and then look up the filepath to use. But that
still requires the user define a place for the exports to go, and
enter that in the database.

If you want to just stick them in the documents folder directly you
can do that too, and its simpler in that nothing special needs to be
done in advance to set it up, but having your exports dumped in
amongst their pictures, sales forecasts, recipes, and who knows what
else isn't terribly user friendly either. And the temp folder is even
worse.

cheers,
Dave

Re: Default file locations/behaviour

d-42 writes:


>If you want to just stick them in the documents folder directly you
>can do that too, and its simpler in that nothing special needs to be
>done in advance to set it up, but having your exports dumped in
>amongst their pictures, sales forecasts, recipes, and who knows what
>else isn't terribly user friendly either. And the temp folder is even
>worse.


But that's what I was told was not possible. I'm more than happy to put
them on the desktop, or in the documents directory.

But my understanding was there is NO 2K/XP equivalent of the current
$HOME or ~/ in Unix's...


If there is one, we can put it in the filename FMP will use, al la:


filewin: /SOMETHING/active.xml

That's all I need.

Re: Default file locations/behaviour

Sorry -- haven't been following the entire thread, but I don't see where
anyone mentions which version of FMP you are on.

I don't know what the "current $HOME" is on Mac. But on Windows:

get(documentspath), get(desktoppath) and get(temporarypath) (that last
one is FM9 only) are all user specific. get(filemakerpath) gives you
the folder where the currently running copy of the program folder is.

Or if you want it on the desktop not specific to any user, then you can
just save it to C:\Documents and Settings\All Users

Hope that helps...


David Lesher wrote:

> But that's what I was told was not possible. I'm more than happy to put
> them on the desktop, or in the documents directory.
>
> But my understanding was there is NO 2K/XP equivalent of the current
> $HOME or ~/ in Unix's...
>
>
> If there is one, we can put it in the filename FMP will use, al la:
>
>
> filewin: /SOMETHING/active.xml
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg
FM Professional Solutions, Inc. Los Angeles

FileMaker 8 Certified Developer
Associate Member, FileMaker Solutions Alliance

Re: Default file locations/behaviour

Howard Schlossberg writes:

>Sorry -- haven't been following the entire thread, but I don't see where
>anyone mentions which version of FMP you are on.

FMP 8.5.1 / FMS 8.0.?

>I don't know what the "current $HOME" is on Mac. But on Windows:

It's a Unix shell builtin that returns the home directory of the user.
For example:

panix5 22:29:39 ~ echo $HOME
/net/u/1/w/wb8foz
panix5 22:29:45 ~

The tilde does as well; if I say "cd ~/Mail" I get:

panix5 22:31:57 ~ pwd {print working directory}
/tmp
panix5 22:32:00 ~ cd ~/Mail
panix5 22:32:03 ~/Mail pwd
/net/u/1/w/wb8foz/Mail
panix5 22:32:05 ~/Mail

The user can be sure {s}he has write permission there.

>get(documentspath), get(desktoppath) and get(temporarypath) (that last
>one is FM9 only) are all user specific. get(filemakerpath) gives you
>the folder where the currently running copy of the program folder is.

How do I use such; call it in a FMP script and pass that to the filewin:
statement?


>Or if you want it on the desktop not specific to any user, then you can
>just save it to C:\Documents and Settings\All Users

.....If C:\ is where that is.... I'd rather test....

--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: Default file locations/behaviour

In case this was unclear... I've added | symbols
that would NEVER be there in real life..

My shell prompt is set to tell me the current directory;
tersely if it can...


>panix5 22:29:39 ~ | echo $HOME
> | /net/u/1/w/wb8foz
>panix5 22:29:45 ~ |

|
this side is | This side the command/response
just the prompt |

The tilde's a shortcut both for entering and showing
my home directory....

--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Re: Default file locations/behaviour

On Oct 18, 7:40 pm, David Lesher wrote:
> Howard Schlossberg writes:

> >Sorry -- haven't been following the entire thread, but I don't see where
> >anyone mentions which version of FMP you are on.
>
> FMP 8.5.1 / FMS 8.0.?

IIRC he said it was FMP8/FMS8 With FMS9 available but not installed.

> How do I use such; call it in a FMP script and pass that to the filewin:
> statement?

Set Variable $path = Get(DocumentsPath)
Set Variable $platformprefix = if( Get(SystemPlatform) = -2,
"filewin:","filemac:")
Set Variable $completepath = $platformprefix & $path

Export records ( $completepath )

Obviously, you can reduce the variables to one, but I broke it up for
simplicity. The above will work on both OSX and windows.

-cheers,
Dave

Re: Default file locations/behaviour

Another hairbrane approach...

The Creating File Paths helpfile lists:

"fmnet:/hostIPaddress/filename"

This does not let me WRITE a file there?

If it did....I could create the XML files on a client, save to the Server, and scp from
there.....

Re: Default file locations/behaviour

On Oct 18, 9:47 pm, David Lesher wrote:
> Another hairbrane approach...
>
> The Creating File Paths helpfile lists:
>
> "fmnet:/hostIPaddress/filename"
>
> This does not let me WRITE a file there?
>
> If it did....I could create the XML files on a client, save to the Server, and scp from
> there.....

fmnet: is the filemaker networking protocol.
Its **only** useful for accessing databases hosted by filemaker/
filemaker server. That is why there is no 'path', just the host
address and filename.

-regards,
Dave

Re: Default file locations/behaviour

d-42 writes:

>fmnet: is the filemaker networking protocol.
>Its **only** useful for accessing databases hosted by filemaker/
>filemaker server. That is why there is no 'path', just the host
>address and filename.

Thanks.... I assumed that but it was worth asking....
--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433