I have a CMake script that creates a command string and runs it with execute_process. But, some of the parameters are not getting filled in properly. Is there a way to print the actual command string that is getting executed?
There is a message call just above it which shows what the command should be but when I run that string on the command line, it works fine while the CMake execute_process fails.
Starting from CMake 3.15, execute_process has a COMMAND_ECHO <where> parameter, and there is also the CMAKE_EXECUTE_PROCESS_COMMAND_ECHO variable to set a default behaviour:
COMMAND_ECHO <where>
New in version 3.15.
The command being run will be echo'ed to <where> with <where> being set to one of STDERR, STDOUT or NONE. See the CMAKE_EXECUTE_PROCESS_COMMAND_ECHO variable for a way to control the default behavior when this option is not present.
Related
Suppose in CMakeLists.txt I have
add_executable(mytarget main.cpp)
enable_testing()
add_test(mytarget_test0 mytarget -option0)
Is there any easy way how can I run mytarget in GDB with all command line options from some particular CTest test? (Other than searching for test in CMakeLists and then copy-pasting add_test parameters to command line manually?)
Real life scenario: I run all tests using ctest, one fails, I want to open it in debugger quickly.
In other build systems there are command line parameters to use gdb, for example in Meson meson test --gdb testname , in bazel bazel --run_under=gdbserver. I did not found anything similar for CTest
It is possible to get test command with arguments:
ctest -R $regex_matching_test -V -N
As output you will get something like:
Test project ../cmake-build-debug-gcc7
Constructing a list of tests
Done constructing a list of tests
1: Test command: ../cmake-build-debug-gcc7/my_tool "-v" "test0"
Test #1: my_tool_test0
Total Tests: 1
Then using regexp it is possible to grab command line args for gdb
I use the following procedure:
make clean
make # Build target and all unit tests
make test # Run all unit tests: make test
You will get an result list and some output, depending of the unit test frame work. Fix the issue and re-run the failed test within gdb until it succeeds. Restart the whole procedure.
In case you are using an IDE (e.g. QtCreator) it is easy to debug through the failed test case.
sqlplus -s £ORA_LOGIN/£ORA_PASSWORD #./sql/getsess.sql £FEED > £FEED.lst
This is the command in a shell script. Can anyone please tell me what is this doing? because i have no knowledge about the sqlplus command
This command runs the script ./sql/getsess.sql providing the value £FEED as parameter and using the credentials £ORA_LOGIN/£ORA_PASSWORD to login. It will store the output from the call to SQLPlus in the file named £FEED.lst.
Note that SQLPlus is invoked in silent mode (parameter -S), so most of the output will not be seen in the output file.
I want to manage (Upload\Download\Delete) a file on an FTP Server with WinSCP command line.
It says I can use environment variables! I have some text files that have the date in their name.
I just created the variable I want:
Test_%DATE:~10,4%%DATE:~4,2%%DATE:~7,2%.txt
and tested it with Windows echo command. It becomes Test_20140916.txt and that is exactly what I have now.
But when I try to upload that file in WinSCP, I get this error:
winscp> put D:\FTP\Test_%DATE:~10,4%%DATE:~4,2%%DATE:~7,2%.txt
File or folder 'D:\FTP\Test_%DATE:~10,4%%DATE:~4,2%%DATE:~7,2%.txt' does not exist.
System Error. Code: 123.
The filename, directory name, or volume label syntax is incorrect
(A)bort, (R)etry, (S)kip, Ski(p) all:
Any idea how to resolve this issue?
WinSCP supports a timestamp formatting natively:
put D:\FTP\Test_%TIMESTAMP#yyyymmdd%
To explain why your syntax does not work: while WinSCP supports the environment variables in scripting commands, it does support only a basic syntax %NAME%, as documented:
https://winscp.net/eng/docs/scripting#syntax
To achieve, what you need, you have to resolve the value to another variable and refer to that in the WinSCP command:
set STAMP=%DATE:~10,4%%DATE:~4,2%%DATE:~7,2%
winscp.com /script=script.txt
where script.txt can use %STAMP%:
put D:\FTP\Test_%STAMP%
Also note that a value of the %DATE% is locale-specific, so make sure you test your code on the same locale on which you gonna use it. Or even better, use a locale independent wmic os get LocalDateTime:
for /F "usebackq tokens=1,2 delims==" %%i in (`wmic os get LocalDateTime /VALUE 2^>NUL`) do if '.%%i.'=='.LocalDateTime.' set LDT=%%j
set STAMP=%LDT:~0,4%%LDT:~4,2%%LDT:~6,2%
I'm having two problems related to the same issue:
I have a shared object saved in `pwd`/lib and while the executable that uses it compiles successfully (by using -l and -L switches), at runtime, it's giving me grief. If I try to run LD_LIBRARY_PATH=/my/absolute/path/to/library/directory ./test it works fine. But if I export LD_LIBRARY_PATH=/my/absolute/path/to/library/directory and do ./test it says that it can't find the shared library. However, if I do LD_LIBRARY_PATH=$LD_LIBRARY_PATH ./test again it works fine!! Any ideas on what I'm doing wrong?
Second issue is related to the exporting of the LD_LIBRARY_PATH env variable. If I open a terminal and type export LD_LIBRARY_PATH=/path/to/stuff and then type echo $LD_LIBRARY_PATH, the variable is correct. However if I write a script containing the export command, simply running it doesn't update the variable, instead I need to run source install.sh in order to actually persist the variable. What's the best solution for this?
Thank you for your time!
To answer the second question first:
source executes the script inside the current shell, ./install.sh opens and executes it in a different shell.
http://www.unix.com/unix-dummies-questions-answers/537-difference-between-source-exec-script.html
Now for your first question:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH ./test sets the LD_LIBRARY_PATH variable before just one command (the ./test command). For the same reason above, I believe this isn't getting transferred to whatever shell ./test creates. To make it persist, you may need to put the export LD_LIBRARY_PATH=... in your ~/.bashrc
I have found sometimes adding -L explicitly via the CFLAGS environment variable is successful when LD_RUN_PATH was not. As in:
export CFLAGS=-L/opt/tool/lib
I'm running a command using the msbuild "Exec" task. However I do not want the stdio output generated from the command to appear in the console, is there anyway to suppress it?
Maybe something along the lines of using the Exec task to call "cmd.exe" with my command exe is a target , and then using ">" to redirect the output somewhere else. (However I'm unable to get this solution to work).
i.e.
<Exec Command="cmd.exe sqlplus.exe $(someCommandSpecificSettings) < test.txt"/>
Any suggestions to get my example to work or alternatives?
The best way to suppress Standard Output and Standard Error Output from Exec tasks or any task that inherits from ToolTask is to lower the importance of the output. That way if you're debugging your build, these output won't be completely hidden because you're redirecting them to nul.
<Exec Command="sqlplus.exe" StandardOutputImportance="low" StandardErrorImportance="low"/>
Just for your information :
( >) redirect the output to the file you specified after (overwritten if needed)
append the output to the file you specified after (not overwritten)
< redirect the standard INPUT to your command (basically pass the content of the file after to your command)
With your code, you create (once) and replace each time a test.txt file. Instead of using a filename, you can use NUL that means redirect to nowhere. This will not create the file (which could be huge in some case) :
<Exec Command="cmd.exe /c sqlplus.exe $(someCommandSpecificSettings) > NUL"/>
If you want to redirect the errors as well, you use 2> like :
<Exec Command="cmd.exe /c sqlplus.exe $(someCommandSpecificSettings) > NUL 2>errors.txt"/>
Also note that you can redirect the stderr to stdout using 2>&1, thus
> NUL 2>&1
will redirect everything to nowhere.
Hope this clarifies your mind ^^
Ok, figured it out ... cmd.exe required a /c argument to work for what I wanted i.e.:
Also, it should be > instead of <
<Exec Command="cmd.exe /c sqlplus.exe $(someCommandSpecificSettings) > test.txt"/>
Try this:
<Exec Command="cmd.exe sqlplus.exe $(someCommandSpecificSettings) < test.txt >nul"/>