@All Thanks a lot,
Yes "set -e" It work fine. This is what I am looking for but I got some
extra things to learn :) .
Thanks you again
Thanks
Jitendra
On Thu, Jul 24, 2014 at 6:10 PM, Wolfgang Maier <
wolfgang.ma...@biologie.uni-freiburg.de> wrote:
> On 24.07.2014 14:37, Chris “Kwpolska” Warr
On 24.07.2014 14:37, Chris “Kwpolska” Warrick wrote:
It’s recommended to switch to the [[ syntax anyways, some people
consider [ deprecated. Also, [ is actually /bin/[ while [[ lives in
your shell (and is therefore faster).
About the equals sign, == is the preferred syntax, and = is also
consi
On Thu, Jul 24, 2014 at 2:23 PM, Wolfgang Maier
wrote:
> On 24.07.2014 14:19, Chris “Kwpolska” Warrick wrote:
>>
>>
> python test.py
> if [ $? = 0 ]; then
> python second.py
> fi
>
> as your shell script.
The [ ] and = should be doubled.
>>>
>>>
>>
On 24.07.2014 14:19, Chris “Kwpolska” Warrick wrote:
python test.py
if [ $? = 0 ]; then
python second.py
fi
as your shell script.
The [ ] and = should be doubled.
?? why that ?
Double brackets can do more:
http://stackoverflow.com/questions/2188199/how-to-use-double-or-single-br
On Thu, Jul 24, 2014 at 2:14 PM, Wolfgang Maier
wrote:
> On 24.07.2014 14:09, Chris “Kwpolska” Warrick wrote:
>>
>> On Thu, Jul 24, 2014 at 2:01 PM, Wolfgang Maier
>> wrote:
>>>
>>> Try something like this (assuming bash):
>>>
>>> python test.py
>>> if [ $? = 0 ]; then
>>> python second.py
>
On 24.07.2014 14:09, Chris “Kwpolska” Warrick wrote:
On Thu, Jul 24, 2014 at 2:01 PM, Wolfgang Maier
wrote:
Try something like this (assuming bash):
python test.py
if [ $? = 0 ]; then
python second.py
fi
as your shell script.
The [ ] and = should be doubled.
?? why that ?
But all th
On Thu, Jul 24, 2014 at 2:01 PM, Wolfgang Maier
wrote:
> Try something like this (assuming bash):
>
> python test.py
> if [ $? = 0 ]; then
> python second.py
> fi
>
> as your shell script.
The [ ] and = should be doubled. But all this is not needed, all you need is:
python test.py && python
On Thu, Jul 24, 2014 at 05:05:24PM +0530, jitendra gupta wrote:
> Hi All
>
> My shell script is not throwing any error when I am having some error in
> Python code.
This is a question about the shell, not about Python. I'm not an expert
on shell scripting, but I'll try to give an answer.
> ~~
On 24.07.2014 13:35, jitendra gupta wrote:
Hi All
My shell script is not throwing any error when I am having some error
in Python code.
test.py ~~
def main():
print "Test"
#some case error need to be thrown
raise Exception("Here is error")
if __name__ == "__main__"
On Thu, Jul 24, 2014 at 1:35 PM, jitendra gupta wrote:
> Hi All
>
> My shell script is not throwing any error when I am having some error in
> Python code.
>
> In this case, I dont want to run my second.py
> Even I am throwing error from my test.py, but still second.py is getting
> executed, whic
Hi All
My shell script is not throwing any error when I am having some error in
Python code.
test.py ~~
def main():
print "Test"
#some case error need to be thrown
raise Exception("Here is error")
if __name__ == "__main__"
main()
~~
second.py ~~
def
On Sun, Mar 25, 2012 at 12:54 PM, Michael Lewis wrote:
> In the below block, why is the if statement e.errno != errno.EEXIST?
> Why can the errno be both before and after the "."?
>
>
>
> import os, errno
> try:
> os.makedirs('a/b/c')
> except OSError, e:
> if e.errno != errno.EEXIST:
>
In the below block, why is the if statement e.errno != errno.EEXIST?
Why can the errno be both before and after the "."?
import os, errno
try:
os.makedirs('a/b/c')
except OSError, e:
if e.errno != errno.EEXIST:
raise
--
Michael J. Lewis
mjole...@gmail.com
415.815.7257
On 25/03/2012 08:22, Russel Winder wrote:
Michael,
On Sat, 2012-03-24 at 15:20 -0700, Michael Lewis wrote:
[...]
It is perhaps worth noting that in Python 3, the syntax has changed:
import os, errno
try:
os.makedirs('a/b/c')
except OSError, e:
except OSError as e :
if e.errno
Michael,
On Sat, 2012-03-24 at 15:20 -0700, Michael Lewis wrote:
[...]
It is perhaps worth noting that in Python 3, the syntax has changed:
> import os, errno
> try:
>
> os.makedirs('a/b/c')
> except OSError, e:
except OSError as e :
>
> if e.errno != errno.EEXIST:
>
> raise
That is because 'errno' is a property on the exception object called 'e',
not the other way around.
On Sun, Mar 25, 2012 at 7:12 AM, Michael Lewis wrote:
>
>
> On Sat, Mar 24, 2012 at 3:51 PM, Colton Myers wrote:
>
>> I am having a bit of trouble understanding what is going on below. What
>> do
On Sat, Mar 24, 2012 at 3:51 PM, Colton Myers wrote:
> I am having a bit of trouble understanding what is going on below. What
> does the "e" in "except OSError, e:" do?
> Any other help you can provide regarding errno would be extremely
> appreciated. I've done help() and dir() on it, but I am n
> I am having a bit of trouble understanding what is going on below. What does
> the "e" in "except OSError, e:" do?
> Any other help you can provide regarding errno would be extremely
> appreciated. I've done help() and dir() on it, but I am not really
> understanding what's going on with "e.e
Hi everyone,
I am having a bit of trouble understanding what is going on below. What
does the "e" in "except OSError, e:" do?
Any other help you can provide regarding errno would be extremely
appreciated. I've done help() and dir() on it, but I am not really
understanding what's going on with "e.e
Our configuration language has evolved a bit more over the last few
days and I've decided to right a recursive descent parser for it.
Since this is a learning project for me, I'm writing the parser myself
instead of using one of the available packages. I'll see how this
affects the error handling.
Yes I am aware of the various Python parser packages. But at the
current moment the language is changing so I'm just writing a parser
as I go along. It probably isn't very good as it combines syntactical
analysis with some calculations as it goes along (which isn't really
good practice). Once the
Shrutarshi Basu wrote:
the front end of the program is essentially a parser for a moderately complex configuration language, which means that there are a variety of syntax/semantics errors possible.
In my experience with parsers there is little or no need for try-except
blocks. Could you give us
"Shrutarshi Basu" <[EMAIL PROTECTED]> wrote
I'm currently working on a research project where we'll be
developing
a moderately complex piece of software. We're designing with
extensibility in mind. One of the problems I can see right now is
that
our program can potentially create a large numb
I'm currently working on a research project where we'll be developing
a moderately complex piece of software. We're designing with
extensibility in mind. One of the problems I can see right now is that
our program can potentially create a large number of very different
errors, some fatal, some not.
24 matches
Mail list logo
