autoexec anomaly

[legg]

When this win982Ed machine boots, without splash screens, I'm used to
seeing recognisable text from Autoexec.bat on the screen as the system
loads.

Recently, after reinstalling some cad SW, the text displayed on boot
has started to vary from that edited in Autoexec. This includes
reorganised but recognizable PATH text strings, with added, seemingly
unneccessary paths in the text strings. The cad SW was an Autodesk
package, and was a reinstall; not something new.

The variation from the normal text editable Autoexec.bat file
suggests to me that the autoexec paths are being set, recorded and
edited elsewhere. MSCONFIG only confirms contents of the known batch
file. This re-arrangement in the display is new to me.

I'm curious.

Firstly; why would a path to C:\WINDOWS or C:\WINDOWS\COMMAND be
required, if both COMMAND and WINDOWS are available in the root
directory? These are some of the extra text lines added to the
displayed boot process that vary from the legitimate autoexec batch
files text contents. I don't recall seeing them on boot before.

The Command executable is present in both the root and the windows
directory, along with a command.pif in root that points to the windows
location. Both executables appear identical as to origin, date and
size. I seldom use it, except to ping network connections.

Secondly - why would the character @ have been inserted before the
first line of the 'legitimate' batch file (norton AV path)?

I am not troubleshooting a performance problem at present - merely
querying my earlier assurance that the boot text displayed would or
should be recognizable as contents of the autoexec.bat file.

RL

 

[me]

When this win982Ed machine boots, without splash screens,
I'm used to seeing recognisable text from Autoexec.bat on
the screen as the system loads.

Recently, after reinstalling some cad SW, the text
displayed on boot has started to vary from that edited in
Autoexec. This includes reorganised but recognizable PATH
text strings, with added, seemingly unneccessary paths in
the text strings. The cad SW was an Autodesk package, and
was a reinstall; not something new.

The variation from the normal text editable Autoexec.bat
file suggests to me that the autoexec paths are being set,
recorded and edited elsewhere. MSCONFIG only confirms
contents of the known batch file. This re-arrangement in
the display is new to me.

I'm curious.

Firstly; why would a path to C:\WINDOWS or
C:\WINDOWS\COMMAND be required, if both COMMAND and WINDOWS
are available in the root directory? These are some of the
extra text lines added to the displayed boot process that
vary from the legitimate autoexec batch files text
contents. I don't recall seeing them on boot before.

The Command executable is present in both the root and the
windows directory, along with a command.pif in root that
points to the windows location. Both executables appear
identical as to origin, date and size. I seldom use it,
except to ping network connections.

Secondly - why would the character @ have been inserted
before the first line of the 'legitimate' batch file
(norton AV path)?

I am not troubleshooting a performance problem at present -
merely querying my earlier assurance that the boot text
displayed would or should be recognizable as contents of
the autoexec.bat file.

RL

It'd be easier to comment while seeing the actual contents.
In general: installers slap into autoexec whatever they think
they need. The OS does not care about duplicates.

The "@" at the beginning of a line means don't display that line
while processing it. Many (most?) autoexecs start with this:
@echo off
which will suppress display of the commands as they are
processed.

Odds are that what you see/have is just a benign mess.

J

 

[Shane]

It'd be easier to comment while seeing the actual contents.
In general: installers slap into autoexec whatever they think
they need. The OS does not care about duplicates.

The "@" at the beginning of a line means don't display that line
while processing it. Many (most?) autoexecs start with this:
@echo off
which will suppress display of the commands as they are
processed.

Odds are that what you see/have is just a benign mess.

Certainly Autodesk does add itself to the path.

Shane

 

[Guy]

The variation from the normal text editable Autoexec.bat file
suggests to me that the autoexec paths are being set, recorded and
edited elsewhere.

Paths can be set in the CONFIG.SYS file.
The advantage being the length of the command.
Which is not limited to 127 characters as is in the AUTOEXEC.BAT file.

 

[Zvi Netiv]

When this win982Ed machine boots, without splash screens, I'm used to
seeing recognisable text from Autoexec.bat on the screen as the system
loads.

Recently, after reinstalling some cad SW, the text displayed on boot
has started to vary from that edited in Autoexec. This includes
reorganised but recognizable PATH text strings, with added, seemingly
unneccessary paths in the text strings. The cad SW was an Autodesk
package, and was a reinstall; not something new.

The variation from the normal text editable Autoexec.bat file
suggests to me that the autoexec paths are being set, recorded and
edited elsewhere. MSCONFIG only confirms contents of the known batch
file. This re-arrangement in the display is new to me.

Use SYSEDIT under Windows for editing, or EDIT under DOS.

I'm curious.

Firstly; why would a path to C:\WINDOWS or C:\WINDOWS\COMMAND be
required, if both COMMAND and WINDOWS are available in the root
directory?

You are confusing between directories and commands. C:\Windows and
C:\Windows\command are the default directories where all Win applications and
its external commands (like format, fdisk, attrib, etc.) reside. The name
Windows you see in the root is just the pointer to the directory by that name.
Command.com is the command interpreter (the DOS shell) and has nothing to do
with the ..\windows\command directory.

If the above sounds Hebrew to you, then do this: Open a DOS shell (type COMMAND
from your desktop 'run' and press Enter). From the command prompt, type SET and
Enter. Look at the display, what you see are the environment variables. Try to
figure out what each is.

These are some of the extra text lines added to the
displayed boot process that vary from the legitimate autoexec batch
files text contents. I don't recall seeing them on boot before.

There is no "legitimate" autoexec. The extra lines were most probably edited by
the reinstallation of the CAD software.

The Command executable is present in both the root and the windows
directory, along with a command.pif in root that points to the windows
location. Both executables appear identical as to origin, date and
size. I seldom use it, except to ping network connections.

The command interpreter is crucial and without it your system won't start, not
even to DOS. One can use a computer without knowing what the role of every file
is, but displaying such ignorance is rather exceptional.

Secondly - why would the character @ have been inserted before the
first line of the 'legitimate' batch file (norton AV path)?

The @ operator at the beginning of a line in a batch means "execute this line
without showing its content on the display".

 

[legg]

When this win982Ed machine boots, without splash screens, I'm used to
seeing recognisable text from Autoexec.bat on the screen as the system
loads.

Recently, after reinstalling some cad SW, the text displayed on boot
has started to vary from that edited in Autoexec. This includes
reorganised but recognizable PATH text strings, with added, seemingly
unneccessary paths in the text strings. The cad SW was an Autodesk
package, and was a reinstall; not something new.

The variation from the normal text editable Autoexec.bat file
suggests to me that the autoexec paths are being set, recorded and
edited elsewhere. MSCONFIG only confirms contents of the known batch
file. This re-arrangement in the display is new to me.

I'm curious.

Firstly; why would a path to C:\WINDOWS or C:\WINDOWS\COMMAND be
required, if both COMMAND and WINDOWS are available in the root
directory? These are some of the extra text lines added to the
displayed boot process that vary from the legitimate autoexec batch
files text contents. I don't recall seeing them on boot before.

.........
Secondly - why would the character @ have been inserted before the
first line of the 'legitimate' batch file (norton AV path)?

This is a fairly mature installation, running since around
Feb of Y2K, without a reinstallation. I've kept on record
iterations of the AUTOEXEC.BAT files, over that time.
I am fairly familiar with some of the installation pecadillos
of both old DOS-era and Post-W98 hardware and SW.
Obvious mistaken duplicates or uninstalled application
references are likely to be removed manually, but only if
they get in the way, rather like barnacles on a hull.

Last known good, with recognisable screen displays,
on boot, follow:

C:\DIAGNOSE\NORTON~1\NORTON~1\NAVDX.EXE /startup
rem - C:\DOS\MSCDEX.EXE /D:MSCD000
rem - By Windows Setup - C:\WINDOWS\COMMAND\MSCDEX /V /D:CD003 /M:10
@SET CLASSPATH=C:\IMAGING\PHOTOD~1.0\ADOBEC~1
PATH
C:\ENGTOOLS\DBASE\OFFICE;C:\ENGTOOLS\DBASE\OFFICE;C:\HARDWARE\UX1400;C:\ENGTOOLS\CAD\QUICKC~1
set XILINX=C:\engtools\PIC\xilinx5101i
SET
PATH=C:\HARDWARE\GPIB\CBGPIB\GPIB351;C:\HARDWARE\UX1400;C:\ENGTOOLS\DBASE\OFFICE;C:\ENGTOOLS\PIC\XILINX5101I\BIN\NT;C:\WINDOWS\;C:\hardware\TEK\VXIPNP\WIN95\BIN
SET WISE02_LICENSE_FILE=C:\Programs\WISE Software
Solutions\License\Wise02.lic
set LM_LICENSE_FILE=C:\engtools\PIC\Modeltech_xe\license.dat
SET GPIBDIR=C:\HARDWARE\GPIB\CBGPIB\GPIB351
SET PATH=%PATH%;C:\PROGRAMS\COMMON~1\AUTODE~1

There is no <cr> after PATH, SET or Software, as may be created by the
word wrapping in this newsreader text editor.

Currently:

@C:\DIAGNOSE\NORTON~1\NORTON~1\NAVDX.EXE /Startup
rem - C:\DOS\MSCDEX.EXE /D:MSCD000
rem - By Windows Setup - C:\WINDOWS\COMMAND\MSCDEX /V /D:CD003 /M:10
@SET CLASSPATH=C:\IMAGING\PHOTOD~1.0\ADOBEC~1
set XILINX=C:\engtools\PIC\xilinx5101i
SET
PATH=C:\HARDWARE\GPIB\CBGPIB\GPIB351;C:\HARDWARE\UX1400;C:\ENGTOOLS\DBASE\OFFICE;C:\ENGTOOLS\PIC\XILINX5101I\BIN\NT;C:\WINDOWS\;C:\hardware\TEK\VXIPNP\WIN95\BIN;C:\ENGTOOLS\CAD\QUICKC~1
SET WISE02_LICENSE_FILE=C:\Programs\WISE Software
Solutions\License\Wise02.lic
set LM_LICENSE_FILE=C:\engtools\PIC\Modeltech_xe\license.dat
SET GPIBDIR=C:\HARDWARE\GPIB\CBGPIB\GPIB351
SET PATH=%PATH%;C:\PROGRAMS\COMMON~1\AUTODE~1

Displayed on boot:

As previous, but with the following extra lines displayed -

SET WISE02_LICENSE_FILE=C:\Programs\WISE Software
Solutions\License\Wise02.lic
set LM_LICENSE_FILE=C:\engtools\PIC\Modeltech_xe\license.dat
SET GPIBDIR=C:\HARDWARE\GPIB\CBGPIB\GPIB351
SET
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\HARDWARE\GPIB\CBGPIB\GPIB351;C:\HARDWARE\UX1400;C:\ENGTOOLS\DBASE\OFFICE;C:\ENGTOOLS\PIC\XILINX5101I\BIN\NT;C:\WINDOWS;C:\HARDWARE\TEK\VXIPNP\WIN95\BIN;C:\ENGTOOLS\CAD\QUICKC~1;C:\PROGRAMS\COMMON~1\AUTODE~1

These latter lines are not present in AUTOEXEC.BAT. They are also not
visible when accessing the AUTOEXEC file through MSCONFIG.

This "@" character seems to have been applied to
an AV SW autoexec line by some other application,
unless virus definition updates have taken the liberty.

previously: "C:\DIAGNOSE\NORTON~1\NORTON~1\NAVDX.EXE /startup"
modified to: "@C:\DIAGNOSE\NORTON~1\NORTON~1\NAVDX.EXE /Startup"

...........

The CONFIG.SYS file is pretty clean, and is ~unchanged
in the last year. It contains only the usual file,buffer and last
drive statement, with rem'd lines concerning CD drive paths.

Is it possible that the extra lines, visible only in the boot display,
are recorded elsewhere other than in AUTOEXEC.BAT?
..........

I realise my error here. I am still curious as to why these paths are
apparently processed with the AUTOEXEC.BAT file, as illustrated in the
boot display, without being present in the editable AUTOEXEC.BAT file.

The 'extra' phantom AUTOEXEC.BAT lines, visible on boot screen
display, are also visible running SET. The normal Autoexec.bat text
lines following the SET PATH statement in Autoxec, are not present.

I had assumed that the AUTOEXEC.BAT file was intended to serve a
purpose, and that it was not made redundant by some other habit of MS
Windows. Perhaps you can illuminate my ignorance in this matter more
fully?
I have admitted to confusing the phantom path setting to the COMMAND
directory with the executable of the same name.
Why would this be applied by any SW settup other than the original
path's text line 'owner'?

RL

 

[Miles Fromier]

Is it possible that the extra lines, visible only in the boot display,
are recorded elsewhere other than in AUTOEXEC.BAT?

Pif file? Maybe one of the MS-Dos prompt.pif files?

 

[Zvi Netiv]

[...]

I realise my error here. I am still curious as to why these paths are
apparently processed with the AUTOEXEC.BAT file, as illustrated in the
boot display, without being present in the editable AUTOEXEC.BAT file.

The %winbootdir% as well as %winbootdir%\command directories are included in the
default path variable even if not specified explicitly in the autoexec. They
are then further inherited to the path variable through the insertion of
PATH=%PATH%; at the beginning of extra PATH declarations in the autoexec.

The 'extra' phantom AUTOEXEC.BAT lines, visible on boot screen
display, are also visible running SET. The normal Autoexec.bat text
lines following the SET PATH statement in Autoxec, are not present.

That's because whatever edited the batch may have missed to include %PATH% in
the extra path line(s) and therefore replacing the already existing path string
with the one in the new path statement. Make it a rule to always start a new
path statement with PATH=%PATH%; if you want to preserve what's already there
and only add new directories to the path.

I had assumed that the AUTOEXEC.BAT file was intended to serve a
purpose, and that it was not made redundant by some other habit of MS
Windows. Perhaps you can illuminate my ignorance in this matter more
fully?

Try booting without autoexec (just rename it to something else), boot to the
command prompt and run the SET command. You'll see.

[...]

Why would this be applied by any SW settup other than the original
path's text line 'owner'?

Common sense suggests that the installer that put the @ operator on that line is
the one that owns that line, i.e. Norton!

Regards, Zvi

 

[Spalls Hurgenson]

When this win982Ed machine boots, without splash screens, I'm used to
seeing recognisable text from Autoexec.bat on the screen as the system
loads.

Recently, after reinstalling some cad SW, the text displayed on boot
has started to vary from that edited in Autoexec. This includes
reorganised but recognizable PATH text strings, with added, seemingly
unneccessary paths in the text strings. The cad SW was an Autodesk
package, and was a reinstall; not something new.

Did you check WINSTART.BAT? If I am remembering correctly, it's sort
of like an "autoexec.bat" for Windows(9x); it runs after DOS hands off
control to win.com but before the kernel is loaded. Or something like
that.

In any event, you may find your "missing" autoexec.bat commands in
there...

 

[legg]

Spalls:
Did you check WINSTART.BAT? If I am remembering
correctly, it's sort of like an "autoexec.bat"
for Windows(9x); it runs after DOS hands off
control to win.com but before the kernel is loaded.
Or something like that.

There is no searchable WINSTART.BAT file on this machine.
.......

Zvi:

The autoexec.bat file visible using SYSEDIT is limited
to the contents of the already accessible AUTOEXEC.BAT
file in root. It does not display the phantom path lines added
to the displayed boot routine.

The %winbootdir% as well as %winbootdir%\command
directories are included in the default path variable
even if not specified explicitly in the autoexec.
They are then further inherited to the path variable
through the insertion of PATH=%PATH%; at the beginning
of extra PATH declarations in the autoexec.

I'm afraid I don't understand default path variables or
inherited path variables. Is this understanding neccessary
to restore a simple AUTOEXEC.BAT file running, with all paths
displayed and owner-editable?

That's because whatever edited the batch may have missed
to include %PATH% in the extra path line(s) and therefore
replacing the already existing path string with the one
in the new path statement. Make it a rule to always start
a new path statement with PATH=%PATH%; if you want to
preserve what's already there and only add new directories
to the path.

How can I correct this error? I do not seem to have access
to the text lines of the file in which the error was made.
SYSEDIT, MSCONFIG and the AUTOEXEC.BAT files do not
include the erronious text entries that COMMAND\SET displays.
The PATH=%PATH% statement is already present in the
accessible portion of the normal intended batch file.

I believe the incorrect line is the last phantom line displayed
on boot or declared by SET:

SET
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\HARDWARE\GPIB\CBGPIB\GPIB351;C:\HARDWARE\UX1400;C:\ENGTOOLS\DBASE\OFFICE;C:\ENGTOOLS\PIC\XILINX5101I\BIN\NT;C:\WINDOWS;C:\HARDWARE\TEK\VXIPNP\WIN95\BIN;C:\ENGTOOLS\CAD\QUICKC~1;C:\PROGRAMS\COMMON~1\AUTODE~1

(no<cr>)

RL

 

[Zvi Netiv]

[...]

The autoexec.bat file visible using SYSEDIT is limited
to the contents of the already accessible AUTOEXEC.BAT
file in root. It does not display the phantom path lines added
to the displayed boot routine.

Of course. You are confusing yourself with your terminology. There are no
"phantom" path lines and what you see on screen is normal.

I'm afraid I don't understand default path variables or
inherited path variables. Is this understanding neccessary
to restore a simple AUTOEXEC.BAT file running, with all paths
displayed and owner-editable?

You are confusing yourself again with "owner-editable"! The entire autoexec is
editable and you will be turning in circles forever, until you master the basics
about batch command syntax, and environment variables of which PATH makes part.

Let's start with the notation %string%. This is the representation of a
variable of type string, used in batches as short writing for "substitute here
with the current content of that variable". This form is useful in *adding*
directories to the path, without dropping its original content. For example:
PATH=%PATH%;C:\NEWDIR adds the directory \NEWDIR to the existing path. When
echoed (another term you have to understand) on screen, then the explicit value
of %path% will be displayed, which is what you possibly take as "phantom" lines.

%winbootdir% is simply the default installation directory of Windows, in your
case C:\WINDOWS

The default environment variables are all established by IO.SYS, and MSDOS.SYS
(a plain text file since Win 95), when starting the OS and they include the
prompt format, winbootdir, path, tmp, temp and comspec.

How can I correct this error? I do not seem to have access
to the text lines of the file in which the error was made.
SYSEDIT, MSCONFIG and the AUTOEXEC.BAT files do not
include the erronious text entries that COMMAND\SET displays.
The PATH=%PATH% statement is already present in the
accessible portion of the normal intended batch file.

I believe the incorrect line is the last phantom line displayed
on boot or declared by SET:

SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\HARDWARE\GPIB\CBGPIB\GPIB351;C:\HARDWARE\UX1400;C:\ENGTOOLS\DBASE\OFFICE;C:\ENGTOOLS\PIC\XILINX5101I\BIN\NT;C:\WINDOWS;C:\HARDWARE\TEK\VXIPNP\WIN95\BIN;C:\ENGTOOLS\CAD\QUICKC~1;C:\PROGRAMS\COMMON~1\AUTODE~1

The establishing of the path is entirely controlled by the autoexec, and it's
time that you learn how to edit it so that it does what you need. Autoexec.bat
is edited by almost every software that installs and needs to run under DOS,
including Windows itself (Windows 9x uniquely, the other versions do not use an
autoexec). It is not uncommon that autoexec gets messed up due to mediocre
editing practice, like omitting the ";" separator when the path is declared in
more than one line, etc. Therefore, it's essential that you revise your
autoexec after having reinstalled Windows, or after having installed or removed
software that modified autoexec. As a rule, *never* restore an ancient copy of
your autoexec, backed up by software that you installed ages ago. It may not
reflect necessary changes that were made recently.

Here are a few guide lines how to properly set and edit your path:

The path may be declared in a single line, or in several lines if it gets too
long. The following are all valid declarations of a path line: PATH , PATH=,
SET PATH=. I'll use the second form in the following, for simplicity.

The first line with the path declaration should start with PATH=%PATH%;... etc.,
*or* with the explicit default path, in your case
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;... Consecutive path declarations should
also start with PATH=%PATH%;... etc., otherwise the previously declared
directories will be dropped from the path and the variable will be reset to the
new declared content. Maybe it's here that your "phantom lines" hide. ;-)

Pay attention to either terminate lines with the ";" separator, or start new
lines with the same, from the second path line and on. Remove duplicate
directories from the path lines because they eat up buffer space for the
environment, which is limited. Windows has the nasty habit to insert its
default directories upfront to every path line in the autoexec, every time you
reinstall it. Windows isn't the only software that does that.

To inspect if you did it correctly, type PATH in a DOS box and see if you didn't
miss anything, like a separator, etc.

You can debug the autoexec by starting your PC in the "step by step
confirmation" mode (use F8 when starting the PC). Before that, add the
following statement after every line in the autoexec and you'll soon find which
line is the one that you perceive as a phantom: ECHO %PATH%

Regards, Zvi

 

[legg]

Zvi:
The establishing of the path is entirely controlled
by the autoexec, and it's time that you learn how to
edit it so that it does what you need.
Autoexec.bat is edited by almost every software that
installs and needs to run under DOS, including Windows
itself (Windows 9x uniquely, the other versions do not
use an autoexec). It is not uncommon that autoexec gets
messed up due to mediocre editing practice, like
omitting the ";" separator when the path is declared in
more than one line, etc. Therefore, it's essential that
you revise your autoexec after having reinstalled Windows,
or after having installed or removed software that
modified autoexec. As a rule, *never* restore an ancient
copy of your autoexec, backed up by software that you
installed ages ago. It may not reflect necessary changes
that were made recently.

I believe the situation is: that the autoexec.bat has been
incorrectly updated by a discrete SW program reinstall.
However, I do not seem to have access to the text-editable
location where the error resides - I can only 'inspect' it.

Will simply removing paths from the accessible section of
Autoexec, where they seem to duplicate the inaccessible
section, miraculously shift the faulty lines back into the
AUTOEXEC.BAT file, for editing?

RL

 

[Zvi Netiv]

I believe the situation is: that the autoexec.bat has been
incorrectly updated by a discrete SW program reinstall.
However, I do not seem to have access to the text-editable
location where the error resides - I can only 'inspect' it.

Where from do you bring that nonsense? It's the first time I hear of an
autoexec that isn't editable, and can only be inspected. Autoexec.bat is a text
file located in C:\. The only thing that can prevent it from being edited is if
its attribute(s) were set as read-only, and/or system, and/or hidden. Even if
this is the case, then you can reset the attributes to archive only with either
the DOS command ATTRIB, or with Windows' Explorer, by setting the file
'properties'.

Will simply removing paths from the accessible section of
Autoexec, where they seem to duplicate the inaccessible
section, miraculously shift the faulty lines back into the
AUTOEXEC.BAT file, for editing?

Stop improvising and start working systematically. In my previous post, I
offered you a method how to inspect what you are doing. Use it. If incapable
to, then ask for assistance from an experienced user.

Regards, Zvi

 

[legg]

Where from do you bring that nonsense? It's the first time I hear of an
autoexec that isn't editable, and can only be inspected. Autoexec.bat is a text
file located in C:\. The only thing that can prevent it from being edited is if
its attribute(s) were set as read-only, and/or system, and/or hidden. Even if
this is the case, then you can reset the attributes to archive only with either
the DOS command ATTRIB, or with Windows' Explorer, by setting the file
'properties'.

The lines:

SET WISE02_LICENSE_FILE=C:\Programs\WISE Software
Solutions\License\Wise02.lic
set LM_LICENSE_FILE=C:\engtools\PIC\Modeltech_xe\license.dat
SET GPIBDIR=C:\HARDWARE\GPIB\CBGPIB\GPIB351
SET
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\HARDWARE\GPIB\CBGPIB\GPIB351;C:\HARDWARE\UX1400;C:\ENGTOOLS\DBASE\OFFICE;C:\ENGTOOLS\PIC\XILINX5101I\BIN\NT;C:\WINDOWS;C:\HARDWARE\TEK\VXIPNP\WIN95\BIN;C:\ENGTOOLS\CAD\QUICKC~1;C:\PROGRAMS\COMMON~1\AUTODE~1

do not appear in AUTOEXEC.BAT, but are run on boot, as if they were.
They are also displayed under COMMAND\SET.

If I cannot access these lines in a text-editable form, I cannot edit
them, to inspect or test test the effects of the edit.

Stop improvising and start working systematically. In my previous post, I
offered you a method how to inspect what you are doing. Use it. If incapable
to, then ask for assistance from an experienced user.

Ahem hem.......

RL

 

[Zvi Netiv]

On Mon, 04 Oct 2004 19:31:48 +0200, Zvi Netiv

The lines:

SET WISE02_LICENSE_FILE=C:\Programs\WISE Software
Solutions\License\Wise02.lic
set LM_LICENSE_FILE=C:\engtools\PIC\Modeltech_xe\license.dat
SET GPIBDIR=C:\HARDWARE\GPIB\CBGPIB\GPIB351
SET
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\HARDWARE\GPIB\CBGPIB\GPIB351;C:\HARDWARE\UX1400;C:\ENGTOOLS\DBASE\OFFICE;C:\ENGTOOLS\PIC\XILINX5101I\BIN\NT;C:\WINDOWS;C:\HARDWARE\TEK\VXIPNP\WIN95\BIN;C:\ENGTOOLS\CAD\QUICKC~1;C:\PROGRAMS\COMMON~1\AUTODE~1

do not appear in AUTOEXEC.BAT, but are run on boot, as if they were.
They are also displayed under COMMAND\SET.

If I cannot access these lines in a text-editable form, I cannot edit
them, to inspect or test test the effects of the edit.

If you followed my suggestion on how to trace the changing of the path
throughout the execution of the autoexec (insert "ECHO %PATH%" between every two
lines of the autoexec, and run it in a step by step mode) then you would have
known since long which line, or external (to autoexec) application introduces
the "phantom" path.

Ahem hem.......

Have you tried tracing the changing of the path, as suggested? Obviously not!

Zvi

 

[legg]

Zvi:
If you followed my suggestion on how to trace the changing of the path
throughout the execution of the autoexec (insert "ECHO %PATH%" between every two
lines of the autoexec, and run it in a step by step mode) then you would have
known since long which line, or external (to autoexec) application introduces
the "phantom" path.

Have you tried tracing the changing of the path, as suggested? Obviously not!

Call me dense, but you have referred to echoing twice in previous
correspondence, once refering to the common practice of starting with
'ECHO off', and a second time as a useful method that needs to be
learned.

This is the first time that the application of echoing has been
illustrated in a manner that can be followed through.

Thank you for the helpful suggestion - I'll try it out.

RL

 

[legg]

Have you tried tracing the changing of the path, as suggested? Obviously not!

When the visible AUTOEXEC.BAT line

PATH=C:\HARDWARE\GPIB\CBGPIB\GPIB351;C:\HARDWARE\UX1400;C:\ENGTOOLS\DBASE\OFFICE;C:\ENGTOOLS\PIC\XILINX5101I\BIN\NT;C:\WINDOWS\;C:\hardware\TEK\VXIPNP\WIN95\BIN;C:\ENGTOOLS\CAD\QUICKC~1

is echoed (with a following ECHO %PATH% line), it is echo-displayed on
boot with the 'C:\WINDOWS;C:\WINDOWS\COMMAND;' paths inserted at the
beginning of the line.
..........

When the visible AUTOEXEC.BAT line

SET PATH=%PATH%;C:\PROGRAMS\COMMON~1\AUTODE~1

is echoed in the same way, the 'invisible' lines not present in the
AUTOEXEC.BAT file are included in this echo-displayed line, on boot.

This brings to my attention the fact that the short version of this
last visible line was always substituted by the longer 'invisible'
line, on boot, since the SW reinstall; that the shorter path line was
never discretely displayed as it's precursors familiarly were.
...........

When the previous set paths are 'included' due to insertion of the SET
PATH=%PATH% statement, then the 'included' paths are also being
displayed in full for that line, on boot, even those that are inherent
and are not visible in the initial text entry in AUTOEXEC.BAT.

I guess I'm beginning to understand what you guys were trying to tell
me, in various ways, in the previous net postings.

Thanks for your help.

Any speculation on the purpose of the path line

C:\WINDOWS\; ......?

This looks like an error, as it doesn't point to a real directory.

RL

 

[Zvi Netiv]

When the visible AUTOEXEC.BAT line

PATH=C:\HARDWARE\GPIB\CBGPIB\GPIB351;C:\HARDWARE\UX1400;C:\ENGTOOLS\DBASE\OFFICE;C:\ENGTOOLS\PIC\XILINX5101I\BIN\NT;C:\WINDOWS\;C:\hardware\TEK\VXIPNP\WIN95\BIN;C:\ENGTOOLS\CAD\QUICKC~1

is echoed (with a following ECHO %PATH% line), it is echo-displayed on
boot with the 'C:\WINDOWS;C:\WINDOWS\COMMAND;' paths inserted at the
beginning of the line.
.........

When the visible AUTOEXEC.BAT line

SET PATH=%PATH%;C:\PROGRAMS\COMMON~1\AUTODE~1

is echoed in the same way, the 'invisible' lines not present in the
AUTOEXEC.BAT file are included in this echo-displayed line, on boot.

This brings to my attention the fact that the short version of this
last visible line was always substituted by the longer 'invisible'
line, on boot, since the SW reinstall; that the shorter path line was
never discretely displayed as it's precursors familiarly were.
..........

When the previous set paths are 'included' due to insertion of the SET
PATH=%PATH% statement, then the 'included' paths are also being
displayed in full for that line, on boot, even those that are inherent
and are not visible in the initial text entry in AUTOEXEC.BAT.

I guess I'm beginning to understand what you guys were trying to tell
me, in various ways, in the previous net postings.

Thanks for your help.

Any speculation on the purpose of the path line

C:\WINDOWS\; ......?

This looks like an error, as it doesn't point to a real directory.

C:\windows\ has the same meaning as C:\windows. It specifies the Windows
default installation directory.

Regards