Some things to add:

• On MacOS 9 the path component separator was :. Falsehood: The path component separator is always / or .

• You should add a list of all the reserved characters on Windows, as well as the COM*, etc. already listed. From https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#:

  < (less than)

  (greater than) : (colon) " (double quote) / (forward slash) \ (backslash) | (vertical bar or pipe) ? (question mark) * (asterisk)

• Falsehood: Windows UNC paths \FOO refer to a network server. Counterpoint: \.\COM1.

• Falsehood: Absolute Windows paths always begin with DRIVELETTER:. Counterpoint: \?\C:\Foo. This is the long path support, the \?\ prefix is used to indicate the application can support long paths.
• Falsehood: Windows UNC paths begin with \SERVERNAME. Counterpoint: \?\UNC\SERVERNAME. \?\UNC\ is the long path UNC prefix.
• Falsehood: A subdirectory of a directory is on the same physical storage on Windows. Counterpoint: Drives can be mounted at arbitrary directories, not just at drive letters.
• Falsehood: Barring symlinks and hardlinks, a file has only one path which can access it. Counterpoint: File paths can contain redundancies like /./, leading to an arbitrary number of strings accessing the same file.
• Falsehood: Barring symlinks and hardlinks and with paths normalised to remove redundancies, a file has only one path which can access it. Counterpoint: The same filesystem can appear at different mountpoints on *nix using bind mounts. On Windows, junctions can be used, which function similarly to directory symlinks, but which are not symlinks and which are substantially more transparent.
• Falsehood: If a Windows path has a drive letter, it must be an absolute path. Counterpoint: C:foo.txt (or C:bar\foo.txt or C:..\bar\foo.txt) is relative to the current working directory which was last set for C:, which may be different to the current working directory for the current drive letter.
• Falsehood: Barring symlinks or hardlinks, a file has only one name. Counterpoint: Short names on Windows. C:\LongFilename.txt is reduced to C:\LongFi~1.txt for legacy access.
• Falsehood: A short name will always end in ~1.EXT. Counterpoint: If C:\LongFilenameX.txt and C:\LongFilenameY.txt both exist, one will be C:\LongFi~1.txt and one will be C:\LongFi~2.txt. Which is which is indeterminate.
• Falsehood: Opening a path successfully means you've opened a file. Counterpoint: Directories (and sockets, and so on) can be opened on *nix. On Windows, alternate file streams are addressed with the colon, which are subcomponents of files.
• Falsehood: A file only has one stream of data associated with it. Counterpoint: Windows has alternate file streams. MacOS has resource forks.
• Falsehood: A filesystem supports filenames longer than 8+3 characters. Counterpoint: DOS is limited to 8 characters before the file extension and 3 after.
• Falsehood: If you write to a file with provided normalised path X and then delete normalised path Y, where Y != X, X will still exist. Counterpoint: On Windows, if X is an alternate file stream path (C:\Foo.txt:sub1), and Y is the file path (C:\Foo.txt), deleting Y will delete X. Also if Y != X is a case sensitive comparison and the filesystem is case insensitive.
• Falsehood: The types of objects which can appear on a filesystem is limited to files and directories. Counterpoint: Windows has files (including hardlinks), directories, symlinks, junctions. *nix has files (including hardlinks), directories, symlinks, sockets, FIFOs, character devices, block devices. Some *nixes may have other object types, like Solaris doors.
• Falsehood: A platform provides or doesn't provide mandatory locking. Counterpoint: Windows does and it is used by default. Linux doesn't provide mandatory file locking.
• Falsehood: A filesystem mounted on *nix is always case sensitive. Counterpoint: Linux can mount FAT32, NTFS, etc.
• Falsehood: A filesystem mounted on Windows is always case insensitive. Counterpoint: Windows can be configured to make its filesystems case sensitive.
• Falsehood: The separators between multiple directory components are the same as that used to separate the directory components and the filename. Counterpoint: OpenVMS paths look like this: SYS$SYSDEVICE:[DIR1.DIR2.DIR3]FILENAME.EXT;FILEVER.

Feel free to use the above.

I wouldn't modify these tips for Windows, since I don't ever use Windows, and haven't ever used Windows for professional software development. I am completely ignorant of how anything works in Windows. Sorry.

How would you modify these tips for someone using Git on Windows? You make several mentions of Debian here. Thanks much!

Your example starts screen with a script containing screen -t irssi irssi.

This script is not really a config file like the ones you would use via screen's -c configfilename option.

script's "real" config files can contain commands which would be not recognised by your way of doing it.

Your way is starting screen -t ... in an already running outer screen what makes the inner screen recognise running in screen and therefore delegating its commands to the outer screen.

Thanks for your comment.

Yes it's missing content because of a formatting error in the source (there should be an empty line before the code block). The output that it was supposed to have is:

$ awk <testdata '{ split($0, A, /->/); print A[2] }'
b

I'll get it fixed.

Hi, thanks for this great blog!

Regarding the cut example: the last line says "For this more complicated tools need to be used. $ awk /); print A[2] }' b", I think something is missing. Regarding the sort/uniq paragraph: the option I find more useful of uniq is "-c" for counting occourrences.

Thank you again, Riccardo

You're right, that would've been a better word choice. Thanks.

Might I suggest rather than "short", you really mean that communication should be kept "brief" or "concise".

Computer/Programming/Information Ethics is a whole discipline in itself, though it is certainly a topic that every programmer really ought have some grounding in.

The Wikipedia page on the topic - https://en.wikipedia.org/wiki/Programming_ethics - is a good place to start for more general information and some ideas about what to consider.

For a more philosophical exploration of the topic, the Stanford Encyclopedia of Philosophy has some good articles, such as: https://plato.stanford.edu/entries/ethics-computer/ and https://plato.stanford.edu/entries/computing-responsibility/

There are also a whole range of books on the topic both from computing perspectives and more philosophical ones.

The Open University also offers a free course on the subject, Introducing Ethics in Information and Computer Sciences

"Does it promote $BADTHINGS, directly or indirectly?"

Slippery surface, as one can easily put GPG/TOR/GNUNet (and loosely following your example, R) in that $BADTHINGS basket.
A medical professional cures people regardless, a lawyer defends their client regardless: is a Free Software contributor more equipped to indulge in this deontological Pandora's box?