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: 
    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
    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.

    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


Log in to reply