I want to log every error on building code.
so I can use -k to make it keep-going even error happened.
However, could I know some error has happened,
and it is -k to make it continue?
I know I can check some pattern error message like make: ***.
But I still wondering if I can have some message in log like:
"error happened, keep-going to make" when I have -k.
Thanks.
make reports errors on its output/error for human readers. Other computer programs can check its exit status, which should be non-zero if any error has occurred. If you're calling make from a shell script, you could do something similar to
make -k || echo "BAD: ERROR(S)"
except change echo to something that's actually useful for you. Other ways to call make will have similar options.
Related
I'm using bash for writing a script.
I use set -ein order to have the script exit (in error) when a line results in an error (i like this approach, that I find less error prone). I almost always combine it with set -u for also "raising" an error when it is attempted to read an undefined variable.
It has worked like a charm since a long time. But today, I found a bug in my script that I could not catch with "set -eu" before, because this does not seem to raise an error like usual.
For the following, I will use the false command that always returns an error (in my script this is another personnal command, but this makes it easier for you to reproduce).
set -eu
A=$(false)
The code above exits bash with an error. Cool this is what I expect.
BUT :
set -eu
export A=$(false)
does not raise any error, bash is totally fine with it !
It even sets the variable A with an empty string, so further reads of $A will not raise an error either !
This is really weird for me, is there a way of getting the expected behaviour, maybe another option for ```set`` ?
I can do this for having it raise an error, but I will have to write it this way every time, so it is less useful for catching bugs :
set -eu
A=$(false)
export A=$A
God bash is complicated :-)
You're not getting an error because the export itself is successful. I can't find explicit documentation of the behavior, but command substitution when building the arguments to another command seems to be one of the special cases where a non-zero exit status doesn't make set -e trigger.
I have been receiving Shell error messages, typically due to a bad command, etc., but have been unable to debug the cause of these messages due to not understanding the information being provided.
I have been looking for documentation, but have been unable to find any regarding the format of an sh error message.
Example:
If I use the following command, it will fail, due to no 'ipconfig' command being available:
$ sh -c "ipconfig"
sh: 1: ipconfig: not found
What I'd like to understand is what each 'field' in that message pertains to? I assume it is:
[interpreter]: [???]: [command]: [error related to command]
I can't for the life of me determine what the number refers to, and I can't be sure if my understanding of the other fields is accurate.
Context:
I am debugging a Python2.7 pytest script used for automation testing, and there are numerous points where this script is executing shell commands. However, the output I receive is:
(32512, 'sh: 2: 2: not found')
I know that function being used to execute the shell script returns a tuple with status code and output. I know that that status code is essentially 'command not found', and the error message is also stating that. Another function is returning a string which is used for this command, and I assume what is happening is that somewhere along the way, a bad argument must have been passed and now the script is attempting to execute, what would basically be sh -c "2". I can't be sure though, as these are a lot of assumptions I'm making from a limited understanding of this error message.
If anyone could please enlighten me as to what the fields in this error ACTUALLY mean I'd be forever grateful!!
If I want to run a command that may or may not work, depending on the situation, I add a dash
make-rule:
-command that may fail
however, when this command fails, I get a message that the entire recipe failed.
How do I flag the command as totally optional, such that even if it fails, make just notes that it failed, but not that the over-all recipe failed?
(this saves time having to carefully read the make messages, if I don't get informed that the entire recipe failed)
It's a bit manual, but you can use an or-sequence in the recipe, as in:
make-rule:
command that may fail || echo "command failed with status $$?"
since echo will succeed, make will consider that the whole line is OK, but you still get your error message in case of problem.
Working in bash I got an error:
user#host:~$ cd ..
bash: cd: write error: Success
It happend once, and next time I tried to cd everything went fine. But I do not want this error to repeat, so I have 2 questions about this error:
Why bash tried to write something while changing dir?
And more intriguing - why Success could be an error?
Why bash tried to write something while changing dir?
Bash keeps a history of every command you run, which ultimately gets recorded in ~/.bash_history. It's likely that the attempted write was related to that.
And more intriguing - why Success could be an error?
That's a display bug. Success is not an error.
If you want the developer take on how it happens, I'm pretty confident in saying that:
bash detected an error, probably via the return code of an I/O function, and
it called the C perror() function to print an explanatory message. By the time it did so, however,
the C errno variable had been reset, if ever it had been set in the first place.
Usually such a reset of errno happens when you call another library function between calling the one that signaled the error and calling perror(). Looking at the actual error message, it is plausible that the bash implementation called sprintf() to format part of the error message, but in doing so clobbered errno.
I am executing a command in terminal which is
cvlc song.amr
Problem is though the song is being played, I am getting some message after I am executing the instruction. The message is
VLC media player 1.1.9 The Luggage (revision exported)
Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS")
Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE")
[0x85de7cc] dummy interface: using the dummy interface module...
Can anyone tell me how to stop this message from coming.
Like in gcc, when we don't want warning message to come, we instruct it by giving an option as
cc -w program.c
Is there anyway, by which I can stop that message from coming. Or is it that solving that problem is the only way to stop it from coming. How to solve it then. Or else can I save those messages in some other file and stop it from coming in terminal, like how we do with this '>' redirection operator in terminal for storing the output somewhere else.
Please help me.
Thanks in advance.
does this work? cvlc song.amr &> /dev/null? otherwise command line options like what you suggest are program specific and i dunno abt cvlc's options, maybe u can try cvlc -h and see if it has a silent mode