Experimental Physics and
Industrial Control System

<[email protected]> · Tue, 24 Jan 2017 17:02:29 +0000

Hi,

As you were talking DLL paths there is another minor change that might we worth doing too. If some application on your computer has decided to install itself in a directory containing an & character and then place this location in your PATH, you will get strange behaviour if you just try and add to the PATH in the way dllPath.bat currently does as & is a command separator - this results in the part of the PATH after the & being discarded. For example:

    set "PATH=A & B;C"
    PATH C;%PATH%

Prints      'B' is not recognized as an internal or external command, operable program or batch file.
and PATH is left containing just C;A

The solution is to quote the entire expression using the syntax       SET  "PATH=epicsdir1;epicsdir2;%PATH%"        in dllPath.bat

Regards,

Freddie 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Andrew Johnson
Sent: 16 January 2017 22:17
To: Mark Rivers; [email protected]
Subject: Re: dllPath.bat problem

Hi Mark,

OK, I just merged my fix from 3.14 up to the Base-3.15 branch. A few other white-space changes (removal of trailing spaces) were also added by the Atom editor that I'm currently trying out.

- Andrew

On 01/16/2017 03:58 PM, Mark Rivers wrote:
> Hi Andrew,
> 
>> I will commit this change to Base (3.14 version)
> 
> Thanks, I saw your commit on the 3.14 branch.
> 
> I am actually running 3.15.5 now, so I needed a fix for 3.15.  This is what I did locally on my system:
> 
> corvette:base-3.15.5/src/tools>
> diff -U3 convertRelease.pl.orig convertRelease.pl
> --- convertRelease.pl.orig      2017-01-16 13:58:35.650816372 -0600
> +++ convertRelease.pl   2017-01-16 14:01:21.853482937 -0600
> @@ -119,15 +119,15 @@
>      unlink $outfile;
>      open(OUT, ">$outfile") or die "$! creating $outfile";
>      print OUT "\@ECHO OFF\n";
> -    print OUT "PATH \%PATH\%;", join(';', binDirs()), "\n";
> +    print OUT "PATH ", join(';', binDirs()), ";\%PATH\%\n";
>      close OUT;
>  }
> 
>  sub relPaths {
>      unlink $outfile;
>      open(OUT, ">$outfile") or die "$! creating $outfile";
> -    print OUT "export PATH=\$PATH:",
> -        join(':', map {m/\s/ ? "\"$_\"" : $_ } binDirs()), "\n";
> +    print OUT "export PATH=",
> +        join(':', map {m/\s/ ? "\"$_\"" : $_ } binDirs()), 
> + ":\$PATH\n";
>      close OUT;
>  }
> 
> It seems to work for dllPath.bat.  I have not tested relPaths.sh.
> 
> Mark
> 
> 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Andrew Johnson
> Sent: Monday, January 16, 2017 10:35 AM
> To: [email protected]
> Subject: Re: dllPath.bat problem
> 
> Hi Mark,
> 
> On 01/14/2017 05:14 PM, Mark Rivers wrote:
>> The EPICS build system can construct a dllPath.bat file in an ioc 
>> boot directory.  This is very convenient when running IOCs built 
>> dynamically for Windows.  An example of such a file is the one built 
>> in asyn/iocBoot/iocTest.
>>  
>> corvette:asyn/iocBoot/ioctest>more dllPath.bat @ECHO OFF PATH
>> %PATH%;/home/epics/support/asyn-4-31/bin/linux-x86_64;/corvette/home/
>> epics/support/seq-2-2-4/bin/linux-x86_64;/corvette/usr/local/epics/ba
>> se-3.15.5/bin/linux-x86_64
>>  
>> However, I think there is an issue with these files.  Note that it 
>> puts the current PATH at the beginning of the new path, rather than 
>> at the end.  This means that if the current path contains a DLL with 
>> the same name as a DLL created by EPICS, it will use the one in the 
>> current path, not the one that EPICS created.  It seems to me that 
>> this is the wrong thing to do, for several reasons:
>>  
>> -          What if the current path happens to contain, for example, a
>> DLL called "com.dll" or "ca.dll" which is completely unrelated to 
>> EPICS.  It will use the wrong DLL.
>> -          What if the current path contains an older version of one of
>> the DLLs that EPICS built.  This is what just happened to me.  I have 
>> the Anaconda Python bin/ directory in my path, and it contains 
>> hdf5.dll.  It is an older version of the HDF5 library.  EPICS 
>> areaDetector builds hdf5.dll using the latest code, actually patched 
>> beyond anything the HDF5 group had yet released.  My IOC won't run, 
>> because the old DLL does not contain the symbols added recently.
>>  
>> Are there any circumstances under which the current behavior would be 
>> desired?
> 
> Good point, I agree that for the reasons you describe the current 
> output is wrong.
> 
> An equivalent fix is also required for the relPaths.sh script, which 
> is the Cygwin equivalent of the dllPath.bat file for those running 
> IOCs under Cygwin and bash.
> 
> I will commit this change to Base (3.14 version):
> 
>> === modified file 'src/tools/convertRelease.pl'
>> --- src/tools/convertRelease.pl 2016-07-07 21:43:29 +0000
>> +++ src/tools/convertRelease.pl 2017-01-16 16:22:42 +0000
>> @@ -119,15 +119,15 @@
>>      unlink $outfile;
>>      open(OUT, ">$outfile") or die "$! creating $outfile";
>>      print OUT "\@ECHO OFF\n";
>> -    print OUT "PATH \%PATH\%;", join(';', binDirs()), "\n";
>> +    print OUT "PATH ", join(';', binDirs(), '%PATH%'), "\n";
>>      close OUT;
>>  }
>>  
>>  sub relPaths {
>>      unlink $outfile;
>>      open(OUT, ">$outfile") or die "$! creating $outfile";
>> -    print OUT "export PATH=\$PATH:",
>> -        join(':', map {m/\s/ ? "\"$_\"" : $_ } binDirs()), "\n";
>> +    print OUT "export PATH=",
>> +        join(':', map {m/\s/ ? "\"$_\"" : $_ } binDirs(), '$PATH'), 
>> + "\n";
>>      close OUT;
>>  }
>>  
> 
> - Andrew
> 

--
Arguing for surveillance because you have nothing to hide is no different than making the claim, "I don't care about freedom of speech because I have nothing to say." -- Edward Snowdon

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System