Manage shortcuts arguments for NSIS CreateShortCut method via CMake - batch-file

First hi to everyone !
I want to create a shortcut to a batch file that does not prompt the DOS window. For that I have seen that the following command works very well:
wscript.exe invisible.vbs my_batch_file.bat
My problem is that I would like to create the shortcut with this command via CMake and NSIS. My problem is that it seems I cannot give more than one parameter after "wscript.exe" in the following command in the CMakeLists.txt file:
list(APPEND CPACK_NSIS_CREATE_ICONS "
CreateShortCut '$SMPROGRAMS\\\\$STARTMENU_FOLDER\\\\link.lnk' 'wscript.exe' 'invisible.vbs my_batch_file.bat' icon.ico 0 SW_SHOWMINIMIZED
")
And the space between "invisible.vbs" and "my_batch_file.bat" is not parsed as I expected (i.e. as a space...). Could anyone help me with this ? Thanks a lot for every comment (method or code hint) !

i don't now anything about NSIS, but maybe this is a hint in the right direction:
list(APPEND CPACK_NSIS_CREATE_ICONS "
CreateShortCut '$SMPROGRAMS\\\\$STARTMENU_FOLDER\\\\link.lnk' 'wscript.exe' 'invisible.vbs my_batch_file.bat' icon.ico 0 SW_SHOWMINIMIZED
")
also maybe, that 'invisible.vbs my_batch_file.bat' has to be ' invisible.vbs my_batch_file.bat' - starting with a space after '.
edit:
have you tried using " instead of '?

I solved my problem using the "NSIS.template.in" file, in which I created the following macro
!macro CreateShortcutBat link bat_file
CreateShortCut '$SMPROGRAMS\\$STARTMENU_FOLDER\\${link}' 'wscript.exe' 'invisible.vbs ${bat_file}' icon.ico 0 SW_SHOWMINIMIZED
!macroend
Then in my CMakeLists.txt file, I only need to call the macro this way:
list(APPEND CPACK_NSIS_CREATE_ICONS "
!insertmacro CreateShortcutBat 'Shortcut.lnk' 'my_batch_file.bat'
")

This short article shows exactly how to do what you want. It uses CPACK_NSIS_CREATE_ICONS_EXTRA and CPACK_NSIS_DELETE_ICONS_EXTRA to achieve the result. The example used there has two command line arguments, so you should be able to use the code there with simple modification. It also shows how to clean up after yourself and have the uninstaller remove the shortcut for you too.

Related

Obtain all filenames in a directory using vim

This is the algorithm of the code:
for every *file* in a directory
nnoremap ,*file* <C-o>:read $HOME/*file*
end
So the problem is, I don't know how to code the "for every file in a directory".
PS: I am new to vim and I don't know if it's possible
You're looking for glob() function. -> glob($HOME.'/*')
I'm not sure this is a good idea, but hey, who am I to judge? :)
Apart from glob() (see answer from #LucHermitte), you also need :execute:
execute 'nnoremap ,' . file . ' <C-o>:read $HOME/' . file
(or more elegantly with printf():)
execute printf('nnoremap ,%s <C-o>:read $HOME/%s', file, file)
Description
Vimscript is evaluated exactly like the Ex commands typed in the : command-line. There were no variables in ex, so there's no way to specify them. When typing a command interactively, you'd probably use <C-R>= to insert variable contents:
:sleep <C-R>=timetowait<CR>m<CR>
... but in a script, :execute must be used. All the literal parts of the Ex command must be quoted (single or double quotes), and then concatenated with the variables:
execute 'sleep' timetowait . 'm'

Batch How to start a program

I want to create a batch file to launch my executable file after it has made some changes to itself.
My batch file is:
START /D "C:\Users\me\AppData\Roaming\Test\Test.exe"
When I run it though I just get a brief console flash and Test.exe doesn't start up.
I've verified the EXE is there in the directory.
I've launched the exe manually to verify it is working as well.
My batch file resides in
C:\Users\admin\AppData\Roaming\run.bat"
There are two issues:
The /D option solely defines the starting or working directory, but not the program to execute.
The start command considers the first quoted argument as the title of the new window. To avoid confusion with other arguments, always provide a window title (that may also be empty).
There are two solutions, which are actually not exactly equivalent:
Remove the /D option, so the current working directory is used:
start "" "C:\Users\me\AppData\Roaming\Test\Test.exe"
Keep the /D option and explicitly provide the new working directory to be used:
start "" /D "C:\Users\me\AppData\Roaming\Test" "Test.exe"
try changing to this
start /d "C:\Users\me\AppData\Roaming\Test" Test.exe
You will see the console flash and your program should startup.
Update
Thanks for #SomethingDark 's suggestion to use the following code.
start "" C:\Users\me\AppData\Roaming\Test\Test.exe
However, the above code will not work if your filename contains space.
Try with the following command.Add it to your batch script.Notice that you have to add double quotes after start keyword if there is/are whitespaces in the path string.
start "" "C:\Users\me\AppData\Roaming\Test\Test.exe"
Enclose any directory names which are longer than one-word into quotation marks. So the following path:
start C:\Program Files\MySQL\MySQL Workbench 8.0 CE\MySQL.exe
Should become something like this:
start C:\"Program Files"\MySQL\"MySQL Workbench 8.0 CE"\MySQL.exe

Why multiple arguments with spaces are not interpreted correctly in a batch script?

I'm running an exe with multiple arguments that may or may not contain spaces. I encloses them with quotes but they are somehow not passed to the exe correctly.
Here's the command i'm using:
makeblastdb -in "D:\d b\sequence.fasta" -input_type fasta -dbtype prot -title xd -out "D:\d b\xd"
which I think cmd should pass 10 arguments to the exe but somehow it isn't passing correctly.
this is the result i get
BLAST options error: File "D:\d" does not exist.
which is basically saying that the second argument is being chopped for some reason?
Any help will be appreciated, thanks!
Based on your comments to your question, the BLAST utility does not properly handle quoted paths with spaces, and your volume does not support short file names.
Obviously you can move your working directory to a path that does not contain spaces.
An alternative is to use SUBST to temporarily create a virtual drive that points to your problematic path.
subst K: "d:\d b"
makeblastdb -in "K:\sequence.fasta" -input_type fasta -dbtype prot -title xd -out "K:\xd"
subst /d K:
Type subst /? for help with the command.
Update based on fact that you are running the command from within python
In your comment to this answer, you state you will attempt to get the command to work from within python. That could be the entire source of your problem.
You should try to run the command in your question directly from a Windows command prompt (cmd.exe console).
If the command does not work from the command prompt, then the problem is indeed with the BLAST utility, and SUBST is a good solution.
If the command does work from the command prompt, then the problem is with how you are shelling out the command from python, and the SUBST command should not be required.
I'm not a python user, but I see that many people have similar problems when using python on Windows. Perhaps this will help: How do I execute a program from python? os.system fails due to spaces in path
makeblastdb has an odd escaping convention. Try this:
-in \""D:\d b\sequence.fasta"\"
Unfortunately this doesn't work for -out, so dbenham's answer is probably best.
Alternative is you can try using directory shortname for "D:\d b" which you can find by running dir /X command on your D drive. For instance if I run dir /X on my C drive here is what I get:
01/21/2013 09:47 AM <DIR> PROGRA~1 Program Files
So you want to use C:\Program Files you can alternatively use C:\PROGRA~1.

My batch script is reporting an error stating "was unexpected at this time"

The Windows batch file I am trying to run contains the following assignment:
set ANT_HOME="C:/Program Files/apache-ant-1.8.4"
The offending line is:
call %ANT_HOME%/bin/ant -f ../config/common.xml start_db
And when I run the script with echo on I get:
call "C:/Program_Files/apache-ant-1.8.4"/bin/ant -f ../config/common.xml start_db
Files/apache-ant-1.8.4""=="" was unexpected at this time.
I've moved the second quote to to the end of the path, after the ant, but I receive the same error message.
If ant were an .exe I would say your code should work. But I suspect that ant is a batch file, and the error is occurring within the ant script.
I base my conclusion on your error message - specifically the following portion of it: ""=="". The error message is a batch parsing error, and I don't see how your code could generate those characters. So I figure ant must be a batch script that is causing the problem.
I suspect ant.bat has #echo off at the top, so you are not seeing the actual line that is failing.
Not having access to the ant.bat script, I couldn't possibly diagnose exactly what is failing, nor can I guess on how to fix it.
Update - exact problem found
I found a copy of ant.bat online.
It has the following line of code within:
if "%ANT_HOME%"=="" set ANT_HOME=%DEFAULT_ANT_HOME%
Your definition of ANT_HOME includes enclosing quotes, so the code is trying to execute
if ""C:/Program Files/apache-ant-1.8.4""=="" set ANT_HOME=%DEFAULT_ANT_HOME%
The space is not quoted, and you have your error.
All you need to do to fix everything is to remove the quotes from the definition of ANT_HOME, and then add quotes to your CALL statement:
set "ANT_HOME=C:/Program Files/apache-ant-1.8.4"
call "%ANT_HOME%/bin/ant" -f ../config/common.xml start_db
Forward-slashes are not always reliable as folder delimiters within Windows. See Why does the cmd.exe shell on Windows fail with paths using a forward-slash ('/'') path separator?.
Better to use back-slashes.
set "ANT_HOME=C:\Program Files\apache-ant-1.8.4"
call "%ANT_HOME%\bin\ant" -f ..\config\common.xml start_db
The quotes have to completely surround a file name. You can't use them for partial names. Try this instead:
set ANT_HOME=C:\Program Files\apache-ant-1.8.4
call "%ANT_HOME%\bin\ant" -f ../config/common.xml start_db
Oh, and I changed some of your slashes to backslashes (DOS doesn't like forward slashes). I assume you are allowed to use / in that parameter you are passing though.

Stupid Batch File Behavior. Tries to execute comments

I have tried prefixing lines with semicolons, 'REM', etc.. but no matter what when I run my batch file I keep getting "unknown command REM whatever"
"REM test" It is not recognized, and it is windows vista. I simply get "rem" output back to my console.
That's entirely normal behavior. Batch files are simply sequences of commands that are run one after another. So every line will get output to the console as if it were typed there.
H:\>echo rem test > test.cmd
H:\>test
yields the output
H:\>rem test
as if I typed rem test directly to the console.
You can suppress this by either prefixing the line with #:
#rem test
or by including echo off in the batch file:
#echo off
rem test
If I put ":: test" and execute it I get back "Test".
Can't reproduce here.
If I put "; test" it recursively executes itself
A semicolon at the start of the line seemingly gets ignored.
If you're talking about cmd.exe batch files under Windows, you can use:
rem this method or
:: this method.
For bash and a lot of other UNIX-type shells, you use:
# this method.
I'm pretty certain you're not using cmd.exe since that would give you an error like:
'rem' is not recognized as an internal or external command,
operable program or batch file.
rather then:
Unknown command ...
If you are using a UNIX-type shell, the # character is almost certainly what you're after. If you let us know exactly the shell you're using, we can probably help out further.
you probably created an UNICODE file. These files contain 2 bytes header named BOM
which is not shown by any editor but cmd attempts to execute them and fails.
To make sure this is indeed an issue: type any other command at the very beginning
of your file and see it throws the same error - for example #echo test
To fix it, just create a new plain text file and copy content of the original file there.
then remove the original file and replace it by the newly created one.
In my case the problems are line endings. Somehow Maven or the Jenkins pipeline running on a Linux machine changed the line endings from Windows style (CR LF) to Unix style (LF). Changing them back solves the issue for me.

Resources