There is a .properties file containing many name-value pairs, separated by "=". Is there any standard way in FinalBuilder to update the value of some properties?
It is possible by using "Text Find/Replace" action and its wildcard feature. Just replace:
<propertyname>=*
with
<propertyname>=<YourDesiredProperty>
Related
I want to change a js file and html file using release pipeline in VSTS. What I see is VSTS only allows JSON and XML config file transformation but I want to change other types(formats eg: .cs, .js, .ts, etc) of file as well.
Earlier we were using octopus deploy which has the option to transform these files.
Please let know if you know some other way to change the file in pipeline itself..
Can we change any file type using variable substitution rather than just JSON or XML
You could use Replace tokens from the Marketplace:
https://marketplace.visualstudio.com/items?itemName=qetza.replacetokens
to change other types files.
You define the desired values as variables in the Release Definition and then you add the Replace Tokens task and configure a wildcard path for all target text files in your repository where you want to replace values. The token that gets replaced has configurable prefix and postfix (default are #{ and }#).
So, the format of variable in those files are #{TestVar}#.
Check my other thread for some more details.
Update:
We do not want to use third party tools from marketplace, do we have
any way within the scope of existing microsoft tools.
I am afraid there is no such directly existing Microsoft tools to change other types files at this moment, you could develop your powershell scripts to replace file content.
Check this thread for some more details.
Hope this helps.
Unix File Associations is a welcome new feature in install4j 8.
I'm trying to register multiple file extensions as file associations with the same mime-type with the install4j 8.0.1 Unix Shell Installer.
The "Create a File Association" action only seems to accept one file extension so I initially tried adding multiple of these actions with a different extension but the same mime-type. This seems valid, but when it translates into the actual installation of the application it appears that the mime-info XML files being made are named with the same mime-type and so all but one get overwritten. This leads to only one file extension being associated with the mime-type.
I've also tried various separators (space, comma, semi-colon) in the file extension field, but this just ends up as a single unlikely looking extension in the mime-info XML file!
(e.g.
<glob pattern="*.ext1,ext2" weight="60"/>
)
The mime-info XML format allows multiple <glob> elements, so the mime-info XML file could contain, e.g.
<glob pattern=".ext1" weight="60"/>
<glob pattern=".ext2" weight="60"/>
but I can't see a way to get to this from install4j8.
Is there a way?
As of 8.0.1, this is indeed not possible. In 8.0.2, you will be able to specify multiple extensions separated by commas. Please contact support#ej-technologies.com to get a build where this is already implemented.
.properties file extension is used for loading context variables through a file in Talend. In tFileProperties, while selecting the file format for parameter file, we have a drop down of .properties and .ini extension also. I want to know what is the difference between .ini and .properties file format in relevance to parameter file extensions in Talend. In which case we use .ini extension?
Documentation says that the only difference is that the .ini files are regrouped in sections, which are somewhat iterated, which I failed to understand. Can anyone elaborate with an example?
Both file types allow you to declare key/value pairs like so:
key=value
The difference between the two is that .ini uses sections. tFileInputProperties allows you to read a section by its name:
The big advantage of this over .properties file is that .ini file can have the same variable inside multiple sections. For instance, your sections can be your execution environments (DEV, PROD..etc) with your variable having a different value for each environment. You can then get the value by reading only the section corresponding to your execution environment (section can be a context variable).
This what I get by setting section to "DEV":
If you declare the same variable in .properties file multiple times, the last occurence of the variable is the one that will be returned. Suppose my file looks like this :
This is the result (notice how only 2 rows are read, and not the 4 present in the file)
In org-mode, when I export to PDF or HTML, I'd like to specify the names of the resulting files. Ideally two separate names, one for the PDF, one for the HTML. Is this possible?
Chris's answer is out of date. There is now an EXPORT_FILE_NAME setting:
#+export_file_name: <filename>
If you put this at the start of your file (not in a subtree), it will name the entire file that when you export.
Edit: For newer versions of org-mode, see slondr's answer.
It doesn't look like you can specify a name for the exported file as a whole.
From the link, emphasis mine:
When exporting only a subtree, each of the previous keywords can be overriden locally by special node properties. These begin with ‘EXPORT_’, followed by the name of the keyword they supplant. For example, ‘DATE’ and ‘OPTIONS’ keywords become, respectively, ‘EXPORT_DATE’ and ‘EXPORT_OPTIONS’ properties. Subtree export also supports the self-explicit ‘EXPORT_FILE_NAME’ property [4].
[4] There is no buffer-wide equivalent for this property. The file name in this case is derived from the file associated to the buffer, if possible, or asked to the user otherwise.
In my program I have a list of pairs - name and size.
I want to build this list from the command line interface using boost::program_options.
It should look something like this:
myProg --value("John",10) --value("Steve",14) --value("Marge",28)
I also need this to be in order - Steve will be after John and before Marge on the list. Is that possible with boost::program_options?
This CLI syntax is just an idea to get the list. If you have a better one, do tell.
You just define your option
("value", value<vector<YourPairType>>()->composing(), "description")
and an appropriate
istream& operator >> (istream& in, YourPairType& pr) { /* ... */ }
that reads a single YourPairType from in in your ("John",10) format. Parsed options will be stored in the order they appear in the command line.
You can achieve greater flexibility if you use custom validators instead of operator >>.
A file with each line having one pair of values can be one option. The file could be a plain ascii text file or you can go for xml files too - refer to boost serialization.