Searching \ for '[OT] Setting a data path in DOS / Inter PC LAN acc' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/mems.htm?key=data
Search entire site for: 'Setting a data path in DOS / Inter PC LAN acc'.

Exact match. Not showing close matches.
PICList Thread
'[OT] Setting a data path in DOS / Inter PC LAN acc'
2006\09\12@074324 by Russell McMahon

face
flavicon
face
For a friend.
I have no direct involvement with the following.
Nobody is going to take your advice if you suggest buying new windows
aware applications software :-).



1.    Dim memory assures me that MSDOS had (has) a data-path command
that would allow data to be referenced by filename without a path
specifier if it was anywhere on the data path. ie just as

       path C:\windows;c:\UTIL;C:\FOXPRO;C:\

allows programs anywhere in the directories on the path to be accessed
by name the data equivalent allowed data to be accessed similarly.

Such a capability is extremely dangerous, and also sometimes useful.
A friend wants top do something with an olllld DOS program that may
benefit from this feature.
Anyone know how it is/was accessed?
Gargle seems to know far too much about the terms 'data path' to be
easily driven to reveal anything useful.


2.    Same problem but different maybe.

WIN98 on N PCs on LAN.

DOS program on PC A runs OK.
Same program on PC B runs OK.
But run program on B and specify data location as on A via mapped
drive etc and it no go.
Need better way for non network-aware program on B to 'see' data files
on A.
Any thoughts.

As the DOS program is run on only one PC at any one time top avoid
data corruption and synchronisation issues I suggested doing a copy of
files to the PC of choice prior to operation and copying altered files
back after use plus a basic control system to prevent more than one PC
accessing the system at a time. Should be easy enough to do and I'd
guess it would be rapid enough but "doing it properly" would be nicer.




       Russell


2006\09\12@083540 by Carey Fisher

face picon face
Maybe this will help:

http://www.computerhope.com/pathhlp.htm

I used Gargoyle with "MSDOS Path" as the search term.  Lots of hits...

Carey

Russell McMahon wrote:
{Quote hidden}

--

*Carey Fisher, Chief Technical Officer
New Communications Solutions, LLC
*spam_OUTcareyfisherTakeThisOuTspamncsradio.com <.....careyfisherKILLspamspam@spam@ncsradio.com>
Toll Free Phone:888-883-5788
Local Phone:770-814-0683
FAX: 888-883-5788
http://www.ncsradio.com <http://www.ncsradio.com/>

2006\09\12@083833 by Tony Smith

picon face
You can change it by issuing "path ;" to clear it, then path "c:\; etc" to
set a new one.

It an environment setting, like %windir% & %temp% under Windows.  To access
the current path would depend in the language it's written it.  In a batch
file, "echo %path%" prints the current one.

To change it a crude way would be to shell out to DOS and run a batch file,
unless the language you're using has a better way to do it.  There's a
length limit (255 char?) too.

For #2, is it using SUBST?

Tony


{Quote hidden}

2006\09\12@084842 by William Couture

face picon face
On 9/12/06, Russell McMahon <apptechspamKILLspamparadise.net.nz> wrote:
> For a friend.
> I have no direct involvement with the following.
> Nobody is going to take your advice if you suggest buying new windows
> aware applications software :-).
>
> 1.    Dim memory assures me that MSDOS had (has) a data-path command
> that would allow data to be referenced by filename without a path
> specifier if it was anywhere on the data path. ie just as
>
>         path C:\windows;c:\UTIL;C:\FOXPRO;C:\

It's normal to use an equal sign in there:
  path=c:\windows;c:\util;c:\foxpro;c:\

> allows programs anywhere in the directories on the path to be accessed
> by name the data equivalent allowed data to be accessed similarly.

Yes and no.  Path is information available to the operating system
(DOS) and applications.  It's use is *NOT* mandatory.

DOS (i.e. COMMAND.COM) will search PATH for an executable if it
is not found in the current directory.

However, DOS (i.e. IBMDOS.SYS / MSDOS.SYS) does *NOT* search
the path when an application opens a file.  So, if your program tries to
open the file "MYDATA.DAT", the DOS call will try to do so from the
current directory, not the current directory plus the directories specified
in the PATH.

The application, however is free to search the directories specified in
PATH by itself (or any other directories specified in the environment.
This is why many programs add statements like
  SET MYAPPDIR=C:\MYAPP
in the AUTOEXEC.BAT file on installation).

> Such a capability is extremely dangerous, and also sometimes useful.
> A friend wants top do something with an olllld DOS program that may
> benefit from this feature.

Another fun (and useful!) command is SUBST, where a drive letter may
be used to substitute for a path.  i.e.
  SUBST Q: C:\MYAPP\DATADIR
will access the directory C:\MYAPP\DATADIR whenever Q: is used.

This is useful for *VERY* old programs that do not know about paths,
and even some new programs that have limits on the length of a
directory string (i.e. MPLAB 7.<mumble>)
  SUBST Q: C:\PROGRAM FILES\MICROCHIP\MPLAB 7.40\MYFILES\PROJECT

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2006\09\12@085226 by Tamas Rudnai

face picon face
> 1.    Dim memory assures me that MSDOS had (has) a data-path command
> that would allow data to be referenced by filename without a path
> specifier if it was anywhere on the data path. ie just as
>
>        path C:\windows;c:\UTIL;C:\FOXPRO;C:\

PATH variable is for accessing PROGRAMS not to data! So that when you start
an external command or an application you do not need to tell where is the
command or app resides. But if you would like to open a data file, you still
have to tell where it is, except if it is in the current directory (selected
by the CD or CHDIR internal command).

> allows programs anywhere in the directories on the path to be accessed
> by name the data equivalent allowed data to be accessed similarly.
You have to handle that by your program. For example LIBPATH is something
like that, but handled by the linker itself. Actually PATH is handled by the
command line interpreter (COMMAND.COM or CMD.EXE).

> Such a capability is extremely dangerous, and also sometimes useful.
> A friend wants top do something with an olllld DOS program that may
> benefit from this feature.
> Anyone know how it is/was accessed?
> Gargle seems to know far too much about the terms 'data path' to be
> easily driven to reveal anything useful.

Create an environment variable, something like

SET MYDATAPATH=C:\MyDataHere\

then use that one. You can set that variable in Windows by user basis, so
every user can have different MYDATAPATH variable. (right click on
MyComputer, Properties, Advanced tab, Environment Variables button, New
button in the User variables square...) Now you can have your batch script
like:

COPY %MYDATAPATH%\datafile1.dat  C:\TEMP\hereIwork.dat

{Quote hidden}

OK, so  what's wrong with opening a file in a mapped drive? It has to be
done in the same way as a local file from the app point of view. The only
thing is that some app opens the file exclusively, so that no any other app
can access to the same file until finished except for reading (some cases
even reading is impossible). That's how the app protect the file from
messing up by unhandled race conditions. So if on app would modify the first
line of text file while other app do the same... which line is the 'good
one'? That's why some app opens the file as nobody else can do the same (to
be able to write into it).

One of the possible solution is that you have to check if you could open the
file, if not wait a while and try again. Then your app has to make the
modification as quick as possible and close the file when finished. But
before you write your data back blindly you have to make sure that it
conforms to the changed file structure (for example if first line is longer
than was then the second line starts in a different file offset).

Other possible thing is that you make sure nobody is working on the file
till you entirely finished (so other clients waits a long time till could
have a chance to open the file for write). This is I call network capable
non-networked app :-)

Oh, almost forgot one thing: you can have a network access in such that you
have only read access to the networked resource. You have to check if the
access is full or restricted.

> As the DOS program is run on only one PC at any one time top avoid
> data corruption and synchronisation issues I suggested doing a copy of
> files to the PC of choice prior to operation and copying altered files
> back after use plus a basic control system to prevent more than one PC
> accessing the system at a time. Should be easy enough to do and I'd
> guess it would be rapid enough but "doing it properly" would be nicer.

You can move the file instead of copy, so that if the file is not in the
original location nobody could open it, right? :-) And move instruction is
one single instruction -- I did not test it therefore I could not tell if no
any problem could occur this way. Alternatively you can rename the file
keeping in the same location, so that the extension tells which client is
working on it (FILE.A or FILE.B for example). It could be much quicker, and
then you can check that the rename was successful -- if not the other one
was quicker or something was completely wrong.

But if it is not a script but a proper program you should consider do a
better record locking mechanism -- even dBASE IV had record locking, and
according to the PATH you mentioned you have FoxPro which is a good clone of
dBASE. Look up the book / google on record locking and shared accessing and
do it in a proper way :-)


Tamas

2006\09\12@090310 by Alan B. Pearce

face picon face
> 1.    Dim memory assures me that MSDOS had (has) a data-path command

I always thought this was program dependant. I have seen the data path
variable, but AFAIK it is not an inherent one in DOS or any later OS, so a
program would have to look for that variable, and parse it to find the
possible paths to search.

2006\09\12@090643 by Alan B. Pearce

face picon face
>OK, so  what's wrong with opening a file in a mapped drive?

Some programs get real funny if they cannot "get at" the drive data in the
same manner as they can on a local machine. I have seen this happen with
programs that attempt to look at the drive properties, presumably to look
for how much empty space there is, and if the drive type is not what they
expect, then they baulk. A network drive is reported as a different drive
type to a floppy, local hard drive, or CD.

2006\09\12@093022 by Tamas Rudnai

face picon face
I see, then replace that program to a proper one :-). That was the worse
thing in MSDOS: every app programmer felt that he/she is an OS developer as
well so broke the app layer in every way they could. (erm, even myself wrote
a FAT driver those days to access files faster and to be able to see hidden
viruses on the system :-)

But seriously, if the app does not support accessing to files on a network
drive I suggest not to use that in this occasion.

Tamas


On 12/09/06, Alan B. Pearce <.....A.B.PearceKILLspamspam.....rl.ac.uk> wrote:
>
> >OK, so  what's wrong with opening a file in a mapped drive?
>
> Some programs get real funny if they cannot "get at" the drive data in the
> same manner as they can on a local machine. I have seen this happen with
> programs that attempt to look at the drive properties, presumably to look
> for how much empty space there is, and if the drive type is not what they
> expect, then they baulk. A network drive is reported as a different drive
> type to a floppy, local hard drive, or CD.
>
> -

2006\09\12@094611 by Russell McMahon

face
flavicon
face
Rather to my surprise, so far ALL the answers have missed the poont of
my original question which I THOUGHT I'd made clear, but obviously I
didn't :-)

I am well aware of the *PROGRAM* path feature which I gave an example
of.
Everyone referred to that, which I am aware of, and which is not
useful for solving the problem, alas.

AFAICR there is also a much more rarely used ***DATA*** path feature
available somewhere in the dark arcanery of the MSDOS world.

As for "what's wrong with using ..." - I have mo idea - but it doesn't
work :-)
ie the more normal DOS tricks fail.

What I am looking for is what I (thought I) said I was looking for - a
command that allow sprograms referencing data in what they actually
think is their "current directory" to be actually accessing it in 1 or
more directories OTHER THAN the current director .

eg Say the command I want was DATAPATH ....

_______________

DATAPATH C:\FRED

C:
CD  \JIM

DIR ALLAN

______________

would list all files named ALLAN BOTH in C:\JIM and ALSO in C:\FRED

   ie     C:\JIM\ALLAN
&
           C:\FRED\ALLAN

A truly dangerous facility :-)
But, sometime suseful.


       Russell



2006\09\12@094731 by Alan B. Pearce

face picon face
>I see, then replace that program to a proper one :-). That was the
>worse thing in MSDOS: every app programmer felt that he/she is an
>OS developer as well so broke the app layer in every way they could.

It wasn't that they broke the application layer, they just checked a field
in the returned information that they did not need to check. This was done
using an MSDOS standard call to get drive information.

2006\09\12@095730 by Russell McMahon
face
flavicon
face
>I see, then replace that program to a proper one :-). That was the
>worse
> thing in MSDOS: every app programmer felt that he/she is an OS
> developer as
> well so broke the app layer in every way they could. (erm, even
> myself wrote
> a FAT driver those days to access files faster and to be able to see
> hidden
> viruses on the system :-)
>
> But seriously, if the app does not support accessing to files on a
> network
> drive I suggest not to use that in this occasion.

As I said at the very top of the original query

       Nobody is going to take your advice if you suggest
       buying new windows  aware applications software :-).

This is an accounting application that has worked well in this
environment but someone broke it. The background is obscure and
several people removed from my involvement (I'm pleased to say :-) ).
The chances of getting people to change in this situation is only
slightly above "Till hell freezes over Do: ...". And the necessity is
only slightly greater than that. All they want is for somone to put it
back how it was. Alas, I did hear Banyan Vine smentioned (seriously)
but I think that's gone and ... !!!

{Quote hidden}

Precisely.
It doesn't look like a standard non networked environment.
Someone managed to make it so.
The maker and their handiwork have now left the building and ...

Deep brain murmurings of Net Bios and Net Bui trouble my repose. May
be worth having a look at just what is enable in that system.


       Russell

2006\09\12@101348 by Russell McMahon

face
flavicon
face
>> 1.    Dim memory assures me that MSDOS had (has) a data-path
>> command
>> that would allow data to be referenced by filename without a path
>> specifier if it was anywhere on the data path. ie just as

> However, DOS (i.e. IBMDOS.SYS / MSDOS.SYS) does *NOT* search
> the path when an application opens a file.

That was my point - SOMETHING allows you to do just what you said it
doesn't do. That's what I'm looking for. I know what DOS *USUALLY*
doesn't do. I'm looking for the feature that  changes the 'normal'
rules.

> So, if your program tries to
> open the file "MYDATA.DAT", the DOS call will try to do so from the
> current directory, not the current directory plus the directories
> specified
> in the PATH.

Which is eactly the opposite for data purposes to the feature I'm
looking for.

>> Such a capability is extremely dangerous, and also sometimes
>> useful.

I can't imagine what people can think I mean by the above line, given
the answers I'm getting :-).

> Another fun (and useful!) command is SUBST, where a drive letter may
> be used to substitute for a path.  i.e.
>   SUBST Q: C:\MYAPP\DATADIR
> will access the directory C:\MYAPP\DATADIR whenever Q: is used.

***BUT*** SUBST will not work over a network path, which is what I
explictly want the feature to do.



       RM

2006\09\12@103842 by Tamas Rudnai

face picon face
Russel, you were right. APPEND is the command for that... I completly forgot
that one!

http://www.easydos.com/append.html

Tamas


On 12/09/06, Russell McMahon <EraseMEapptechspam_OUTspamTakeThisOuTparadise.net.nz> wrote:
{Quote hidden}

> -

2006\09\12@115049 by William Chops Westfield

face picon face

On Sep 12, 2006, at 7:13 AM, Russell McMahon wrote:

>> However, DOS (i.e. IBMDOS.SYS / MSDOS.SYS) does *NOT* search
>> the path when an application opens a file.
>
> That was my point - SOMETHING allows you to do just what you said it
> doesn't do. That's what I'm looking for. I know what DOS *USUALLY*
> doesn't do. I'm looking for the feature that  changes the 'normal'
> rules.
>
I don't remember anything like that within DOS itself, but it is
certainly within the capabilities of TSR-style programs.  Perhaps
you're remembering a feature from one of those ?  Could have been
part of one of the early networking products, perhaps?  It would be a
small matter of programming to write a TSR that intercepted simple
file-open calls and searched a path beyond the default current dir.

BillW

2006\09\12@121251 by Russell McMahon

face
flavicon
face
> Russel, you were right. APPEND is the command for that... I
> completly forgot
> that one!
>
> http://www.easydos.com/append.html

That seems to fit the memory very well.
I skimmed right over APPEND tonight :-( as the documentation just says
it is an old and dangerous version of the SUBST command - and it
certainly isn't just that.

They say:

       "If a file with a .COM, .EXE, or .BAT filename extension is to
be treated as a data file (for example, if you want to edit the
contents of a batch file), its path CAN be specified using the APPEND
command. However, if you want to execute the file from any directory,
you must specify its location using the PATH command.

and (beautifully dangerously)

           "Use the APPEND command to tell DOS where to search for
data files if a specified file is not found in the current directory.
This means that you will need only one copy of a file on your fixed
disk, even if you use it for different purposes. For example, you can
store a copy of the file NAMES1.TXT in the directory LISTS and use it
(copy from it, insert it into other files) while working in any drive
or directory."

And, most usefully:

       "The APPEND command CAN be used on a network."

Thanks for that.
Also, good to know that memory still serves well enough for general
outline, even if the detail got a bit lost, some of the time anyway
:-)



       Russell


2006\09\12@122949 by William Couture

face picon face
On 9/12/06, Tamas Rudnai <tamas.rudnaispamspam_OUTgmail.com> wrote:
> Russel, you were right. APPEND is the command for that... I completly forgot
> that one!
>
> http://www.easydos.com/append.html

Huh.... For all the DOS work I've done, that's a new one on me.

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2006\09\12@141757 by Peter van Hoof

face picon face


--- Russell McMahon <@spam@apptechKILLspamspamparadise.net.nz> wrote:
[snip]
> a data-path command
> that would allow data to be referenced by filename without a path
> specifier if it was anywhere on the data path. ie just as
>
>         path C:\windows;c:\UTIL;C:\FOXPRO;C:\
>
> allows programs anywhere in the directories on the path to be
> accessed
> by name the data equivalent allowed data to be accessed similarly.
[snip]

Like this:
http://www.vfrazee.com/ms-dos/6.22/help/append.htm

Peter van Hoof

2006\09\12@225134 by Russell McMahon

face
flavicon
face
> Like this:
> http://www.vfrazee.com/ms-dos/6.22/help/append.htm

Indeed.
Except !!!
They do say:

        Do not use this command when Windows is running.

and

       Caution
       Do not use Append with Microsoft Windows
       or the Windows Setup program.

I like this one :-)

        APPEND--Notes

            Running APPEND with Microsoft Windows

               Do not use Append with Microsoft Windows or
               the Windows Setup program.


I THINK they're trying to tell us it's not  a good idea to use it with
Windows ;-)


       Russell


2006\09\13@012425 by Tony Smith

picon face
{Quote hidden}

Don't you like warning that don't tell you why something is a bad idea?
They know we'll try it anyway.

The LOCK command (and UNLOCK) *may* solve things.  LOCK is a DOS 7 (ie
Win95/98 etc) and is used to give DOS programs exclusive access to the hard
drive.  Or something like that.

Tony

2006\09\13@023658 by Tamas Rudnai

face picon face
> Do not use this command when Windows is running.

I think it is for the time whem there was a DOS and on that operating system
the Windows was just a graphical interface... (Win 3.1). In XP for example
APPEND is exists, therefore I expect it to work (I do not know if work only
with DOS apps or in other way as well, and I do not know if you can set up
APPEND environment variable in the same way as PATH, however, when you call
it with /? it will say:

Allows programs to open data files in specified directories as if they were
in
the current directory.

APPEND [[drive:]path[;...]] [/X[:ON | :OFF]] [/PATH:ON | /PATH:OFF] [/E]
APPEND ;

 [drive:]path Specifies a drive and directory to append.
 /X:ON        Applies appended directories to file searches and
              application execution.
 /X:OFF       Applies appended directories only to requests to open files.
              /X:OFF is the default setting.
 /PATH:ON     Applies appended directories to file requests that already
              specify a path.  /PATH:ON is the default setting.
 /PATH:OFF    Turns off the effect of /PATH:ON.
 /E           Stores a copy of the appended directory list in an
environment
              variable named APPEND.  /E may be used only the first time
              you use APPEND after starting your system.

Type APPEND ; to clear the appended directory list.
Type APPEND without parameters to display the appended directory list.

So that /E is interesting to me, you still have to use APPEND command but it
CAN store the directory list in environment -- maybe you can even set up
manually?

Tamas


On 13/09/06, Russell McMahon <KILLspamapptechKILLspamspamparadise.net.nz> wrote:
{Quote hidden}

> -

2006\09\13@043336 by Howard Winter

face
flavicon
picon face
Russell,

On Wed, 13 Sep 2006 14:42:13 +1200, Russell McMahon wrote:

>...
>                 Do not use Append with Microsoft Windows or
>                 the Windows Setup program.
>
>
> I THINK they're trying to tell us it's not  a good idea to use it with
> Windows ;-)

I agree - except I would have omitted the words "Append with" !  :-)

Cheers,


Howard Winter
St.Albans, England


2006\09\13@043726 by Howard Winter

face
flavicon
picon face
Tamas,

On Wed, 13 Sep 2006 07:36:55 +0100, Tamas Rudnai wrote:

> > Do not use this command when Windows is running.
>
> I think it is for the time whem there was a DOS and on that operating system
> the Windows was just a graphical interface... (Win 3.1).

Yes, also Win95, 98, 98SE and ME.  It's only NT, 2000 and XP that aren't DOS based.

Cheers,

Howard Winter
St.Albans, England.

"Windows VISTA, from the people who brought you EDLIN!"  :-)

2006\09\13@080407 by William Couture

face picon face
On 9/13/06, Howard Winter <RemoveMEHDRWTakeThisOuTspamh2org.demon.co.uk> wrote:

> "Windows VISTA, from the people who brought you EDLIN!"  :-)

I'm far from being a MicroSnot fanboy, but EDLIN was originally
part of 86DOS from Seattle Computer Products.

It was included with IBM-DOS (aka MS-DOS) when Microsoft
bought up 86DOS and changed the name.

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2006\09\13@082657 by Russell McMahon

face
flavicon
face
>> > Do not use this command when Windows is running.

>> I think it is for the time whem there was a DOS and on that
>> operating system
>> the Windows was just a graphical interface... (Win 3.1).

> Yes, also Win95, 98, 98SE and ME.  It's only NT, 2000 and XP that
> aren't DOS based.

It's Win98 that they want to use this with :-)


       Russell

2006\09\13@090222 by Howard Winter

face
flavicon
picon face
Bill,

On Wed, 13 Sep 2006 08:04:05 -0400, William Couture wrote:

> On 9/13/06, Howard Winter <spamBeGoneHDRWspamBeGonespamh2org.demon.co.uk> wrote:
>
> > "Windows VISTA, from the people who brought you EDLIN!"  :-)
>
> I'm far from being a MicroSnot fanboy, but EDLIN was originally
> part of 86DOS from Seattle Computer Products.
>
> It was included with IBM-DOS (aka MS-DOS) when Microsoft
> bought up 86DOS and changed the name.

Hey, I said "brought you" - I didn't say they wrote it!  :-)

And actually it's not the worst editor I've ever worked with - that was on an ICL machine whose keyboard had "Enter" where "Backspace" should be,
so I was forever hitting it by mistake when I made a typing error.  The editor interpreted "Enter" as "save this screen up to the cursor and drop the
rest" !  I've never tried shaving with a cutthroat razor while riding a unicycle down a cobbled street, but I think it would have been safer and less
stressful than using that darned editor/keyboard combination!  :-)

Cheers,


Howard Winter
St.Albans, England


More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...