Set wrong value of relative path in form component in Linux in install4j - installation

When I am setting relative path in File Chooser form component in Linux environment using install4j installer it sets wrong value like I read data/conf/truststore.txt relative path from properties file and then set this path to File Chooser form component, instead of setting path "data/conf/truststore.txt" it sets "ES210/configure.sh.15633.dir/data/conf/truststore.txt". How can I correct this?

By default, the relative file is relative to the working directory. To set it relative to the installation directory, set it to
${installer:sys.installationDir}/data/conf/truststore.txt

Related

Setting environment variable with WiX, losing filename at end of path

I am utilizing the WiX "Environment" element to set an environment variable.
<Environment Action="create" Name="My_Certificates" System="yes" Id="certificate_env" Value="[CERT_XML_PATH]" Permanent="yes" />
CERT_XML_PATH gets set to the following: c:\this\is\my\path\myfile.xml
If that file actually exists, the environment variable is set properly and points to the file.
If that particular file doesn't exist at the time of the install, the environment variable is created and set, but the path is truncated to remove the myfile.xml portion.
This installer is part of a larger suite. It has its own standalone MSI. Installing one of the packages creates this xml file, but not the particular one I'm working on. If the xml file has been created, everything works fine. But if this installer is ran first, it will set the environment variable to
The environment variable "My_Certificates" gets created, but set to:
c:\this\is\my\path\
Instead of:
c:\this\is\my\path\myfile.xml
Troubleshooting:
The install log shows the property being set to the proper location.
MSI (s) (70:80) [15:27:44:988]: PROPERTY CHANGE: Adding CERT_XML_PATH property. Its value is 'c:\this\is\my\path\myfile.xml'.
Then we see the installer doing a WriteEnvironmentStrings a utilizing the proper path, including the xml file.
MSI (s) (70:80) [15:27:50:644]: Executing op: UpdateEnvironmentStrings(Name=My_Certificates,Value=c:\this\is\my\path\myfile.xml,Delimiter=[~],Action=536870914,)
WriteEnvironmentStrings: Name: My_Certificates, Value: c:\this\is\my\path\myfile.xml, Action 536870914
screen shot of system variables showing it not set properly
Any insight into why the file name is being truncated would be greatly appreciated.
Found the issue. There is a custom action in the installer that is also trying to set the Environment Variable. When disabling that custom action, everything works as intended.

Jmeter variable filepath is not resolved in FileToString function

I am using:
${__eval( ${__FileToString(${filePath}\x.xml)})}
to get an XML String from a file. The variable filePath is not resolved and I'm always getting the error "FileNotFound exception". If the absolute path is given, it works. It seems the variable is not resolved before the FileToString function call. Is there a way to use a relative path?
JMeter uses FileServer class to determine it's base directory.
If you look into JMeter log you'll be able to see something like:
2014/07/14 15:32:12 INFO - jmeter.services.FileServer: Default base='/opt/jmeter/bin'
In my case it's /opt/jmeter/bin
So if I drop x.xml file into /opt/jmeter/bin folder it would be resolved via ${__FileToString(x.xml,,)} function.
There is a property which can control base directory for relative paths resolution:
# Prefix used to identify filenames that are relative to the current base
#jmeter.save.saveservice.base_prefix=~/
You can set it to any other folder and JMeter will use it as the base for paths resolution.
The property can be changed in:
jmeter.properties file
user.properties file
overriden via -J command-line argument as
jmeter -Jjmeter.save.saveservice.base_prefix=c:/xml_payload/
jmeter.properties and user.properties files live under /bin folder of your JMeter installation, FileServer base is usually the same folder.
See Apache JMeter Properties Customization Guide for more details on JMeter tuning using properties.

Laravel location of created files

I'm attempting to modify a text file stored on the server using Larvel's File::put(filelocation,filecontents)
but I can't figure out what location this is relative to on the server. If I have a file "somestuff.json" within my LaravelApp/public folder, what location string do I use for a parameter to File::put() ?
File name for File::methods() is not relative you have to give the full file path:
File::put('/var/www/LaravelApp/public/somestuff.json', $filecontents);
But Laravel has some helpers to help you with this:
File::put(public_path().'/somestuff.json', $filecontents);
Also:
base_path(); // the base of your application LaravelApp/
app_path(); // Your LaravelApp/app
They are all in the file vendor/laravel/framework/src/Illuminate/Support/helpers.php.

How to set a relative path in a Generic Test's(Visual Studio 2010) working directory and summary results file

How to set a relative path in a Generic Test's(Visual Studio 2010) working directory and summary results file ?
As far I looked there is no way to set these locations programmatically in Generic test because the generic test has only properties page and no page to write C# code.
I have a folder structure as follows
c:\Files\GenericTestFolder\generictest.sln
c:\Files\SummaryFiles\summary.xml
Now I need to set the working directory to the following (To run an external program)
c:\Files\
And the Summary Results file location to:
c:\Files\SummaryFiles\summary.xml
I tried the following options to set the location of working directory(WD) and summary file(SF) location :
setting WD to "..\" or ".\" or "\" -> all of these seem to set the directory to c:\, so this is not useful for me.
Using a visual studio's inbuilt environment variable like %TestDeploymentDirectory% don't seem to work with "..\" , i.e %TestDeploymentDirectory% ..\ does not translate to parent of %TestDeploymentDirectory% during runtime.
You can use %TestLocation%. Which represents the location of the .GenericTest file.
Source

including files without having to specify $_SERVER['DOCUMENT_ROOT']

Before the PHP Version update I used to be able to include files as following without specifying the document root:
<?php include '/absolute/path/to/files/file1.php'; ?>
However I now have to include the same file as following:
<?php include $_SERVER['DOCUMENT_ROOT'].'/absolute/path/to/files/file1.php'; ?>
What php.ini setting could have overridden the former behaviour?
You need the php.ini directive include_path
See: http://us.php.net/manual/en/ini.core.php#ini.include-path
Including an absolute path should be working the same way straight through PHP 5.2.9 (haven't tried 5.3, but this shouldn't change). Since you're specifying an absolute path, the include_path directive has no bearing.
Can you provide some more information? What PHP version, platform, and the error you get back from include would be a great start.
Linux: RHEL 5 PHP: Version PHP 5.2.9 Error Messages I get are: PHP Warning: require(/conf/common.php): failed to open stream: No such file or directory in /var/www/vhosts/DOMAIN/httpdocs/tell-a-friend-fns.php on line 63 PHP Fatal error: require(): Failed opening required '/conf/common.php' (include_path='.:/usr/share/pear:/usr/lib/php:/tmp') in /var/www/vhosts/DOMAIN/httpdocs/tell-a-friend-fns.php on line 63
Okay, it looks like your application is living in /var/www/vhosts/DOMAIN, and you're looking for /conf/common.php, right? I don't know if your file is actually in /conf/ or if it's in /var/www/vhosts/DOMAIN/conf/ (I assume the latter, with the information given). If it's in /conf/, then make sure that your Web server user can read that directory. If not, change your include to /var/www/vhosts/DOMAIN/httpdocs/conf/common.php.
Better yet, you might be able to do include '../conf/common.php, depending on where common.php lives in relation to your main script for the requested page.
Remember that any path given with a leading "/" is absolute in relation to the file system, not the Web server document root. Any path given without a "/" is assumed to be a relative path, relative to your executing script (not the current file). My guess is that prepending $_SERVER['DOCUMENT_ROOT'] to your path is changing the absolute path to a relative path. I have no idea why an absolute path would act as a relative path pre-upgrade, unless you were operating in a jailed environment (common with virtual hosts) which got removed during the upgrade.
I always use something like:
require( dirname( __FILE__ ) . '/../../subdir/somefile.php' );
It gives you a relative path from the current file, but resolves to an absolute path (by using dirname on the current file).

Resources