If I run Inno Setup compiler from a command line/batch file it creates an exe with the version information in the file name.
However, when I run from hudson (same command line) I don't get the version information.
Perhaps I am missing something.
Is this a known issue?
This is the way I am doing it in the iss script file.
#define FileVerStr GetFileVersion(SrcApp)
EDIT:
The env vars are all set for all users - not just my login - so the service has access to everything that the command line build does.
EDIT: See my answer for a resolution of this.
Like "tim" has said, then relative paths doesn't work as expected for defines.
#define MyAppVer GetFileVersion(SourcePath + "\..\Build\Release\MyExeName.exe")
#if MyAppVer == ""
#error MyAppVer - Version information not found!
#endif
By prefixing with SourcePath then the relative path will start from the path where the InnoSetup-script is located.
You are likely running Hudson on Windows given the technology mentioned.
When there is a discrepancy between what happens on the command line and what Hudson does, it is often because Hudson is running as a service on Windows. This means it is running as the service user, which is distinct from your login account.
I would look for an environment variable that you have defined in your user profile that may enable this behavior, that is not being set for the service user.
I am not exactly sure how to describe how I "fixed" this/worked around it.
It seems the GetFileVersion() method does not use the same base path as the other part of the Inno functionality that determines where the source files/installable files are.
The SAME relative paths used for:
// this is for determining what files get put into the install image
[Files]
Source: ..\Build\ForRelease\MyExeName.exe; DestDir: {app}
and
#define SrcApp "..\Build\ForRelease\MyExename.exe"
#define FileVerStr GetFileVersion(SrcApp)
apparently do not use the same mechanism to resolve the file name/path. So what i did to work around this was to copy the exe file that contains the version info to two additional different locations (aside from ..\Build\ForRelease) - one where hudson starts the processes and also to the path where the inoo script is. (I am too lazy to figure out which one is the one that makes it all work.
Again, this works fine from my batch file but not from hudson. It is essentially a strange interaction with how Inno works I guess.
Related
I'm using Windows 10 and installed gitlab-runner using the Gitlab's doc.
After a successful installation and registration, I try to leave the folderI used to install (C:\Gitlab-Runner in my instance) and try to run gitlab-runner. I get the response: 'gitlab-runner' is not recognized as an internal or external command, operable program or batch file.
I am able to run without issue in the C:\Gitlab-Runner folder, but nowhere else.
Based on the documentation and tutorials I looked at, I wouldn't expect this behavior; am I supposed to?
Did you check to ensure that it was added to The windows environment. You will likely need to update the path variable to include the path that you are using to run the command.
On windows, you add to the PATH variable with the following steps (yanked from google search page):
On the Windows taskbar, right-click the Windows icon and select System.
In the Settings window, under Related Settings, click Advanced system settings. ...
On the Advanced tab, click Environment Variables. ...
Click New to create a new environment variable.
Once you've added C:/Gitlab-runner/ to PATH, I believe you should be able to invoke with gitlab-runner.
The only thing I'll add is that, for setting PATH, the last step above is most likely unnecessary, as there will already be a variable named PATH with a list of directories stored in it. Just click EDIT and add your directory to the end of the list. Be sure to add the separator that is used for the others (I believe it's a semicolon on Windows...)
Solved. I need to call C:/Gitlab-runner/gitlab-runner rather than just gitlab-runner in other directories.
Please make sure the name of the exe is correct in the folder C:\GitLab-Runner
In my situation, I have the gilab-runner.exe.exe, there was an extra .exe in the file name though its not showing in the directory.
enter image description here
Running the Config Wizard via the start menu (Windows 7) simply fails. Running it from the command prompt shows the infamous
'C:\Program' is not recognized as an internal or external command, operable program or batch file
I know this is due to the space in "Program Files" (dir C:\pro* /x doesn't show C:\Progra~1).
The solution I've found for this is to replace C:\Program Files\... with "C:\Program Files\...".
My question is this:
Since the WebLogic config wizard runs from config.cmd, which is loaded with variables for path names, do I have to update Windows system environment variable PATH and put quotes around all path names that have a space (since I don't know what WebLogic is looking for)?
Update:
I tried this and received Files was unexpected at this time. Which made me think I was off with the quotes, but they are paired properly around every path with C:\Program Files. A search on this error resulted with this advice...basically the double quotes are the cause.
If the lack of quotes causes the first problem, and the presence of quotes causes the second problem, what to do? It's a loop...
I installed another JDK in a location with no spaces (still got the error because I didn't change any environment variables because work site will change them back, breaking things).
The install docs in chapter 4 say:
To begin domain configuration, navigate to the
ORACLE_HOME/oracle_common/common/bin directory and start the
Configuration Wizard.
On UNIX operating systems:
./config.sh
On Microsoft Windows operating systems:
.\config.cmd
Which implied at a command prompt (to me anyways). I was reading another site for help and the guy said to update config.cmd to point it to new JDK location instead of JAVA_HOME.
Instead of right clicking on config.cmd to edit it I double clicked it and lo and behold...this nice domain creator GUI opened up where I could specify which JDK to use. Done! No errors...
If that little tidbit were in the docs it would've save me a lot of time and frustration. And no, I'm not a server admin type, just a dev who needed a local web server for testing purposes.
I hope this helps someone.
How can I get ejabberd to run an external auth script on windows?
So far- I've modified the file
C:\Program
Files\ejabberd-15.06\lib\ejabberd-15.06\priv\cfg\ejabberd.yml
to comment out the existing auth_method directive and instead added this:
auth_method: external
extauth_program: "D:\\DROPBOX\\Dropbox (Personal)\\EJABBERD\\auth\\ejabberd-auth.exe"
However, when I try to connect to the server- I see nothing in the logs indicating an attempt to run the script. I've even tried changing it to a non-existant file to see if that will log an error of some sort, but nothing.
All I get are "Accepted connection" type of logs.
In case it matters- upon start I do get several "unknown option" errors, including "ejabberd_config:validate_opts:752 unknown option 'auth_method' will be likely ignored" - however it seems this is a known, cosmetic-only error (see: https://github.com/processone/ejabberd/issues/630)
I do not use Windows, but, you should try playing with Erlang open_port command:
open_port({spawn, "YOURCOMMAND"}, [{packet, 2}]).
Note that open_port Erlang documentation says:
For external programs, the PATH is searched (or an equivalent method is used to find programs, depending on operating system). This is done by invoking the shell on certain platforms. The first space separated token of the command will be considered as the name of the executable (or driver). This (among other things) makes this option unsuitable for running programs having spaces in file or directory names.
I see your path has spaces. That alone should indeed make it impossible to call your command.
That said, external_auth command has never been tested on Windows. You may need to patch ejabberd command to make that authentication through external process work. I would be surprised if it works as is.
Wondering if it's possible to move the module directory in a JBoss 7 install to a non-default loco.
Does anyone know of a config param to specify where to pick it up?
Kinda like a conf-dir, bin-dir type of thing.
Thanks,
Aaron.
Yes, it's actually possible. As the documentation states, from within the standard launch scripts users are able to manipulate the module path by setting the $JBOSS_MODULEPATH environment variable. (If not set, $JBOSS_MODULEPATH is set to $JBOSS_HOME/modules). The module path is provided to the running process via the -mp command line argument that is set in the standard scripts.
I try to commit a folder hierarchy into out Mercurial repository, which contains files, whiches absolute path length exceeds 255 characters (Windows max. path length).
For these files I receive an error message saying
The system cannot find the path specified
We use TortoiseHG and an Eclipse plugin for Mercurial, both don't work.
Has anybody found a solution for this?
(I do not want to change the repository's location on my HD)
There exists an extension which is aimed at solving this exact problem. It is: https://www.mercurial-scm.org/wiki/Win32LongFileNamesExtension
It uses \\?\ style names to transparently handle long files.
I'm the author, let me know if it works for you.
I've just installed Aaron Cohen' extension, as he suggested.
And it perfectly works with my TortoiseHG 2.6.1 ! Thanks, Aaron!
Though, I'd like to add a detailed guide here, because I cannot find one...
(At least here's what I did on my Win7 x64 - I'm not sure this is the shortest way possible)
1. Download Mercurial-py
Note the Python version required
I've downloaded "Mercurial-2.4.2 (64-bit py2.7)"
2. Download Python
Make sure you're downloading compatible version.
I used "Windows X86-64 MSI Installer (2.7.3)" link
3. Install Python
I've installed it to "D:\Python27"
4. Download pywin32
It's required by the Win32LongFileNamesExtension.
Note the Python version number in pywin32's filename.
I used "pywin32-218.win32-py2.7.exe"
5. Install pywin32
Make sure installer detected correct Python installation
In my case, it's installed in "d:\Python27\Lib\site-packages\pywin32_system32\"
6. Install Mercurial
Make sure installer detected correct Python installation
In my case, it's installed in "d:\Python27\Lib\site-packages\mercurial\"
7. Set PYTHONPATH enviroment variable
setx PYTHONPATH d:\Python27\Lib\site-packages\win32lfn\src;d:\Python27\Lib\site-packages\mercurial\
Use this cli command, or do the same using some other method
Of course, you should adapt paths to your needs
Restart your cli after this, to make sure env. variable is now properly set
8. Download win32lfn
Check for availible downloads on the project's repository page
If there's still nothing, just clone a repository from https://bitbucket.org/remleduff/win32lfn to "d:\Python27\Lib\site-packages\win32lfn\"
Now "win32lfn.pyc" should be in "d:\Python27\Lib\site-packages\win32lfn\src\"
9. Do interanal win32lfn tests
cd /D D:\Python27
python d:\Python27\Lib\site-packages\win32lfn\tests\testwin32lfn.py
10. Create a backup of your repository.
For me, everything went just fune, but you never know....
11. Add win32lfn to hgrc
[extensions]
win32lfn = d:\Python27\Lib\site-packages\win32lfn\src\win32lfn.py
you can find "hgrc" in your ".hg" folder, inside your repository
12. Test it!
The quick and dirty solution is to map a network drive.
For the path c:\some long path\project folder
Map \\localhost\c$\some long path\ to drive Z:\
cd z:\project folder
hg push
We are using this successfully as an interim solution, before migrating to shorter paths.
The mercurial plugins above look good but unfortunately there are numerous non-mercurial bugs related to path greater than 255 characters. For example the VS2010 failure at exactly 259 characters is a real corker!
http://support.microsoft.com/kb/2516078
See https://www.mercurial-scm.org/wiki/Win32LongFileNamesExtension (Aaron pointed to it via the mercurial-devel mailing list).
Another workaround without changing the path to the repo could be to create a second path to it by means of directory junction points. It may work because the reparsing is done at a very low level by the file system driver (or rather some installed filter), so the full (Unicode) path is known by that time and the expansion to beyond 260 characters should work fine. Give it a try. You can use the tool mklink on Windows Vista or 7 and junction.exe from Sysinternals on Windows 2000 or later. For mklink make sure to create a junction point. I'm not sure the reparsing mechanism works the same for directory symlinks (although I faintly remember that it should).
If you don't have a Unicode version of the program available, the limit is 260 characters (including drive letter part). There is nothing to get around it.
However, all ANSI functions are implemented by means of their Unicode counterpart and therefore you may get lucky by providing the full path prepended with \\?\. This may work, but likely won't because the program itself didn't consider anything beyond MAX_PATH (= 260). Ask the author to compile a Unicode version and use the prefix I mentioned. This will fix the issue.
This is a limit of the Win32 subsystem. The absolute path length limit is approximately 32,767 characters. Approximately because the object manager of Windows may expand it (symlinks in the object namespace and the likes).
Windows 10 system running the mercurial 4.4.1 client
Aaron Cohen extension will work I did need make a small one small tweak
based on a comment from mhaecki on this thread: https://bitbucket.org/remleduff/win32lfn/issues/13/not-compatible-with-version-431
in the win32lfn.py file I changed:
from mercurial import util, osutil,cmdutil
from mercurial.i18n import _
to:
from mercurial import util, cmdutil
from mercurial.cext import osutil
from mercurial.i18n import _