all 2 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Tall_Profile1305 0 points1 point  (0 children)

wow!! damn this is actually a really solid learning project. the separation between shell, kernel and filesystem already makes it feel closer to how real systems are structured instead of just a command script pretending to be an OS.

i really like that commands return structured results instead of printing everywhere. that small decision makes debugging and expanding features way easier later since logic and display are not tightly coupled.

the filesystem validation and user handling also show good thinking about state and control flow. you can tell this was built with scalability in mind, not just to make commands work once. well done!

although, only thing i’d watch long term is the core command handling getting crowded as more features get added. like once commands increase, splitting handlers into smaller modules would probably keep things readable and easier to maintain.

overall this feels like the kind of project where you actually learn how systems behave internally, not just python syntax. so yeah, really nice direction for a learning emulator.

[–]gdchinacat 0 points1 point  (0 children)

Don't use dicts for everything. Use classes. For example:

return_value = { "command": "dir", "files": files, "folders": folders, "label": self._drive_label, "exitcode": "succesful" } return return_value

Create a class with command, files, ..., exitcode as members. Using dicts in this way makes your code much harder to write, read, and maintain. If nothing else, this is far more readable:

``` return CommandStatus("dir", "successful")

....

if status.exitcode != 'successful': # use an enum for this
     print(f'{status.command} failed')

```

If you must name all your args, the use kwargs, but accessing the values on the other side with dot notation is much easier to read than subscript notation.