subdirectories which are updated on today in python

I am trying to find todays updated subdirectories under directory with time later I want to send email.

 import os
 import time
 import operator
 alist={}
 now = time.time()
 directory=os.path.join("/home","radhika")
 os.chdir(directory)
for file in os.listdir("."):
     if os.path.isdir(file):
         timestamp = os.path.getmtime( file )
         # get timestamp and directory name and store to dictionary
         alist[os.path.join(os.getcwd(),file)]=timestamp

subdirectories which are updated on today in python

I am trying to find todays updated subdirectories under directory with time later I want to send email.

 import os
 import time
 import operator
 alist={}
 now = time.time()
 directory=os.path.join("/home","radhika")
 os.chdir(directory)
for file in os.listdir("."):
     if os.path.isdir(file):
         timestamp = os.path.getmtime( file )
         # get timestamp and directory name and store to dictionary
         alist[os.path.join(os.getcwd(),file)]=timestamp

How does gdb read the register values of a program / process it’s debugging? How are registers associated with a process?

I wrote a short program in c++ :

#include<iostream>
using namespace std;

    int main(){
    int x=10;
    int y=20;
    cout<< x+y <<endl;
    return 0;
    }

just out of curiosity i wanted to understand a program behind the hood so i was playing with gdb & came acrooss info registers command .when i use info registers in gdb i get output like this:

(gdb) info registers
rax            0x400756 4196182
rbx            0x0  0
rcx            0x6  6
rdx            0x7fffffffd418   140737488344088
rsi            0x7fffffffd408   140737488344072
rdi            0x1  1
rbp            0x7fffffffd320   0x7fffffffd320
rsp            0x7fffffffd320   0x7fffffffd320
r8             0x7ffff7ac1e80   140737348640384
r9             0x7ffff7dcfea0   140737351843488
r10            0x7fffffffd080   140737488343168
r11            0x7ffff773a410   140737344939024
r12            0x400660 4195936
r13            0x7fffffffd400   140737488344064
r14            0x0  0
r15            0x0  0
rip            0x40075a 0x40075a <main+4>
eflags         0x246    [ PF ZF IF ]
cs             0x33 51
ss             0x2b 43
ds             0x0  0
es             0x0  0
fs             0x0  0
gs             0x0  0

I understand these are registers and their values but what I want to know is how/why are registers associated with a process. the values of registers should be changing continuously as different processes are scheduled by the operating system? I referred to the command info registers & this is what I found but this is still confusing.

info registers -> Prints the names and values of all registers except
floating-point and vector registers (in the selected stack frame).

Why does paging let us use physical memory that is larger than what can be addressed by the CPU’s address pointer length?

I’m reading Operating System Concepts by Avi Silberschatz, in chapter 8 Main Memroy, it goes like:

Frequently, on a 32-bit CPU, each page-table entry is 4 bytes long, but that
size can vary as well. A 32-bit entry can point to one of 232 physical page frames.
If frame size is 4 KB (212), then a system with 4-byte entries can address 244 bytes
(or 16 TB) of physical memory. We should note here that the size of physical
memory in a paged memory system is different from the maximum logical size
of a process. As we further explore paging, we introduce other information that
must be kept in the page-table entries. That information reduces the number of bits available to address page frames.A 32-bit
CPU uses 32-bit addresses, meaning that a given process space can only be 232
bytes (4 GB). Therefore, paging lets us use physical memory that is larger than
what can be addressed by the CPU’s address pointer length.

I’m really confused with some concepts now.

In the first example(4KB frame size and 232 frames), since we have 32-bit frame number and 12-bit offset, is the logical address 44-bit? So what’s relationship between logical address space and the CPU’s word size?

In the second example(32-bit CPU using 32-bit addresses), how should I understand the physical memory that can be addressed by the CPU’s address pointer length? And is the CPU’s address pointer 32-bit long since CPU uses 32-bit addresses?

Running executables in parallel and consecutively using python

I have two folders. FolderA contains dozens of executables, FolderB contains an initial input file and a subsequent input file (both text files).

I would like to write a script that will do the following:

  • Create folder for each of the executables
  • Copy corresponding executable and a copy of the initial input file into this new folder
  • Run executable for this input file
  • Once process is complete, copy subsequent input file and run executable again
  • End when this second process is done

This could easily be a for loop and I could accomplish this using the os package, unfortunately I’d like to see if there is a way to run this process in parallel for all the executables, or some strategic number of executables at a given iteration.

I’ve never done parallel processing before and I also have no idea how it can be accomplished for such a two-step execution process. Any help would be most appreciated. Thanks.

How to create a standalone java OS? [on hold]

Hii I am creating my java OS but how can it be standalone as java requires JVM that converts it’s byte code to Windows exec code but in case of standalone how to use jvm and in what code now jvm has to convert the byte code as now the Windows is not present here can I use Linux kernel yes then how? or I have to use any other thing?

reading file while it is being written

Ok. This is weird. I started with an empty file called foo.txt and in a python3 interpreter, wrote the following code:

>>> import time
>>> f = open('foo.txt', 'r')
>>> while True:
...     print(f.readlines())
...     f.seek(0)
...     time.sleep(5)
... 

and I started seeing output like this:

[]
0
[]
0

So far, so good. Then I opened another window, and ran the following:

echo "line number 1" >> foo.txt

and my output changed to:

['line number 1\n']
0

Now in the other window, I opened file via vim and added one new line such that final state of the file looked like this (I closed vim after that)

line number 1
line number 2

Strangely enough, I was still seeing the “previous” output in the interpreter

['line number 1\n']
0
['line number 1\n']
0

I expected to see two lines in the interpreter now, but that was not the case. For some reason, writing file via echo was behaving differently from writing file via vim.

At that point, I decided to see whether the file descriptor in python is still pointing to the original file.

>>> print(f.name)
foo.txt

Confused, I decided to check lsof output

$ lsof | grep foo.txt
python3.6 .... foo.txt~

Ah ha! The tilde at the end meant that the open fd is actually now pointing to something else. Running the same experiment on ubuntu (the above was on MacOS), lsof had an interesting output

$ lsof | grep foo.txt
python3.6 .... temp.txt~ (deleted)

So, when the file was opened in vim, operating system (?) at that point decided to create a copy of the file for the already opened fd. (But didn’t do this when I edited the file via echo)

Does anyone know why this happens only for vim, and not for echo?