Home > Archive > Tcl > December 2006 > How to source a file which is in a remote machine?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to source a file which is in a remote machine?
|
|
|
| Hi all,
Is it possible to [source] a file which is in a remote machine?
Regards,
Prabu
| |
| peace07 2006-12-18, 4:16 am |
|
prabu schrieb:
> Hi all,
>
> Is it possible to [source] a file which is in a remote machine?
>
> Regards,
> Prabu
Hi Prabu,
a solution is to mount the remote filesystem (e.g. NFS) and source the
file via the
source
command. Another solution would be to build or use a simple
server-application which will deliver the script over the network (such
as a webserver or another Server written in Tcl for eaxmple). If you
need such a simple Tcl-server, just send me an email.
regards,
Friedemann
| |
| Leopold Gerlinger 2006-12-18, 4:16 am |
| prabu wrote:
> Hi all,
>
> Is it possible to [source] a file which is in a remote machine?
>
> Regards,
> Prabu
>
If you can access it via a mounted / mapped drive than it's no
difference to any other source'd file. This would assume that the path
to the file to be sourced is the same on every machine (or you have some
way of configuring it).
Otherwise you would have to download the file somehow to a local dir and
source it from there.
Regards - Leo
| |
|
| prabu <catchme.prabu@gmail.com> wrote:
> Is it possible to [source] a file which is in a remote machine?
Yep, if you must. A couple of options for you:
1. Set up a remote file system so it appears like a local filesystem.
Something like NFS, Samba/Windows shares, Netware, Appleshare, etc.
2. Package require VFS::FTP first. This does a similar job to a remote
filesystem except the filesystem's visible only for your app.
I'd recommend against either of these for anything but a development
environment on a secure LAN though. Out in the wild wooly world of the
Internet, it would leave a massive hole through which anyone with
control of that remote machine would have nearly unrestricted access to
the end-user's desktop machine. Bad stuff.
|
|
|
|
|