Traditional assembler, and higher level compilers work with several memory segments, according to intended use. Hence, there is a data segment, a stack segment, a bss,
It might have something to do with the fact that the code section was usually read-only, and it could also contain strings of characters for the text messages the program could display to the user as messages. Hence the "text" section. This is in contrast to the "data" section which contains pieces of data that can be modified.
I suggest that the meaning references the assembler (in that case that is for what we are speaking about) language is text, readable text. So the segment .text can be traduced as segment where the code program (text) is written and where the text of the program is, but last is called segment .data. Also it can be called segment .code because is the segment where the program's code is.
In my opinion should be just called: .code (which is text and also it logically differenciates from the other sections).
The name segment comes from the memory management techniques used in older times, which is now replaced by paging. I believe the name text comes from the analogy with the novel. Like the text in the novel, the code can be thought of as a piece of text in a novel. The text section of the code tells describes the code or it tells the story of what the program does.
I agree with kdgregory's answer, but I think the the binary text
notation came from this fact.
I've always imagined it comes form the analogy with human-readable text.
You write in english language a piece of text. It is a string of letters, punctuations, etc. and adheres to certain rules defined by the language (i.e. syntactical, grammatical, etc.). It can be understood by people that know the language.
Similarly, you write (i.e. build) in machine language a "text". It is a string of binary data (digits) and adheres to certain rules defined by the language (i.e. the instruction set architecture). It can be understood (i.e. executed) by processors that know that machine language (i.e. implement the ISA).
IMO the term "code" is less logical. "code" means a piece of information that has been converted (encoded) from it's original form into some alternative representation (for whatever purpose). But with the executable "code", it is not clear which was its the "original" form.
Going a little further with nos's comments, I turned up a scanned version of the GE-635 Programming Manual, and found the following in the section on the macro assembler:
The GE-625/635 Macro Assembler is being provided to give the professional programmers some of the conveniences of a compiler and the flexibility of an Assembler. [...] The output options enable him to obtain binary text in relocatable as well as absolute formats.
So, it appears that the use of "binary text" was a GE colloquialism, or perhaps a commonly used term at the time (remember that those were the days when card readers/punches were used for much IO). So, one possible path is GE, to Multics via GE-645, to Unix via Bell Labs' work on Multics, to Linux.
Could it be because the program code, be it hard-to-read machine instructions, is really the program text - i.e. the text that contains the instructions? The same as when you call a calculus book a text book, although it is pretty hard to decipher unless you are familiar with the mathematical symbols that are the code..