These should maybe go in an issue instead?

Not sure why we're using a .scm file extension, extra unknowns tend to distract from the learning objectives.
Might be clearer to use a file extension that people are familiar with.

My suggestion would be to change the file exension to .txt.

It would be good to have solutions somewhere for all the tasks on this workshop (and a finished version of the project as well).

I can add a folder with solutions for most of the tasks except for the piping task as I can't figure out how to do it...

Shall I add a folder with example solutions and can anyone help with a solution for the piping task and the project? (@bradreeder @eliasCodes @jsms90 )

As I was going through the lesson, the way these were named was slightly confusing. I've suggested renaming to path_to_read_file and path_to_write_file

In examples, it is often written e.g.

cat index.html > example.js

which doesn't work as written, as these files are within the public folder. Not a big deal but just trying to make it a bit clearer, so suggesting changing to e.g.

cat public/index.html > public/example.js

To make this more like the nodeschool workshops this is inspired by, it might be an idea to add tests that verify if a student's solution is correct.

Make this into a tutorial that runs on the terminal screen like nodeschool tutorials.

If you want to see a detailed break-down on this at any point go into my notes on the white-board session under week5 of your notes repo. It's not necessary to go into that much depth to do these exercises, the syntax you need is provided, just in case it helps clarify any questions from yesterday.

This is a reference to the time in FAC9 when I originally delivered this workshop. I should go through the files to modify any historic references so as to not confuse new users using this workshop.

I think adding how to create an npm module is a good round-off to this workshop. We should probably add a cautionary note about publishing modules to npm willy nilly, however.

Go into the public folder and try this:

node path_to_your_cat.js public/index.html > public/example.js

There are a few examples like this where the file paths aren't correct. (If you're in the public folder you only need to write out index.html or example.js.)

The plan is to use the project as a topic for research afternoon to replace code coverage

Option 2 chosen by @bradreeder

Follow same format as other repos

Author: @bradreeder
Maintainer: @bradreeder

Workshop begins here

No instructions to clone repo

since there isn't a solution branch in this repo, could I and @mrm7moud make one and push our solution to it? @eliasCodes?

Formerly in the notes that were at the end of lesson1.md #5

**To be continued: more options, recursives, wildcards, redirections, pipes, publishing your new found wizardry on npm, storing your environment variables using shell commands...**

redirections & pipes are covered in lesson2.md and I believe publishing modules to npm is in the project.md.

Unsure why this file ended up getting stored here but it's not providing any extra value and should be removed to avoid confusion.

Hint: try doing this just with fs first and see what happens. You're going to need a specific core module in order to access the whole line of a file as you're reading it.

I remember when I delivered this that someone solved the task without using the module referenced here. I will update this hint to the point to the existence of this module rather than imply it's necessary.

In the project, the thing they are being asked to build is described as a test-runner. It's actually a TAP output formatter. tape is still the thing actually running the tests.

I would suggest that we replace references to 'test-runner' with "TAP output formatter", or alternatively "test output formatter" if you don't feel like explaining what TAP is (which would be fair enough).