is there a nohup-command which repeat the task if there is a traceback?
I work with python scripts, and if there is an error, I receive this "ERROR Traceback (most recent call last):" (+ additional information). So, at the moment, I reenter the commands for all the files I receive a traceback manually. But if there exists a command which reenter the command automatically, in case of a traceback, I really would appreciate this :)
Thanks a lot.
Read the section on handling exceptions in the python documentation, and this should guide you on how to catch them, and if approriate, re-run.
Related
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!!
So I was trying to download somevideos using rtmpdump, and I used this shell script which is supposed to download the some videos but it gave me and error message saying
./script: line 9: $1: ambiguous redirect
Now I am pretty sure that I am doing something silly so I will tell you exactly what I did. I first downloaded that above file into my system saved it as "script". And opened terminal and typed:
./script
and it gave me the above error.
Now I have also gone through this thread, and also some other threads but they don't seem help me at all and now I have nowhere to go. please save me.
script tries to use $1 as the name of a file for redirection (e.g., someCommand > "$1"), but you didn't supply a an argument when you called script.
The script needs a file as the first parameter which will have one video to download per line
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'd like to create a dummy script (with the prospect of writing a real life script) that invokes for example the Python interactive interpreter from within a Scala process and lets the user fully interact with the subprocess; i.e. the stdin/stdout/stderr of the child process should be connected to those of the parent (Scala) process. I've tried using the following to no avail:
#!/usr/bin/env scala -savecompiled
import sys.process._
stringToProcess("python").run(BasicIO.standard(connectInput = true)).exitValue
however, while it does seem to successfully run a python subprocess, the only interaction I get to have with it is Ctrl-C:
~$ ./scalashelltest.scala
foo
^CTraceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyboardInterrupt
If press Ctrl-C immediately, I don't even get that output:
~$ ./scalashelltest.scala
^C~$
Any idea why this is happening and how to make it work as expected?
You aren't giving python a (pseudo-)tty. You are just giving it stdin (and possibly stdout).
So python is operating in a non-interactive mode.
Running python with the -i flag will force it to use prompts even without a tty but the more correct fix is likely to find a scala/java library which can create a (pseudo-)tty and run an application in it.
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