[Excellent work and comprehensive. I've being doing portable dev for years (actually since DOS)]

A closely related issues is writing npm scripts that are portable. Often a little care goes a long way but there are limitations and that might causeyou to reach for somehting like shx. Or just use Makefiles :)

I'll dig up an old post it did and link it here.

Aside: even though process.hrtime() returns nanoseconds, the actual resolution is usually much coarser. On Linux, for example, it's usually no better than 100 ns (0.1 us) and often much worse. I wouldn't single out Windows.

I've noticed the readme says:

On the other hand the birthtime and birthtimeMs values are undefined on Unix.

Assuming that you were talking about unix-y systems and not exactly Unix I can't reproduce this on both macOS and Lubuntu:

So I'm not sure what to take of that. Has this been "fixed" in more recent versions of node? Does it only happen on some specific filesystems? Are you actually talking about the Unix here?

Thanks!

Great project!

Which problem is this pull request solving?

Since at the end of every other section there is a link to the following "chapter", I thought I could add a link in the last page of the "System" chapter (Time) to the "Terminal" chapter.

Let me know if it was wanted, or it just slipped by. 😃

I also noticed that the "Terminal" chapter index page has the "Previous" link to the last page of the File System chapter. Do you want me to fix it as well?

Checklist

Please add a x inside each checkbox:

• [x] I have read the contribution guidelines.

Which problem is this pull request solving?

Some points regarding Windows are erroneous.

This was reported by @ayra on Reddit.

Please note few points inside that Reddit comments have not been added because:

• the guide already mentions them:
  • Newlines in Windows are always CRLF, never just LF.
  • CTRL+Z does end streams in Windows but only in text mode, not when reading in binary mode.
• while this works on Windows, this does not lead to the best cross-platform behavior:
  • While you should avoid common device names as file/directory names in Windows (COM1,COM2,etc.) you can use them normally using the long file name syntax \\?\
  • No reason to avoid uppercase characters on Windows.
• others:
  • TCP servers can listen on a file descriptor in Windows and If you mean an internal socket by "File descriptor" this is done via anonymous or named pipes in Windows.: see note at end of https://nodejs.org/api/net.html#net_server_listen_handle_backlog_callback

Checklist

Please add a x inside each checkbox:

• [x] I have read the contribution guidelines.
• [x] The status checks are successful (continuous integration). Those can be seen below.

WSL is now a very usable option on Windows, though is still slow. However I beelive we should still write for cmd / PS portability.

BTW I use Git for Windows bash as my main shell and it works a treat for me. It's based on the old MSYS / MinGW system which I always prefered to Cygwin (actually might use MSYS2) However npm always launches cmd for child shells so you still need portable npm scripts. :(

As listed in the Windows file naming conventions (as linked from the original document), aux is also a reserved file name. This change makes the list of reserved names the same as the source.

Bumps prismjs from 1.20.0 to 1.21.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

🎉 Thanks for sending this pull request! 🎉

• [x] I have read the contribution guidelines.

See:

• bcoe/awesome-cross-platform-nodejs#32
• bcoe/awesome-cross-platform-nodejs#36

Awesome work!

Here's some of my proposal

• For encoding converting: https://www.npmjs.com/package/buffer-encoding
• For encryption on sqlite: https://www.npmjs.com/package/cross-sqlcipher

The README currently says this:

only use process.on(signal) with the following signals: [..] SIGILL, [..] SIGFPE, SIGSEGV

The docs however strongly recommend against listening for those signals:

   * `'SIGBUS'`, `'SIGFPE'`, `'SIGSEGV'` and `'SIGILL'`, when not raised
   artificially using kill(2), inherently leave the process in a state from
   which it is not safe to attempt to call JS listeners. Doing so might lead to
   the process hanging in an endless loop, since listeners attached using
   `process.on()` are called asynchronously and therefore unable to correct the
   underlying problem.