Birmingham | 2026-MAR-SDC | Joy Opachavalit | Sprint 3 | Implement shell tools#408
Birmingham | 2026-MAR-SDC | Joy Opachavalit | Sprint 3 | Implement shell tools#408enjoy15 wants to merge 4 commits intoCodeYourFuture:mainfrom
Conversation
illicitonion
left a comment
There was a problem hiding this comment.
Generally looking good, but it looks like you're slightly over-fitting to the examples in the README.md - give some thought to other command lines a user may try to run, and how your implementations may be surprising to them.
implement-shell-tools/cat/cat.js
Outdated
| let lineNumber = 1; | ||
|
|
||
| files.forEach((file) => { | ||
| const filePath = path.resolve(file); |
There was a problem hiding this comment.
What is this line doing? What would break if you removed it and just used file instead of filePath?
There was a problem hiding this comment.
I have removed the unnecessary use of path.resolve and now directly use file. The code works as expected without it, simplifying the implementation.
implement-shell-tools/cat/cat.js
Outdated
| if (options.numberNonEmpty && line.trim()) { | ||
| console.log(`${lineNumber}\t${line}`); | ||
| lineNumber++; | ||
| } else if (options.numberLines) { | ||
| console.log(`${lineNumber}\t${line}`); | ||
| lineNumber++; | ||
| } else { | ||
| console.log(line); |
There was a problem hiding this comment.
The three branches here look quite similar and repetitive. In general, if you have multiple similar branches, it's more clear to extract the differences into variables, and then run the same code, i.e. so you'd only have one call to console.log which looks more like console.log(`${prefix}${line}\n`) where prefix may be set differently based on options (including potentially an empty string).
This way it's easier for someone reading the code to see what's the same / different in each case, and also avoids the hazard that someone updates one of the branches but forgets to update the other ones.
There was a problem hiding this comment.
I have refactored the code to reduce repetition. Now, the differences are handled using a prefix variable, and there is only one console.log statement. This makes the code cleaner and easier to maintain.
implement-shell-tools/cat/cat.js
Outdated
| } | ||
| }); | ||
| } catch (err) { | ||
| console.error(`cat: ${file}: No such file or directory`); |
There was a problem hiding this comment.
What exit code will your program have if something went wrong? What exit code should it have?
There was a problem hiding this comment.
I have added proper exit codes. The program now exits with process.exit(1) when an error occurs, ensuring it signals failure appropriately.
implement-shell-tools/cat/cat.js
Outdated
| } | ||
| }); | ||
| } catch (err) { | ||
| console.error(`cat: ${file}: No such file or directory`); |
There was a problem hiding this comment.
Are you sure the problem here is that the file didn't exist? What would happen e.g. if you didn't have permission to read the file?
In general specific error messages are good, but misleadingly specific error messages are a problem - if we're not sure what went wrong (or if we have more information about what went wrong), we should present that information, rather than guessing. And if we are guessing, we should make it clear we're not sure what the problem exactly was and that this is a guess.
There was a problem hiding this comment.
I have improved the error handling to differentiate between file-not-found (ENOENT) and permission errors (EACCES). The error messages now provide more accurate information about what went wrong.
| if (arg === '-l') { | ||
| options.lines = true; | ||
| } else if (arg === '-w') { | ||
| options.words = true; | ||
| } else if (arg === '-c') { | ||
| options.bytes = true; | ||
| } else { | ||
| files.push(arg); | ||
| } |
There was a problem hiding this comment.
What happens if someone specifies more than one of these flags? What should happen?
Given the test cases we gave you in the README file, it's ok if your implementation doesn't do the same thing as the real wc does, though that would be ideal, but in general ignoring user input is bad - so if someone asks for both -l and -c and you ignore one of them, that can be confusing. Either showing both, or giving an error, is probably preferable.
There was a problem hiding this comment.
I have updated the code to handle multiple flags. If multiple flags are specified, the program now displays all the requested results together, ensuring user input is respected.
implement-shell-tools/wc/wc.js
Outdated
| } | ||
|
|
||
| files.forEach((file) => { | ||
| const filePath = path.resolve(file); |
There was a problem hiding this comment.
Again, why do you need the path.resolve here?
There was a problem hiding this comment.
I have removed the unnecessary use of path.resolve and now directly use the file path provided by the user. This simplifies the code without affecting functionality.
implement-shell-tools/ls/ls.js
Outdated
| } else if (arg === '-a') { | ||
| options.all = true; | ||
| } else { | ||
| directories = [arg]; |
There was a problem hiding this comment.
This meets the requirements for the examples listed in the README.md, but feels like it risks being confusing to users. If someone specified ls /some/path /some/other/path what do you think they would expect to happen? What does your code actually do? (See also the comment about wc options for a similar question)
There was a problem hiding this comment.
I have updated the code to handle multiple directories. The program now lists files for all specified directories, making it more intuitive for users.
Learners, PR Template
Self checklist
Changelist
Completed all exercises