1. system "feature"
--- Part 1 ---
Maybe somebody can comment on this situation. I'm running a Euphoria =
program on a network. When using open/close/puts/etc., the program sees =
the network drives with no problem. However, when using the system =
command, the network drives are invisible. What's up with this? Of =
course, if Euphoria 2.2 had built-in file processing commands, this may be =
much simpler. =20
--- Part 2 ---
After further testing, it seems only one drive is affected. There's a =
hard disk partition that maps to G: on boot, but when the network drives =
are mapped, one of the network drives automatically maps to G: in the =
standard script. This is the first occurrence I've seen of anything being =
able to see this partition when connected to the network. Of course, I'm =
more interested in the network drive with this program, but I'd like to =
know if anyone has seen anything like this before.
Note: I temporarily worked around the problem by remapping the network =
drive to a different letter in the batch file, but that doesn't really =
solve the original problem.
Michael J. Sabal
2. Re: system "feature"
Mike:
You didn't say what network you are using so I am assuming NETWARE.
Just a thought, could your problem with the system() have anything to
do with which drives are search drives in your script file ? Also What
about security settings.
Bernie
3. Re: system "feature"
Sorry, I forgot to specify that I am using Netware. As an admin user, =
there are no security issues, and G: is not in the search path. If my =
filename is "blahblah.dat", I can say=20
fp =3D open(current_dir()&"blahblah.dat","r")=20
with no problem, but
system("dir "¤t_dir()&"blahblah.dat")
returns "Path not found". Note that it's *path* not found rather than =
file not found. The problem is directly related to the supposedly hidden =
partition, since that's the only drive that has this problem.
>>> xotron at BUFFNET.NET 04/25/00 01:05PM >>>
Mike:
You didn't say what network you are using so I am assuming NETWARE.
Just a thought, could your problem with the system() have anything to
do with which drives are search drives in your script file ? Also What
about security settings.
Bernie
4. Re: system "feature"
Mike: I have two suggestions.
Try issuing a MAP comannd with the system command this might
show you what system sees.
Also try using the NDIR command in the system command.
Bernie
5. Re: system "feature"
Thanks for all your suggestions. Here are the results:
system("map") -- G: drive does not appear at all, either locally or =
networked
system("ndir") -- returns an error that the specified directory could not =
be found.
I guess what it comes down to is how does system call directory information=
as opposed to current_dir or any other such thing. Is this something =
that Rob is doing differently or is it something inherent to Watcom? This =
seems to be a very low-level problem, perhaps on the assembly interrupt =
level. Rob?
6. Re: system "feature"
On Tue, 25 Apr 2000 15:46:12 -0400, Mike Sabal <MikeS at NOTATIONS.COM> wrote:
>I guess what it comes down to is how does system call directory
information as opposed to current_dir or any other such thing. Is this
something that Rob is doing differently or is it something inherent to
Watcom? This seems to be a very low-level problem, perhaps on the assembly
interrupt level. Rob?
Mike:
I don't think it a problem with system().
I think the problem is with your script files.
The fact that you can map the drive by using a batch file tells me
that system() is ok.
The most likely problem is one of the following problems:
1: Your workstation is running more than one script file at boot time
2: A script file is over-riding another and you are not loading the
script file that you think you are.
Try running the script file that you know is correct manually and
then try running system()
Bernie
7. Re: system "feature"
Mike Sabal writes:
> I guess what it comes down to is how does system call
> directory information as opposed to current_dir or any
> other such thing. Is this something that Rob is doing differently
> or is it something inherent to Watcom? This seems to be a
> very low-level problem, perhaps on the assembly interrupt level.
> Rob?
system() calls the WATCOM C system().
Did you try running it with exw?
Since ex runs on DOS, system()
might be limited somehow.
Also, system() opens a new shell, and might
not have the same environment variables visible.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. Re: system "feature"
Mike Sabal wrote (subject to massive snippage):
> ...However, when using the system() command, the network drives are invisible.
> ...I'd like to know if anyone has seen anything like this before.
>
> Note: I temporarily worked around the problem by remapping the network drive
> to a different letter in the batch file, but that doesn't really solve the
> original problem.
>
> Michael J. Sabal
One of the things I have run into is that under a Win32 environment the new
shell does *not* appear to inherit *any* of the environment settings at all. This
was especially evident on NT4.
After much experimentation, I was able to come up with a very messy solution
which involved using getenv() and writing a batch file to execute from within the
shell called from system() to set the variables, but even that is subject to
vagaries since so many settings are stored in the registry these days...
9. Re: system "feature"
>>> donovan at ABS.NET 04/25/00 07:37PM >>>
One of the things I have run into is that under a Win32 environment the =
new shell does *not* appear to inherit *any* of the environment settings =
at all.
....a very messy solution which involved using getenv() and ...
----------------------
Which brings me back to my originial idea. It seems it would be better =
for Euphoria to implement natively a set of file control commands similar =
to what is used for directory management. As far as file naming, it could =
either be OS specific (/home/mike/blahblah in Linux or C:\mike\blahblah.doc=
in Dos/Win), or an URL-like format could be used and then translated =
internally based on which version of Euphoria was being used.
For minimalization, it could be limited to copy, rename, and delete; with =
move being a procedure that calls copy and delete. This doesn't seem like =
too much to ask and would greatly enhance Euphoia's ability to do things =
by itself without such messy OS calls.
Also, checking the archives, these are features that have been asked for =
before; and while libraries exist, internalizing these primitives would =
make life a lot simpler for everybody.
Michael J. Sabal
10. Re: system "feature"
----- Original Message -----
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Wednesday, April 26, 2000 7:55 AM
Subject: Re: system "feature"
>>> donovan at ABS.NET 04/25/00 07:37PM >>>
One of the things I have run into is that under a Win32 environment the new
shell does *not* appear to inherit *any* of the environment settings at all.
....a very messy solution which involved using getenv() and ...
I think i remember fixing this by running the autoexec in the new dos shell,
then running my pascal program in it. If you can have Eu run the autoexec to
set vars in the new shell, but not start a new shell when you do that,
you'll solve the problem. Seems to me there are DOS command line switches
"start the shell running this app and do not go away", then have the
"special autoexec" call your Eu app. But i don't remember if i was able to
ever make the new shell go away.
Kat,
working from old memories.
11. Re: system "feature"
Mike:
Did you read my last reply to this message about your problem
Bernie
12. Re: system "feature"
Yes, sorry Bernie. The problem is quite specific to my machine having 2 =
partitions and 2 CD-ROMs, and network drives mapping themselves onto 4 =
consecutive drives which overlap one of the partitions. For now, the =
simplest solution is, in the batch file, remapping the network drive I =
want to use onto something like drive R: which has no local interference =
and on which the program works fine. As this situation is internal to the =
Watcom C compiler, there's no other clean solution. I do appreciate your =
help and suggestions. If only Rob could internalize the copy/rename/delete=
file commands....
Michael J. Sabal
>>> xotron at BUFFNET.NET 04/26/00 11:05AM >>>
Mike:
Did you read my last reply to this message about your problem
Bernie
13. Re: system "feature"
I also have wanted copy/rename/delete type commands. It just seems kind of an
ugly way to do somthing by calling the system() function. Just my opinion
--
Bret Belgarde
POS Support/Network Administrator
Seattle Crab Co./Skippers Inc.
Phone: (425)563-9244
Email: bretbelgarde at worldnet.att.net
14. Re: system "feature"
Bret Belgarde wrote:
>I also have wanted copy/rename/delete type commands. It just seems
>kind of an ugly way to do somthing by calling the system() function.
>Just my opinion
I have to agree; especially now that something like chdir() is a built-in
function, it seems silly for the other file-handling routines to be
dependent on system() calls. Just my two pennies' worth...
-- Gabriel
______________________________________________________
PLEASE IGNORE ANY ADS YOU MAY SEE BELOW THIS LINE. 
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
