Strangely, it appeared to do nothing at all when I specified the directory.

On Unix systems, at least, directories can be fopen()ed just like files, and they contain binary content. It sounds like perhaps yours started with a NUL byte which ended the "sql" the shell thought it was reading. That's actually correct behavior, but the shell could arguably check whether it's a directory before opening it. (The same thing bit me in another piece of software a few years ago.)

On Unix systems, at least, directories can be fopen()ed just like files, and they contain binary content.

Not sure what does POSIX specify about this, but trying to fread() (but not fopen()!) a directory on GNU/Linux results in an error:

#include <errno.h>
#include <stdio.h>
#include <string.h>

char buf[256];

int main() {
	int e;
	size_t i;

	FILE * f = fopen(".", "r");
	printf("%p\n", f);
	if (!f) return -1;

	i = fread(buf, 1, sizeof buf, f);
	e = errno;
	printf("%llu %d %s\n", (unsigned long long)i, e, strerror(e));

	fclose(f);
	return 0;
}

0x55b11dfd7010
0 21 Is a directory

Those are the C library interfaces. Try the POSIX ones, without the leading “f”. I assume the Unix VFS uses the latter.

Those are the C library interfaces. Try the POSIX ones, without the leading “f”. I assume the Unix VFS uses the latter.

open() and read() do the same on my system (Mint Linux 20):

#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main() {
	int e;
	size_t i;
  char buf[256];
	int fd = open(".", O_RDONLY);
	printf("%d\n", fd);
	if (!fd<0) return -1;

	i = (ssize_t) read(fd, buf, sizeof(buf));
	e = errno;
	printf("%llu %d %s\n", (unsigned long long)i, e, strerror(e));

	close(fd);
	return 0;
}

Output:

3
18446744073709551615 21 Is a directory

Whether or not that's a standard behaviour, i don't know. It was a good 5 or 6 years ago that i had a piece of software simply open/fopen and read/fread a directory handle - perhaps that was specific to those C libs. No man pages i've found make any mention of it being an error to open/fopen a directory.

IEEE fopen() lists only one error case which sounds relevant:

[EISDIR]
    [CX] [Option Start] The named file is a directory and mode requires write access.

strongly implying that opening a directory is acceptable in read-only mode.

Edit: in any case, the opening is succeeding, both with open() and fopen(), but the reading, both with read() and fread(), on my current system. This StackOverflow answer says that the ability to read() a directory entry existed historically but was eventually removed.

Edit: IBM's z/OS docs say that fread() returns 0 when used to read a directory, which differs from how Linux does it. Insofar as i can determine, this capability lives in the realm of implementation-defined behaviour.

/shrugs shoulders

On both tests there is a directory 'test' and a file 'test.sql'.

Windows:

D:\TEMP>sqlite3 test.db
SQLite version 3.32.3 2020-06-18 14:00:33
Enter ".help" for usage hints.
sqlite> .read test
Error: cannot open "test"
sqlite> .q

Linux (WSL):

/mnt/d/TEMP$ sqlite3 test.db
SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> .read test
sqlite> .q

It could be the difference in versions, but it's different.

IMHO reading a directory as SQL doesn't make sense, even if it were technically possible. It would be good style to warn the user about this with an error message. W. Oertl

Historically I recall observing the same thing, that you could even cat a directory and get garbage printed to your terminal. However I think it was widely regarded as a misfeature and there's generally been a move towards the read syscall itself returning EISDIR as noted elsewhere in the thread. I've just tested linux (3.10.0-693.5.2.el7) and OpenBSD (6.4) and they both display this behaviour.

OSX (Darwin kernel 19.5.0) reports "Operation not supported" trying to cat a directory but I'm not sure how to check the syscalls here.

Indeed, and error message seems to be missing on Linux.

For info, the bottom of this post on the Fossil forum is possibly the "same sort of thing"... reading a directory as though it were a normal file.