The standard naming practice for executables is to give them the name of the command they’re supposed to implement: ls
, cat
... There is no provision for extensions which end up ignored from the command line.
To check what a file contains before feeding it to cat
, run file
on it:
$ file /bin/ls
/bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b6b1291d0cead046ed0fa5734037fa87a579adee, for GNU/Linux 3.2.0, stripped, too many notes (256)
$ file /bin/zgrep
/bin/zgrep: a /usr/bin/sh script, ASCII text executable
This tells me that cat /bin/zgrep
won’t do anything strange to my terminal (it doesn’t even contain escape sequences, which are identified separately by file
).
I much prefer using less
in general: it will warn about binary files before showing them, and won’t mess up the terminal in any case. It can also be configured to behave like cat
for short files (see the -F
option).
As mosvy points out, you can make cat
safe to use on binaries by adding the -v
option, which replaces non-printable characters with visible representations (^
and M-
prefixes). (Rob Pike famously considered that this option is harmful — not because of its effects on the terminal, but because of its effect on command style.)
cat
on a UTF8-encoded file be a problem? Do you mean you want to check to see if a file is non-text? – Chris Davies Mar 03 '20 at 15:19