Recent comments on posts in the blog:

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.

Comment by hlandau Sat Apr 7 08:21:16 2018
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.
Comment by liw.fi Mon Feb 26 19:29:49 2018
How would you modify these tips for someone using Git on Windows? You make several mentions of Debian here. Thanks much!
Comment by dave Mon Feb 26 15:09:55 2018

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.

Comment by yeti Sun Jan 28 08:31:20 2018

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.

Comment by Richard Maw Mon Nov 20 13:33:51 2017

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

Comment by riccio Sat Nov 18 10:58:40 2017
You're right, that would've been a better word choice. Thanks.
Comment by liw.fi Wed Nov 1 12:40:04 2017
Might I suggest rather than "short", you really mean that communication should be kept "brief" or "concise".
Comment by lesley.g.mitchell Wed Nov 1 12:22:00 2017

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

Comment by lesley.g.mitchell Thu Oct 26 12:43:51 2017

"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?

Comment by fa-ml Wed Oct 25 13:15:15 2017