Typically that's the way TeX primitives react. From the TeXbook (Chapter 3: Controlling TeX, p 10):
How can a person distinguish a TeX primitive from a control sequence that
has been defined at a higher level? There are two ways: (1) The index to this
manual lists all of the control sequences that are discussed, and each primitive is marked with an asterisk. (2) You can display the meaning of a control sequence while running TeX. If you type
\cs is any control sequence, TeX will respond with its current meaning. For example,
\show\input results in
> \input=\input., because
\input is primitive. On the other hand,
->\kern .16667em .
This means that
\thinspace has been defined as an abbreviation for
\kern .16667em. By typing
\show\kern you can verify that
\kern is primitive. The results of
\show appear on your terminal and in the log file that you get after running TeX.
Commands that are declared in a robust way have a similarly bizarre output even though they are declared as a "macro". For example,
->\protect \vspace .
in the terminal.
Some primitives can be expanded and there is also a way around peeking inside the definition of robust commands. For those primitives that cannot be expanded, you'd have to look into TeX The Program - the
.web code or its documentation - in order to understand what it's doing.
Using David's example that input the following in the TeX terminal (no filename specified):
528. Initially job_name = 0; it becomes nonzero as soon as the true name is known. We have job_name = 0 if and only if the
log file has not been opened, except of course for a short time just after job name has
534. The open_log_file routine...
if job_name = 0 then job_name ← "