implement netcat operating mode #1222
|
@ -66,6 +66,7 @@ from network.downloadthread import DownloadThread
|
|||
import helper_bootstrap
|
||||
import helper_generic
|
||||
import helper_threading
|
||||
import std_io # for STDIO modes
|
||||
|
||||
|
||||
def connectToStream(streamNumber):
|
||||
|
@ -205,8 +206,8 @@ class Main:
|
|||
|
||||
try:
|
||||
opts, args = getopt.getopt(
|
||||
sys.argv[1:], "hcdt",
|
||||
["help", "curses", "daemon", "test"])
|
||||
sys.argv[1:], "hcdtn",
|
||||
["help", "curses", "daemon", "test", "mode-netcat"])
|
||||
|
||||
except getopt.GetoptError:
|
||||
self.usage()
|
||||
|
@ -224,6 +225,14 @@ class Main:
|
|||
elif opt in ("-t", "--test"):
|
||||
state.testmode = daemon = True
|
||||
state.enableGUI = False # run without a UI
|
||||
elif opt in ("-n", "--mode-netcat"):
|
||||
# STDIO MODES - reconfigure threads for netcat mode
|
||||
state.enableNetwork = True # enable networking
|
||||
state.enableObjProc = False # disable object processing
|
||||
state.enableGUI = False # headless
|
||||
state.enableSTDIO = True # enable STDIO
|
||||
# STDIN to invQueue, STDOUT from objectProcessorQueue
|
||||
std_io.stdInputMode = 'netcat'
|
||||
|
||||
# is the application already running? If yes then exit.
|
||||
shared.thisapp = singleinstance("", daemon)
|
||||
|
@ -263,7 +272,12 @@ class Main:
|
|||
sqlLookup.start()
|
||||
|
||||
Inventory() # init
|
||||
Dandelion() # init, needs to be early because other thread may access it early
|
||||
|
||||
# start network components if networking is enabled
|
||||
if state.enableNetwork:
|
||||
Dandelion() # init, needs to be early because other thread may access it early
|
||||
else:
|
||||
state.dandelion = 0
|
||||
|
||||
# Enable object processor and SMTP only if objproc enabled
|
||||
if state.enableObjProc:
|
||||
|
@ -283,6 +297,12 @@ class Main:
|
|||
objectProcessorThread.daemon = False # DON'T close the main program even the thread remains. This thread checks the shutdown variable after processing each object.
|
||||
objectProcessorThread.start()
|
||||
|
||||
elif state.enableSTDIO and std_io.stdInputMode == 'netcat':
|
||||
# Start the thread that outputs objects to stdout in netcat mode
|
||||
objectStdOutThread = std_io.objectStdOut()
|
||||
objectStdOutThread.daemon = False # same as objectProcessorThread
|
||||
objectStdOutThread.start()
|
||||
|
||||
# Start the cleanerThread
|
||||
singleCleanerThread = singleCleaner()
|
||||
singleCleanerThread.daemon = True # close the main program even if there are threads left
|
||||
|
@ -309,6 +329,12 @@ class Main:
|
|||
singleAPIThread.daemon = True # close the main program even if there are threads left
|
||||
singleAPIThread.start()
|
||||
|
||||
# STDIO MODES - Start the STDIN thread
|
||||
if state.enableSTDIO:
|
||||
stdinThread = std_io.stdInput(sys.stdin)
|
||||
stdinThread.daemon = True
|
||||
stdinThread.start()
|
||||
|
||||
# start network components if networking is enabled
|
||||
if state.enableNetwork:
|
||||
BMConnectionPool()
|
||||
|
@ -440,7 +466,10 @@ Options:
|
|||
-h, --help show this help message and exit
|
||||
-c, --curses use curses (text mode) interface
|
||||
-d, --daemon run in daemon (background) mode
|
||||
|
||||
Advanced modes:
|
||||
-t, --test dryrun, make testing
|
||||
-n, --mode-netcat no GUI, read and write raw objects on STDIO
|
||||
|
||||
All parameters are optional.
|
||||
'''
|
||||
|
|
167
src/std_io.py
Normal file
|
@ -0,0 +1,167 @@
|
|||
|
||||
"""
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
STDIO handling threads for netcat and airgap modes
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
stdInput thread: receives hex-encoded bitmessage objects on STDIN
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
Supported input formats, format is auto-detected:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
- each line a hex-encoded object
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
- each line formatted: hex_timestamp - tab - hex-encoded_object
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
(the output format of netcat mode)
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
objectStdOut thread: replaces the objectProcessor thread in netcat mode,
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
outputs to STDOUT in format: hex_timestamp - tab - hex-encoded_object
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
"""
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
import threading
|
||||
PEP8 validation missing here PEP8 validation missing here
Maintain a order all the imports should be first. Maintain a order all the imports should be first.
from statements should be written after import statements.
why can't we use why can't we use
if not line or if not line.strip() ?
done done
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
import time
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
import protocol
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
import queues
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
import state
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
import shutdown
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
import shared # statusIconColor
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
from struct import unpack
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
from binascii import hexlify, unhexlify
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
from addresses import decodeVarint, calculateInventoryHash
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
from debug import logger
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
from inventory import Inventory
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
from helper_sql import sqlQuery, sqlExecute, SqlBulkExecute
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
stdInputMode = 'netcat' # process STDIN in netcat mode by default
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
netcatExitOnEOF = True # exit program if EOF on STDIN
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
class stdInput(threading.Thread):
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
"""
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
Standard Input thread reads objects from STDIN, posts them to Inventory
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
"""
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
def __init__(self, inputSrc):
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
threading.Thread.__init__(self, name="stdInput")
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
self.inputSrc = inputSrc
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
logger.info('stdInput thread started.')
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
def run(self):
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
Please write a method with only 15 or 20 lines. Please write a method with only 15 or 20 lines.
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
No. Go big or go home :) No. Go big or go home :)
Over longer term, I would also prefer to have shorter methods, some parts of the old code, like the class_objectProcessor are too long, but for this PR it's fine the way it is. Over longer term, I would also prefer to have shorter methods, some parts of the old code, like the class_objectProcessor are too long, but for this PR it's fine the way it is.
Noted with thanks. I think the ad-hoc object parsing accounts for a lot of avoidable LLOC wastage, however, as discussed in PR #1149 , there was no readily usable parser function to use instead. Noted with thanks. I think the ad-hoc object parsing accounts for a lot of avoidable LLOC wastage, however, as discussed in PR #1149 , there was no readily usable parser function to use instead.
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
while True:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# read a line in hex encoding
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
line = self.inputSrc.readline()
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if not line:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
logger.info("STDIN: End of input")
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if netcatExitOnEOF:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
shutdown.doCleanShutdown()
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
break
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
hexObject = line.rstrip()
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
hexTStamp = ''
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# detect timestamp-tab-object format (as output by netcat mode)
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if "\t" in hexObject:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
hexTStamp = hexObject.split("\t")[0]
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
hexObject = hexObject.split("\t")[-1]
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# unhex the input with error rejection
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
try:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
binObject = unhexlify(hexObject)
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
except TypeError: # fix codacy warning
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
logger.info("STDIN: Invalid input format")
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
continue
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# sanity check on object size
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if len(binObject) < 22:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
logger.info("STDIN: Invalid object size")
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
continue
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if not state.enableNetwork and state.enableGUI:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
You set You set `state.enableGUI = False` above. Will this conditional ever be reached?
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
state.enableGUI is only false in netcat mode; std_io may have other uses outside of netcat mode, which are not currently included. Yes, the conditional makes sense from a logical perspective. state.enableGUI is only false in netcat mode; std_io may have other uses outside of netcat mode, which are not currently included. Yes, the conditional makes sense from a logical perspective.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# in airgap mode, trick the status icon that we are in fact
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# NOT waiting for a connection
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# (may be removed after impact analysis)
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
shared.statusIconColor = 'yellow'
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if stdInputMode == 'airgap':
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# airgap mode uses the timestamp
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# unhex the timestamp with error rejection
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if len(hexTStamp) == 16:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
try:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# stdioStamp, = unpack('>Q', unhexlify(hexTStamp))
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
_, = unpack('>Q', unhexlify(hexTStamp))
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
except (struct.error, TypeError): # fix codacy warning
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
logger.info("STDIN: Invalid timestamp format: " + hexTStamp)
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
continue
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# check that proof of work is sufficient.
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if not protocol.isProofOfWorkSufficient(binObject):
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
logger.info('STDIN: Insufficient Proof of Work')
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
continue
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# extract expiry time, object type
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
eTime, = unpack('>Q', binObject[8:16])
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
objectType, = unpack('>I', binObject[16:20])
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# extract version number and stream number
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
readPosition = 20 # bypass the nonce, time, and object type
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# versionNumber, versionLength
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
_, versionLength = decodeVarint(binObject[readPosition:readPosition + 10])
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
readPosition += versionLength
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
streamNumber, streamNumberLength = decodeVarint(binObject[readPosition:readPosition + 10])
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
readPosition += streamNumberLength
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# calculate inventory hash
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
inventoryHash = calculateInventoryHash(binObject)
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# duplicate check on inventory hash (both netcat and airgap)
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if inventoryHash in Inventory():
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
logger.debug("STDIN: Already got object " + hexlify(inventoryHash))
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
continue
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# in netcat mode, push object to inventory and id to output queue
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if stdInputMode == 'netcat':
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
Inventory()[inventoryHash] = (objectType, streamNumber, binObject, eTime, '')
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
logger.debug("STDIN: Accepted object (type=%u) " % objectType + hexlify(inventoryHash))
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
queues.invQueue.put((streamNumber, inventoryHash))
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# honour global shutdown flag
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if state.shutdown != 0:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
logger.info('stdInput thread shutdown.')
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
break
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
class objectStdOut(threading.Thread):
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
"""
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
The objectStdOut thread receives network objects from the receiveDataThreads.
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
"""
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
def __init__(self):
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
Follow Pep8 styling format. Follow Pep8 styling format.
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
done done
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
threading.Thread.__init__(self, name="objectStdOut")
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# REFACTOR THIS with objectProcessor into objectProcessorQueue
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
queryreturn = sqlQuery(
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
'''SELECT objecttype, data FROM objectprocessorqueue''')
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
for row in queryreturn:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
By waiting until we have synchronously pulled all objects from the database and put all objects on the queue we are missing out on some benefits of parallelism and we'll hit a memory limit with large data sets. Maybe this is unavoidable or related to your suggested refactoring. Also, keeping the number of places where raw SQL is used to a minimum is a good idea. Again, I assume this would be part of your suggested refactoring. By waiting until we have synchronously pulled all objects from the database and put all objects on the queue we are missing out on some benefits of parallelism and we'll hit a memory limit with large data sets. Maybe this is unavoidable or related to your suggested refactoring.
Also, keeping the number of places where raw SQL is used to a minimum is a good idea. Again, I assume this would be part of your suggested refactoring.
The block marked by The block marked by `refactor ... /refactor` is duplicated verbatim from class `objectProcessor`; the comment indicates my intention to refactor it into class `objectProcessorQueue`, a task which is outside the scope of this PR.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
objectType, data = row
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
queues.objectProcessorQueue.put((objectType, data))
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
sqlExecute('''DELETE FROM objectprocessorqueue''')
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
logger.debug('Loaded %s objects from disk into the objectProcessorQueue.' % str(len(queryreturn)))
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
Pep8 styling missing Pep8 styling missing
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
done done
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# /REFACTOR THIS
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
def run(self):
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
while True:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
When the queue is empty would this not cause unnecessary 100% CPU? Perhaps a small sleep is needed inside the while loop? Edit: no it wouldn't, Queue.get(block=True) blocks when the queue is empty. I was thinking of the AMQP library I was most recently using. When the queue is empty would this not cause unnecessary 100% CPU? Perhaps a small sleep is needed inside the while loop?
Edit: no it wouldn't, Queue.get(block=True) blocks when the queue is empty. I was thinking of the AMQP library I was most recently using.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
objectType, data = queues.objectProcessorQueue.get()
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# Output in documented format
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
print "%016x" % int(time.time()) + '\t' + hexlify(data)
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
Should we use sys.stdout.write() instead of print here? Should we use sys.stdout.write() instead of print here?
It would be indeed the logical choice, I'm just not sure how cross-platform it would be. Print is 100% portable and not wrong. It would be indeed the logical choice, I'm just not sure how cross-platform it would be. Print is 100% portable and _not wrong_.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
if state.shutdown:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
time.sleep(.5) # Wait just a moment for most of the connections to close
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# REFACTOR THIS with objectProcessor into objectProcessorQueue
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
numberOfObjectsInObjProcQueue = 0
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
with SqlBulkExecute() as sql:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
while queues.objectProcessorQueue.curSize > 0:
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
objectType, data = queues.objectProcessorQueue.get()
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
sql.execute('''INSERT INTO objectprocessorqueue VALUES (?,?)''',
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
objectType, data)
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
numberOfObjectsInObjProcQueue += 1
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
logger.debug('Saved %s objects from the objectProcessorQueue to disk. objectProcessorThread exiting.' %
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
str(numberOfObjectsInObjProcQueue))
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
# /REFACTOR THIS
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
Yes please! Yes please!
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
state.shutdown = 2
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
||||
break
|
||||
PEP8 validation missing here PEP8 validation missing here
why can't we use why can't we use
if not line or if not line.strip() ?
done done
"if not line" - can't strip an EOF :) "if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except. According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify. Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know. Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246
|
PEP8 validation missing here
PEP8 validation missing here
why can't we use
if not line or if not line.strip() ?
why can't we use
if not line or if not line.strip() ?
done
done
"if not line" - can't strip an EOF :)
"if not line" - can't strip an EOF :)
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not
logger.info
pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.EDIT - Done: #1246
You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not
logger.info
pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.EDIT - Done: #1246