.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)
Related
In the documentation of pythonforandroid, at https://python-for-android.readthedocs.io/en/latest/buildoptions/, there is a build option described called blacklist.
--blacklist: The path to a file containing blacklisted patterns that will be excluded from the final APK. Defaults to ./blacklist.txt
However, not a word can be found anywhere about how to use this file and what exactly the patterns are supposed to represent. For instance, is this used to exclude libraries, files, or directories? Do the patterns match file names or contents? What is the syntax of the patterns, or an example of a valid blacklist.txt file?
This file should contain a list of glob patterns, i.e. as implemented by fnmatch, one per line. These patterns are compared against the full filepath of each file in your source dir, probably using a global filepath but I'm not certain about that (it might be relative to the source dir).
For instance, the file could contain the following lines:
*.txt
*/test.jpg
This would prevent all files ending with .txt from being included in the apk, and all files named test.jpg in any subfolder.
If using buildozer, the android.blacklist_src buildozer.spec option can be used to point to your choice of blacklist file.
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.
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.
I've got a huge phing build file here. Is there a way to put things like filesets into an external file used by the build.xml? Just need some organisation here.
You can try using the import task, which lets you split a build file into multiple files.
You can also look into property files
FileLists also support a listfile property which is a text file with one file per line.
FileSets support the includesfile and excludesfile property which is a text file with a list of patterns.
I've gone trough my source files and updated all my strings using the NSLocalizedString() macro. Now because I have a lot of strings that come up across multiple source files , I decided to place a large amount of the strings in a header file called "LocalizedStringDefinitions.h" using the #define directive. So for example each line looks like this,
#define kLocalizedSTRINGNAME NSLocalizedString(#"STRINGNAME", #"Comment")
I just ran the genstrings command in terminal and the Localizable.strings file that was created contained only the localized strings that were directly placed in my code and none of the #defined ones. I have around 100 lines of #defined strings which I do not want to place back in my code especially because they appear across multiple files. How can I localize the strings?
I just realized how simple this is. If you look a the Terminal command genstrings *.m the .m part is clearly specifying to look through the implementation files. The file with the #define's is a header file (.h) so by using the command genstrings *.h I was able to generate the .strings file, or I could just change the name of the file with the definitions to "LocalizableStringDefinitions.m"