I run command like this:
./cppcheck file.cpp --inline-suppr --enable=all --error-exitcode=13 \
--quiet --suppress=missingInclude:* --suppress=unusedFunction:* --inconclusive
There is nothing in stdout, but:
echo $?
13
At the same time, if I check other files, cppcheck writes nothing into stdout and returns 0:
echo $?
0
How can I understand, what is "wrong" with file.cpp?
My cppcheck version (with problem) is 1.82.
I haven't found exact problem (simple sample of code that reproduces the problem), but I have tried last version ('Cppcheck 1.87 dev' at the moment) and now the problem is solved (for me).
So, If you have same problem - try to upgrade cppcheck.
I don't know how general this answer is, but maybe somebody might find it useful.
I got the same behavior in a third-party library header I had included with -I: cppcheck did not show the warning, but did count it for the exit code. Including it with -isystem instead made the problem go away.
Related
I need to get different SFTP exit codes for each error. For instance 'no such file or directory' --> exit code=552 or 550 instead of returning 1.
I've tried the following and it did not work:
//A05FTP EXEC PROC=SFTPROC,COND=(0,NE)
//COPSFTP.MYSTDIN DD *
host="xpto.xpty.xptz"
lzopts mode=text
cd /home/apl/files/unl
ls
a=`ls | wc -l`
echo `$a`
echo $?
QUIT
//*
and the output in spool is:
cozsftp> lzopts mode=text
mode=text
cozsftp> lzopts mode=text
mode=text
cozsftp> cd /home/apl/files/unl
Ý09.807¨ Invalid command.
cozsftp> a= 1
CoZBatchÝI¨: returning rc=exitcode=1
Can anyone help me?
COZBATCH allows you to embed shell scripts into JCL, so you don't need to use BPXBATCH. BPXBATCH really is a poor utility. If you're using Co:Z then good for you it rocks.
If you want to run shell commands you need to use the ! escape character.
!echo $a
FWIW, SFTP always returns 1 on error. I'm not sure if you can change that. Errors should be logged in the sysout.
Your problem may simply be the echo `$a`. Try enclosing with quotes instead of tick marks.
More generally, if you want to do more detailed error checking, instead of using the SFTP procedure (SFTPROC), I think you'd do better to write yourself a simple script that you execute with BPXBATCH. The script would issue the same SFTP commands, but you could capture and redirect the output (STDOUT/STDERR) and based on the return value ($?) and any error messages, you could certainly detect all the unusual conditions you might want.
I am getting the following error running make:
Makefile:168: *** missing separator. Stop.
What is causing this?
As indicated in the online manual, the most common cause for that error is that lines are indented with spaces when make expects tab characters.
Correct
target:
\tcmd
where \t is TAB (U+0009)
Wrong
target:
....cmd
where each . represents a SPACE (U+0020).
Just for grins, and in case somebody else runs into a similar error:
I got the infamous "missing separator" error because I had invoked a rule defining a function as
($eval $(call function,args))
rather than
$(eval $(call function,args))
i.e. ($ rather than $(.
This is a syntax error in your Makefile. It's quite hard to be more specific than that, without seeing the file itself, or relevant portion(s) thereof.
For me, the problem was that I had some end-of-line # ... comments embedded within a define ... endef multi-line variable definition. Removing the comments made the problem go away.
My error was on a variable declaration line with a multi-line extension. I have a trailing space after the "\" which made that an invalid line continuation.
MY_VAR = \
val1 \ <-- 0x20 there caused the error.
val2
In my case, I was actually missing a tab in between ifeq and the command on the next line. No spaces were there to begin with.
ifeq ($(wildcard $DIR_FILE), )
cd $FOLDER; cp -f $DIR_FILE.tpl $DIR_FILE.xs;
endif
Should have been:
ifeq ($(wildcard $DIR_FILE), )
<tab>cd $FOLDER; cp -f $DIR_FILE.tpl $DIR_FILE.xs;
endif
Note the <tab> is an actual tab character
In my case error caused next. I've tried to execute commands globally i.e outside of any target.
UPD. To run command globally one must be properly formed. For example command
ln -sf ../../user/curl/$SRC_NAME ./$SRC_NAME
would become:
$(shell ln -sf ../../user/curl/$(SRC_NAME) ./$(SRC_NAME))
In my case, this error was caused by the lack of a mere space. I had this if block in my makefile:
if($(METHOD),opt)
CFLAGS=
endif
which should have been:
if ($(METHOD),opt)
CFLAGS=
endif
with a space after if.
In my case, the same error was caused because colon: was missing at end as in staging.deploy:. So note that it can be easy syntax mistake.
I had the missing separator file in Makefiles generated by qmake. I was porting Qt code to a different platform. I didn't have QMAKESPEC nor MAKE set. Here's the link I found the answer:
https://forum.qt.io/topic/3783/missing-separator-error-in-makefile/5
Just to add yet another reason this can show up:
$(eval VALUE)
is not valid and will produce a "missing separator" error.
$(eval IDENTIFIER=VALUE)
is acceptable. This sort of error showed up for me when I had an macro defined with define and tried to do
define SOME_MACRO
... some expression ...
endef
VAR=$(eval $(call SOME_MACRO,arg))
where the macro did not evaluate to an assignment.
I had this because I had no colon after PHONY
Not this,
.PHONY install
install:
install -m0755 bin/ytdl-clean /usr/local/bin
But this (notice the colon)
.PHONY: install
...
Following Makefile code worked:
obj-m = hello.o
all:
$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
So apparently, all I needed was the "build-essential" package, then to run autoconf first, which made the Makefile.pre.in, then the ./configure then the make which works perfectly...
I just made the switch to Zsh, but I'm facing a weird problem with it: every time I hit the tab key, the prompt goes up a line, thus eating what was above.
In order to demonstrate the problem more clearly, I created a GIF:
I'm using a custom theme and Oh My Zsh. You can find the theme here: http://pastebin.com/12dZtZf3.
EDIT: The problem seems to reside in my theme, as using other themes solves the problem.
EDIT: The culprit seems to be in the function that prints the row of dashes and the date above the prompt:
_professional_prompt_header() {
echo -n "$bg[grey]"
for i in {0..$(( $(tput cols) / 2 - 6 ))}; do
echo -n "--"
done
# Uncommenting this line fixes the problem.
# Tried echo without -n and print, but no success.
echo -n " %*$reset_color"
}
This has also emerged as an issue with multiline prompts in the release of zsh 5.3. As of 2017-01-13, a patch has not been released. A discussion and explanation can be found in this prezto issue.
More discussion of the offending zsh issue itself can be found here.
Hopefully a fix will emerge from the zsh project. If not, some workarounds mentioned on that github repo are to make your PROMPT variable only a single line, outputting any other lines in the precmd function. This seems like a pain, however, so until it is fixed (or decided to be a "feature"), the easiest fix sounds like it is to roll back to zsh 5.2.
make is halting and reporting an error code of 12 after attempting to zip -u some files.
The error code 12 is actually an exit status from zip which indicates that it has "nothing to do."
I don't understand why this is a non-zero exit status. Wouldn't it be more appropriate to just let zip quietly do nothing? It doesn't seem like an actual problem if zip has nothing to do.
I could suppress it: tell make to ignore non-zero exit status from zip by calling -zip -u. But the problem with that approach is that 12 is the only exit status I want to ignore. All of the others indicate actual problems that would cause me to want to abort make.
Maybe I could set a variable equal to the output from echo $? and then test for 0 or 12 but it seems klodgy to do this after every single zip statement in the .mk file.
Is there an elegant way to handle this?
Err... As a quick and dirty solution, you can use a shell wrapper:
#!/bin/ksh
zip "$#"
rc=$?
if [[ rc -eq 12 ]]; then
exit 0
fi
exit $rc
Alternatively, you can do almost the same inline in Makefile but it will look somewhat ugly (will have to be a shell one-liner with duplicate $ signs etc.)
Something like this sounds simpler to me.
It returns an error in make if the error code is non-zero and different of 12.
target:
zip -uj file.zip file.csv || [ $$? -eq 12 ]
When running a CMake generated Makefile with multiple processes (make -jN), the output often gets messed up like this:
[ 8%] [ 8%] [ 9%] Building CXX object App/CMakeFiles/App.dir/src/File1.cpp.o
Building CXX object App/CMakeFiles/App.dir/src/File2.cpp.o
Building CXX object App/CMakeFiles/App.dir/src/File3.cpp.o
I'm not sure, but I think this behavior is also there for Makefiles not generated by CMake. I'd say it happens when multiple processes write to stdout at the same time.
I know I'm probably being pedantic, but is there any (simple) fix to this? ;)
If you're using GNU make, you can do it by redefining SHELL such that commands are wrapped by a trivial utility that ensures atomicity of information printed to standard output. Here's a more detailed description, including sample source for the wrapper utility.
I tried to get the CMake people to fix this, but apparently they don't want to. See http://www.cmake.org/Bug/view.php?id=7062.
The specific CMake bug related to interleaved make output using -jN with N>1 is CMake bug 0012991: "Parallel build output mess". It is still open in the "backlog" state waiting to be fixed.
This bug is actually annoying enough that it's a strong reason to switch to Ninja instead of make. Plus the fact that Ninja is faster than make. Ninja also uses an appropriate number of parallel jobs based on the number of CPU cores present. Also cool is how Ninja is, by default, very quiet: all progress happens on a single line in the terminal unless the build process emits messages or a build step fails. If a build step fails, Ninja prints the full command line that invoked it and displays the output. It's really nice since it makes any warning or error messages stand out. Although currently there is no colored terminal output: that would be a nice improvement but for me the advantages of Ninja over make are tremendous.
Looks like it is already fixed. Add a -Oline parameter to the command line:
make -j 8 -Oline
Version of make:
GNU Make 4.3
Built for x86_64-pc-msys
Sun's (now Oracle's) dmake available on Linux and Solaris takes care of that.
See here and there.
Here is a simple working example of using a wrapper for Make. I'm not sure if I'd encourage it's use, but it's an idea.
# Makefile
SHELL = /tmp/test/wrapper
test: test1 test2
test1:
$(eval export TARGET=$#)
env
test2:
$(eval export TARGET=$#)
env
and this:
#!/usr/bin/env bash
# wrapper
bash $# | sed -e "s/^/${TARGET} /"