London | 26-Jul-SDC | Roman Sanaye | Sprint 3 | Implement Shell Tools

[RomanSanaye]

Self checklist

• I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
• My changes meet the requirements of the task
• I have tested my changes
• My changes follow the style guide

Changelist

Implemented shell tools using Node.js.

Changes include:

• Implemented my own version of the wc command
• Added functionality to count:
  • Lines
  • Words
  • Characters
• Added support for processing multiple text files
• Used Node.js fs module to read and process files
• Tested the implementation with sample files and compared results with the original wc command

Questions

No questions at the moment.

Task ID: CYF-1150

[SlideGauge]

Hi Roman - solid grasp of the fundamentals here: your file reading and line/word/char counting all work, and the "total" loop in wc is nicely done. One structural thing is worth stepping back on, though, because it shapes the whole task. Right now there are ~17 scripts - roughly one per example command line - each with the flag and file path hard-coded inside it. When you run the real wc -l sample-files/3.txt, how does wc know both the flag and the file? Take a look at process.argv when you run node wc.js -l sample-files/3.txt - if your script read the flag and filename from there, how many of the README's command lines could a single wc.js handle?

My point is that once the arguments come in rather than being baked into each file, your 17 scripts collapse into three - one cat.js, one ls.js, one wc.js - each acting on whatever it's given. That's really the heart of the task. Could you have a go at rebuilding around argument handling and re-running each README command line against the real tool? Once that's in place I'll do a closer pass on the smaller details. The underlying skills are clearly there - keep going.

The result of the work should be three scripts: a single cat.js, a single ls.js and a single wc.js accepting command line parameters in the same manner as their real counterparts do.

[RomanSanaye]

Hi Roman - solid grasp of the fundamentals here: your file reading and line/word/char counting all work, and the "total" loop in wc is nicely done. One structural thing is worth stepping back on, though, because it shapes the whole task. Right now there are ~17 scripts - roughly one per example command line - each with the flag and file path hard-coded inside it. When you run the real wc -l sample-files/3.txt, how does wc know both the flag and the file? Take a look at process.argv when you run node wc.js -l sample-files/3.txt - if your script read the flag and filename from there, how many of the README's command lines could a single wc.js handle?

My point is that once the arguments come in rather than being baked into each file, your 17 scripts collapse into three - one cat.js, one ls.js, one wc.js - each acting on whatever it's given. That's really the heart of the task. Could you have a go at rebuilding around argument handling and re-running each README command line against the real tool? Once that's in place I'll do a closer pass on the smaller details. The underlying skills are clearly there - keep going.

The result of the work should be three scripts: a single cat.js, a single ls.js and a single wc.js accepting command line parameters in the same manner as their real counterparts do.

Hi, @SlideGauge thank you for the helpful feedback and guidance. I understand now that the main goal was not to create separate scripts for each command, but to use process.argv to handle flags and file paths dynamically.

I have started refactoring the project into three tools only: cat.js, ls.js, and wc.js, with each one accepting command-line arguments like the real shell commands.

Thanks again for pointing me in the right direction — it helped me understand the structure of the task much better.

[SlideGauge]

Great job, review complete!