HowTo_AccessRaw SectorsOfPhysical Drives_onLinux.py
-
I hate to submit Python code ...... but this is really bad.
link
for physicalDriveID in ['a','b','c','d','e','f','g','h']:
drive = '/dev/hd%s'%(physicalDriveID,)
try:
fileLikeAccessToContentOfSectorsOfHardDrive0 = open(drive, 'rb')
hardDriveSector0_theMBR = fileLikeAccessToContentOfSectorsOfHardDrive0.read(512)
fileLikeAccessToContentOfSectorsOfHardDrive0.close()
byteCounter = 0
lstHexDumpOfMBR = []
for byte in hardDriveSector0_theMBR:
byteCounter += 1
lstHexDumpOfMBR.append((' %02x'%(ord(byte),)).upper())
if byteCounter % 16 == 0:
lstHexDumpOfMBR.append('\n')
#:if
#:for
strHexDumpOfMBR = ''.join(lstHexDumpOfMBR)
print
print 'HexDumpOfMBR of %s \n'%drive + strHexDumpOfMBR
fileOut.write('\nHexDumpOfMBR of %s \n' % drive + strHexDumpOfMBR)
noOfPhysicalDrives += 1
for logicalDriveNo in range(1,10):
try:
drive = '/dev/hd%s%s'%(physicalDriveID, logicalDriveNo)
fileLikeAccessToSectorsOfDriveX = open(drive, 'rb')
bootRecordDriveX = fileLikeAccessToSectorsOfDriveX.read(512)
fileLikeAccessToSectorsOfDriveX.close()
byteCounter = 0
lstHexDumpOfBootRecord = []
for byte in bootRecordDriveX:
byteCounter += 1
lstHexDumpOfBootRecord.append((' %02x'%(ord(byte),)).upper())
if byteCounter % 16 == 0:
lstHexDumpOfBootRecord.append('\n')
#:if
#:for
strHexDumpOfBootRecord = ''.join(lstHexDumpOfBootRecord)
print
print 'HexDumpOfBootRecord of LogicalDrive %s%s: \n'%(driveDescr,) + strHexDumpOfBootRecord
fileOut.write('\nHexDumpOfBootRecord of LogicalDrive %s: \n'%(physicalDriveID,logicalDriveNo) + strHexDumpOfBootRecord)
except:
pass
print
print r"""open(r'\.%s:', 'rb') failed"""%(driveLetter,)
#:try/except
except:
print
print r"""open(r'%s', 'rb') failed""" % drive
blnAccessToPhysicalDriveFailed = True
break
#:try/except
#:while
-
Re: HowTo_AccessRawSectorsOfPhysicalDrives_onLinux.py
That's incredible, in the sense of 'not credible. I'm sure it's real,
but.... lstHexDumpOfBootRecord? strHexDumpOfBootRecord? Last I checked,
python doesn't need type warts,
andCapitalizingThingsLikeThisThatAreMoreThanTwoWordsInLengthIsUgly,
like Java style but without the purpose...
It's one thing for code to be written in Python, it's another entirely for code to be written like Python.
-
@Spigot said:
That's incredible, in the sense of 'not credible. I'm sure it's real, but.... lstHexDumpOfBootRecord? strHexDumpOfBootRecord? Last I checked, python doesn't *need* type warts, andCapitalizingThingsLikeThisThatAreMoreThanTwoWordsInLengthIsUgly, like Java style but without the purpose...
It's one thing for code to be written in Python, it's another entirely for code to be written like Python.People who bitch about the naming/capitalizing convention are morons and bad coders.
If you don't have nothing to add, shut up.
-
@Spigot said:
That's incredible, in the sense of 'not credible. I'm sure it's real, but.... lstHexDumpOfBootRecord? strHexDumpOfBootRecord? Last I checked, python doesn't *need* type warts, andCapitalizingThingsLikeThisThatAreMoreThanTwoWordsInLengthIsUgly, like Java style but without the purpose...
It's one thing for code to be written in Python, it's another entirely for code to be written like Python.The 'type warts' actually make sense in this particular case, because first he has a list, then he converts it to a string, but both have the same information. I'm a little surprised you actually noticed the 'type warts' in those huge variable names. Apart from that, no language needs type warts, whereas some programmers do.
-
Re: HowTo_AccessRawSectorsOfPhysicalDrives_onLinux.py
Identifiers are supposed to be descriptive, but this is rediculous. I haven't used Python before but I sure hope good Python code is easier to understand than this.
-
Of course, most people think Python code is very readable, although some find it cryptic because of some language constructs like lambda functions and list comprehensions.
Still, this is not bad code, if you change names like "<FONT face="Courier New">fileLikeAccessToContentOfSectorsOfHardDrive0</FONT>" to "<FONT face="Courier New">fd</FONT>" or "<FONT face="Courier New">disk</FONT>" something. And then put a comment above the assignment to fd:
<FONT face="Courier New"># File-like access to content of sectors of hard drive 0</FONT>
-
@Savior said:
@Spigot said:
That's incredible, in the
sense of 'not credible. I'm sure it's real, but....
lstHexDumpOfBootRecord? strHexDumpOfBootRecord? Last I checked, python
doesn't need type warts,
andCapitalizingThingsLikeThisThatAreMoreThanTwoWordsInLengthIsUgly,
like Java style but without the purpose...
It's one thing for code to be written in Python, it's another entirely for code to be written like Python.People who bitch about the naming/capitalizing convention are morons and bad coders.
If you don't have nothing to add, shut up.I'm sorry but he's right, putting full fucking phrases in camelCase is stupid and unreadable, as this example proves
He didn't bitch about camelCase itself, he bitched about a damn misuse of it, how can you create variables names of 44 characters length for chrissake?
And for the code, well it's just plain ugly, without even mentioning those damn "this is an end of block" comment (god, if you can't even notice the dedent just get an indent of 4 spaces just like everyone)
Other stupid things:
- except with a break of while, if you're going to get out of the loop anyway, just put the try/except OUTSIDE of it
- Non-specified exception catcher, equivalent to
on error resume next
if not worse - this guy even nests unspecified try/except blocks...
- except: pass; print; print("whatever")... god, if you're printing shit you're not passing in the first place
- empty prints for newlines...
Unreadable, butt-ugly code for the win, i guess
-
Re: HowTo_AccessRawSectorsOfPhysicalDrives_onLinux.py
Just goes to show you can write fortran in any language.
Hope you don't have more than 8 physical harddrives on your system, nor
more than 10 partitions on the drive. I know of systems
where those are not safe assumptions. I've seen over 50
different harddrives in a Unix system before (the system was created
before RAID was thought of, today we would of course use RAID of some
sort to make it look like one drive). I've also seen more
than 10 partitions on a disk before. (/ /usr /var /tmp /usr/local
/home are common on small systems, and it is easy to come up with more)
I think there are Unix systems where harddrives can be of a pattern of
other than /dev/hd*, but I can't recall any now. This code
doesn't handle that, though I would want it to.
This code is clearly Unix specific, so not using os.path to create the
drive path string is excusable, but still a mistake.
However not using the rest of the os module to list /dev and figure out
what is really on the system is a WTF.
Those variable names are too long. Variable names should be
long enough to make their purpose clear and no
longer. I leave you a lot of room to decide who long
a variable should be, but this is too much. It took me a
while to understand this code because I was trying to read too much
into the varaible. (If you need a name that long it must be
something really complex)
The prints could be moved into the loop, thus saving the need for the
list. Shorter code is more readable (In general, there are
large exceptions), and in this case also faster.
The excepts assume that it was the open that failed. Likely true, but something else could be wrong.
Reading the link, this code is a biffer WTF: it is linux
specific. Unix specific could be excused, afterall Windows
is different in many critical ways, such that trying to make this
portable to Windows would be hard. However Unix is in
general enough alike that you should go through the effort to make your
stuff portable to the rest where you can.
All of this would be excusable if the auther just did something quick
for use on his own system. However this code was a posted
example, and thus demands more care.
-
For the windows version, see here. So
-
... So THAT'S how you write platform-independent Python code!
-
By the way, didn't Fortran have the blessing of 8-character variable names?
-
@joost said:
By the way, didn't Fortran have the blessing of 8-character variable names?
It was actually 6 letters up to and including Fortran77, and lines no longer than 72 characters (the first 8 where used for something specific i think)
Not only that, but the actual type was originally specified by the first letter of the variable name is not specified, variables beginning with I to N were Integers, others were Real (spawning the very funny "GOD is REAL (unless declared INTEGER)" which only works in Fortran)
-
@joost said:
For the windows version, see here. So
I find it saddest that it never occured to the guy to do an OS check and use either unix or windows hardware path names. Otherwise they're functionally identical. (It's not surprising that even the user interface half is just as butt ugly as the system code.)try:
Mask: I just realized that's where the For I = 1 to ... tradition came from. Man, I feel stupid now. And don't forget those line numbers.
retValFromSubprocessCall = subprocess.call(
strCurrentShellCommand
, shell=True
)
print ' %s'%(strCurrentShellCommand,)
except OSError:
print
print " !EXIT! in '%s' "%(strTHIS_fileName,)
print " Can't execute:"
print " " + strCurrentShellCommand
print
raw_input('\n EXIT with RETURN \> ')
sys.exit(2)
#:except OSError
So which is worse, 50-character variable names or a stone-age 2-character throwback to BASICA programmer?
-
@hank miller said:
I think there are Unix systems where harddrives can be of a pattern of
other than /dev/hd*, but I can't recall any now.
You mean, like... SCSI harddisks? Quite common, actually. ESPECIALLY on Unix.
-
@hank miller said:
I think there are Unix systems where harddrives can be of a pattern of
other than /dev/hd*, but I can't recall any now. This code
doesn't handle that, though I would want it to.On NetBSD, it's sd0a, sd0b, ..., for the partitions on sd0, and you get sdN for SCSI/SCSI-like and wdN for ATAPI. On Mac OS X, it's disk0 or disk0s1 for a partition.
Which is to say, I've never seen it be "hda1" on anything but Linux. But then, the code seems intended to be Linux-only.
-
He should really have made a function that creates a list of disks and
a list of partitions for each disk, depending on OS. And then a
function to read the first 512 bytes from a file-like object, and a
function for converting a list of bytes to a hex dump. Computers should
explode with great violence and wipe out the neighbourhood when programmers use copy+paste. That would really teach people about code reuse.
As to the question of 50-char versus 2-char var names, the perpetrator
of this code probably has a Fortran trauma (see his wiki space); that might explain his morbid preference for variable names that are longer than the
expressions that assign to them.
Link (as if) to perpetrator's wiki page