I am automating a process and I use GPG2.exe for it.
Because I need to parse console output - potentially from different systems I need to set the languge to a controlled value.
I am following the Instructions from the manual which states that
LANGUAGE
Apart from its use by GNU, it is used in the W32 version to override the
language selection done through the Registry. If used and set to a valid and
available language name (langid), the file with the translation is loaded from
gpgdir/gnupg.nls/langid.mo. Here gpgdir is the directory out of which the
gpg binary has been loaded. If it can’t be loaded the Registry is tried and as
last resort the native Windows locale system is used.
I found a thread from 2011 that goes into a bit more detail regarding this problem, but this may actaully concern a different version.
I created a batch file for manual testing.
#echo off
REM C is meant to display untranslated messages according to one internet source
set LANGUAGE="C"
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
pause
I ecpext the output to be english but it is still german.
The manual states something about there beegin a "gnupg.nls" folder somewhere.
I was not able to locate this folder, which makes me wonder where german is loaded from.
Is there an error in the man page?
The pdf Version of the man page shows the same content as the man page that came with the installation.
Can someone shed some light on this?
I had the same problem that the output was in Swedish though I wanted it in English. The Windows display language was set to English, and I also tried setting environment variables but what solved it for me was to remove the Swedish translation for gnupg file found here:
C:\Program Files (x86)\gnupg\share\locale
After having removed the "sv" directory all output was in English.
The language directory can be pulled from the registry or I suppose it can also have a fixed path since I can not find the information in my registry.
On my testsysten the path is 'C:\Program Files (x86)\GNU\GnuPG\share\locale'.
This path contains folders for each language - not all of them contain translation files for gpg2 as far as I can tell.
The environment variable for language is not LANGUAGE but LANG. Setting it to C causes gpg2 to default to english.
I successfully tested the following call.
#echo off
set LANG=C
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
User bignose is still correct when he states that I should use the API instead but within my current restrictions I do not see a straight forward way to do so.
This isn't a programming question, as noted in the votes to close.
To answer a different question that could be asked from a programming perspective: Don't parse inherently-changeable console output, when there is a well-defined library API for the same functionality.
Related
I'm writing my first KDE plasmoid using QML. The hello world example uses a metadata.desktop file, while this KDE Plasmoid tutorial talks about a metadata.json instead and says that the metadata.desktop is 'discouraged' now and a desktop file should be converted to json using desktoptojson.
However, when I browse the globally installed plasmoids under /usr/share/plasma/plasmoids/ they all have both the metadata.desktop and metadata.json.
First question: So, what is really recommended? Just the metadata.json? Or both?
And, I wasn't able to find the desktoptojson tool. I'm using Linux Mint and the ./kdesrc-build --initial-setup for debian based systems says that it's "This is woefully incomplete and not very useful" ... I read that "most users of this [i.e. desktoptojson] utility will use the CMake macro kservice_desktop_to_json as part of the process of building a plugin.". However, I haven't found the documentation yet how to use this.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
Thanks!
First question: So, what is really recommended? Just the metadata.json? Or both?
In the current source code, most stock KDE applets such as the task manager use metadata.json's and have dropped the metadata.desktop's. It may be that the desktop files you have locally are left over from old versions, the new format was installed but the old one was never deleted.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
The man page on Arch you linked to has all the information. The tool is part of the package kservice. Find the equivalent in the repository for your distribution. Then, to use it
as part of a CMake macro:
add_library(myplugin MODULE ${myplugin_SRCS})
kservice_desktop_to_json(myplugin myplugin.desktop)
directly on the command-line:
desktoptojson -i myplugin.desktop -o myplugin.json
Is there a way to do so ? I searched Google but couldn't find any answer, so I guess the answer would be no. Is there anything close ? If not, would it be easy to extend red-lang to do so ?
From http://www.rebol.com/docs/setup.html
Startup Scripts
When REBOL starts it will automatically run the rebol.r and user.r files, if they exist.
The system looks for these files first in the current directory (or the directory of the script being run), then in the directory that contains the REBOL executable program.
Note that REBOL/Core runs fine without the rebol.r and user.r files. They simply provide an easy way to include additional code and data on startup, such as your network preferences.
If you compile your own Red interpreter you can add an autoloading file, maybe in console.red after system/console/init "Red Console" and before system/console/launch Best advice is to ask on the https://gitter.im/red/help site to ask for help. I guess this was already discussed.
Need To Set Version Information on the existing .dll
I need to add these to dll
1.File Version
2.Product Version
Tried this free version.
does not work
any Idea ?
There is a tool named verpatch that does exactly that.
After you download it you can run it from command line as below:
verpatch your.dll /pv "product.version" /va "file.version"
There are many other flags that can be used to add extra information.
Try:
verpatch /?
There is Resource Tuner Console from Heaventools Software.
Resource Tuner Console is a command-line tool that enables developers to automate editing of different resource types in large numbers of Windows 32- and 64-bit executable files.
See specifically the Changing Version Variables And Updating The Version Information page for greater details.
I've created a tool for this purpose because didn't find anything that is enough easy to use and easy to automate. Developers find it useful.
I'm sorry if that might seem as a self-ad but I know how annoying is to sync versions...
I have installed both the GNAT Programming Studio (GPS) and GtkAda. They both seem to work fine, but when I try to build the Simple Window project under New Project from Template, I get a bunch of errors saying "file gtk.ads not found." This seems to be a directory/dependency sort of problem - GPS doesn't know where to look for GtkAda. I'm running Windows 7, and have GPS installed at C:\GNAT\2011, and GtkAda installed at C:\GtkAda. I tried adding GtkAda to my PATH; at the moment my PATH user variable includes C:\GNAT\2011\bin, and my Path System variable includes C:\GtkAda\bin. Any advice on resolving this problem is greatly appreciated!
There are two things here.
First, "project" is key. Whenever you're building something that depends
on a library like GtkAda, it's much much easier if (a) you use GNAT
Project to manage it, and (b) you use the GPR(s) provided by the library
- always assuming it does, of course.
In the case of GtkAda, that means that your GPR needs to "with" GtkAda;
with "gtkada";
project Tinkering is
...
Second, gnatmake or gprbuild needs to be able to find gtkada.gpr.
The easiest way is to install GtkAda in such a way that gtkada.gpr is in
the default place that gnatmake/gprbuild expect to find GPR files. This
is $prefix/lib/gnat. GtkAda obeys this convention, so you could install
GtkAda under the same root as your compiler. I don't know why that's not recommended anyway.
If you don't want to do that, you can add the correct location to the
environment variable ADA_PROJECT_PATH, for example in your case set it
to C:\GtkAda\lib\gnat.
There is a lot of good stuff in the GtkAda README at libre.adacore.com, and in
the GtkAda User's Guide which I see from the README is also included with the
installed package at (in your case) C:\GtkAda\doc\GtkAda\gtkada_ug.
I'm going to have to write a number of vba modules for a project I'm working on, and would prefer to use SciTe to the built in editer in Office.
SciTe allows you to redirect the effect of hitting F1 to a arbitary command with the selected text as an argument. Is there anyway of using this functionality to search the relevant .chm files?
I'm guessing not, given that the help for vba is spread across multiple files, but I'm hoping someone can prove me wrong...
I'm especially interested if anyone can suggest a way to find out which chm file a particular libraries help resides, just from the fully delimitered name of the function.
Another approach is to use the HTML Help command line program HH.EXE to either show specific pages, or to decompile a particular CHM into HTML files.
Go to the folder mentioned by Lunatik in a command window and enter this command:
hh -decompile html vbaac10.chm
^^
# ac is for Access; use xl for Excel, wd for Word, etc
This will create an "html" folder below it and fill it with most of the files that went into creating the CHM file. The resulting HTML files can be opened directly in your browser, although they won't find their related style sheets or scripts which are addressed by their locations in CHM files. The style sheets and scripts do get extracted though so you can work with them too.
Also take a look at the XML files in the 1033 folder like VB_ACTOC.XML - this is the Table of Contents for the Access VBA help. It contains topic nodes with labels and urls for each item in the help file:
<topic>
<label>CheckBox Object</label>
<url>mk:#MSITStore:vbaac10.chm::/html/acobjCheckBox.htm</url>
</topic>
The mk:etc... url can be put on the HH command line to open that topic in a regular HTML Help window. Also, it shows the source CHM filename, and the relative path of the file when decompiled.
hh mk:#MSITStore:vbaac10.chm::/html/acobjCheckBox.htm
Working from these files, you could put together a script to find/grep files by keyword and show them in a browser, or you could reengineer the files into some sort of database or other lookup capability to work with SciTe's command based help system.
Some sites with more info about using HH.EXE:
HTMLHelp command-line
tips on using the HH command line and links to other sites
KeyHH 1.1
an alternate/supplemental program to HH.EXE for working with CHM files
The main files are held (for Office 2003 anyway) in Program Files\OFFICE11\1033, but accessing pages within them could be a bit tricky as Microsoft have gradually had to reign in the ability to delve into CHM files over the years due to security concerns.
This page (download) has some good info on what might still be possible as far as linking to specific pages inside a CHM
Having said that, I don't think this file is the default help shown to most users nowadays, but it's close enough, missing only the Office 2007 pimping most of the time. The online help seems to be set as default unless you specifically disable it during the Office install. The URLs are, I think, not very SEO friendly so couldn't be guessed. I suppose you could borrow a sneaky trick from scammers and craft URLs that point to the top link on Google, thusly: Range.
EDIT: Google cache link?
Inspired heavily by Lunatik's answer, adding:
command.help.$(file.patterns.vb)=http://www.google.co.uk/search?hl=en&newwindow=1&q=site%3Amsdn.microsoft.com+%222003+VBA%22+$(CurrentWord)
command.help.subsystem.$(file.patterns.vb)=2
to my vb.properties file gives me a reasonable work around (loads a Google search results page with search criteria of:
site:msdn.microsoft.com "2003 VBA" $(CurrentWord)
Obviously no guarantees of it taking me to a helpful page, but then the inline help in the VBA editer isn't all that reliable on that one either...
Can anyone who knows SciTe better suggest a more elegant solution?