Bsrgvty

Several objects in /dev are pseudo-devices and are handled directly by kernel functions. The more frequently used ones are:

• 
  /dev/null: the universal sink of infinite capacity. Used to discard output: try echo foo >/dev/null. Reading from it returns an empty stream of bytes (immediate EOF).


• 
  /dev/zero: an infinite source of 0x00 bytes. Often used as input to overwrite things with 0s.


• 
  /dev/random, /dev/urandom: infinite sources of random bytes.

Indeed none of the other answers seem to actually answer the question of why hx refuses to work with /dev/null. The reason why hx reacts this way is simply that it was programmed to output this error message for device files.

From https://github.com/krpors/hx/blob/develop/editor.c#L125:

if (!S_ISREG(statbuf.st_mode)) {
 fprintf(stderr, "File '%s' is not a regular filen", filename);
 exit(1);

That means that hx specifically refuses to work on anything that isn't a regular file. I don't think there is a very good reason for this check - without it, I would expect that /dev/null would work with hx, in the sense that hx would read an empty file, and any updates to it would be lost when saving them.

(This assumes that https://github.com/krpors/hx/ is really the hx programm the poster talks about)

/dev/null is basically a way to discard information.

The main purpose is simply to be able to redirect things into oblivion.

echo 'duck' > /dev/null

will suppress the message given by echo 'duck' as it's sent to /dev/null and therefore discarded.

This is mainly used when using commands that give you output that you don't want to see.

Reading from /dev/null immediately returns end of file — i.e., it acts like an empty file.

There is other fun things in /dev like random that will give you random data; not really what you expect from a "file" :)
Worth noting is that /dev/random is true random data collected from usage in the system (time between keystrokes and things like that), and that pool can be exhausted rather fast. /dev/urandom give you what seem to be random number but is calculated by a math formula. Usually /dev/urandom is fine for your need, but for for instance very strong crypto keys it's not good enough.

You can also read from /dev/zero to get an endless stream of zero (null) bytes.

I would like to add to already existing answers that there exists a man page man null that describes the /dev/null and /dev/zero files.

Name

null, zero - data sink

Description

Data written to a null or zero special file is discarded.

Reads from the null special file always return end of file (i.e.,
read(2) returns 0), whereas reads from zero always return bytes
containing zero ( characters).

null and zero are typically created by:

mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/zero c 1 5
chown root:root /dev/null /dev/zero

Files

/dev/null
/dev/zero

Notes

If these devices are not writable and
readable for all users, many programs will act strangely.

_{Source: https://linux.die.net/man/4/null}

/dev/null is a character device file, i.e. an interface to a device driver.

This specific device is a dummy device (not representing a real hardware). It is specially made to be a bottomless trash can; that you can dump any program's output into it, in case you don't want them to get on display or anywhere else.

• Content-wise, if you actually tried to read this file (yes, you can read it), it will always be equivalent to an empty 0-byte length file.

I don't know what your hx command is, but I would guess from your description that it was a command to identify file type by its content. The command I use on my GNU/Linux system for this task is file, and it stops too, if it found that the file is not a regular file...

$ file /dev/null
/dev/null: character special

But file command also provide an -s option, which force it to read regardless...

$ file -s /dev/null
/dev/null: empty

Maybe your hx command has a similar option that you can use?

The reason that file (and maybe your hx command too) don't identify non-regular files by default is hinted in the documentation of -s option in file's manual page, namely...

• Reading these files may cause side effects, side effects that are sometimes undesirable.
  
  
  • Reading from FIFO pipe consumes data in it permanently, you cannot push the data you have read back into the pipe.
  
  
  • Reading from device file causes the device to change...
    
    
    • Reading from tape device causes tape head position to shift.
    
    
    • Reading from serial port device causes buffered input bytes to be consumed.
    
    
    • Reading from random number device causes system's entropy pool to be depleted.
    
    
    • And many more, depending on driver of the device in question.
    
    
  
  


• Identifying these special files by content requires much more work, with much less certainty:
  
  
  • Content size won't be known in advance (or needs special system-specific ioctl() calls to obtain).
  
  
  • Seeking won't work in many cases.
  
  
  • Detection of file types that relies on end-of-file signature will require reading through the entire thing.
  
  
  • Some of these files give infinite content.
  
  

In case your program is not designed to handle the works needed, then it might not be capable of identifying content of non-regular files; and aborted as a safety precaution.

• Should the program proceeded without this safety check, it may result in a hang, a crash, or worse, cause the system to run out of memory; depending on the design of the program in question.

If this is the case, it is a limitation of your program; use file -s for identification purpose instead.

Addendum

If your hx is some kind of hex/binary editor; then it is especially NOT advisable to use it to open special files you don't know about. Hex editors usually preload entire file into the memory for your edit operations.

For this reason, if you try to make it open an infinite-content device file (like /dev/zero or /dev/urandom) or even a large finite device (like /dev/sda), it could drive your system into an out-of-memory condition, which you might need to reset the entire machine to recover.

The safety check you just tripped is likely there to keep you safe from that scenario. (As already mentioned: device file's content size is not known in advance— the program cannot determine beforehand whether you have enough memory to load it or not)

In case you just want to "peek" at the file's header no matter what; use hexadecimal viewer instead, like hexdump (recommended), or old-school od. For example:

• 
  hexdump -C -n 512 /dev/null (Content will be empty)


• 
  hexdump -C -n 512 /dev/urandom (Content will be a different gibberish every time)

^ The -n 512 option limits the view to the first 512 bytes. But even when you omitted this, and got bombarded with endless output, all you would need to do to stop it is just pressing Ctrl+C.

With hx I think you mean the hex editor of krpors, available on Github.

In its source file editor.c, lines 118 ff say:

struct stat statbuf;
if (stat(filename, &statbuf) == -1) 
 perror("Cannot stat file");
 exit(1);


// S_ISREG is a a POSIX macro to check whether the given st_mode denotes a
// regular file. See `man 2 stat'.
if (!S_ISREG(statbuf.st_mode)) 
 fprintf(stderr, "File '%s' is not a regular filen", filename);
 exit(1);

So, it is pretty obvious that asserting if this is a regular file leads to this error message.

What does stat do? It retreives a structure that holds information about the said file, see man 2 stat. The invocation of stat on /dev/null succeeds, because the file exists and is accessible.

Why is the assertion that /dev/null is a regular file (IS_REG()), false? Because /dev/null, the so-called Null Device, is a special pseudo-device file provided by a kernel driver. Everything written to it is discarded, and reading from it immediately returns end-of-file.

The directory /dev contains all the device files. Running ls -l also shows the Null Device as a special file by denoting it with a c as character device (as opposed to - for regular file, d for directory, l for soft link and others):

$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 1. Okt 08:46 /dev/null

The files in dev are called "special files" - unlike a "regular file", which stores content, and a "directory", which stores references to other files, a "special file" is one such that reading and writing to it does something arbitrary, defined by the kernel.

For instance, the /dev/sda special file reads data directly from your primary hard drive, in the exact layout it's stored on that drive. The /dev/eth0 special file corresponds to your Ethernet port - writing bytes to the file sends data out of that port, and reading that file reads from the port. Some special files don't talk directly to a device, but do something much like it - for instance, there is a special file (usually called /dev/ttyN/, where N is some number) for your terminal window, where writing to the file writes to the screen and reading from the file reads from the keyboard.

And, as other answers have explained, some special files just provide utilities that are nice to have around. /dev/null is one such file - when you read from it, you get EOF, and when you write to it, nothing happens. There's also /dev/zero, where you always get a zero byte when you read from it, /dev/random, which reads as random bytes sourced from chaotic events in the system (like hard disk spin time), and a few others, depending on your particular OS.