On Fri, Dec 08, 2023 at 05:41:57PM -0500, Pocket wrote: > > On 12/8/23 17:31, Greg Wooledge wrote: > > On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote: > > > In Unix and Linux there isn't a file extension, that is a microsoft > > > invention. > > cc(1) and make(1) would like to have a talk with you. > > > Linux/Unix filenaming specs would like to inform you. > > file specs/naming i Unix and Linux are 355 characters and nothing more. > > I am surprised you don't know that
cc(1) looks at the file extension to decide what kind of content each named argument file is expected to contain. A .c file is expected to contain C language source code; a .o file is expected to contain object code; a .s file is expected to contain assembly language source code; and so on. It invokes the compiler, the assembler, and/or the linker depending on what kinds of files it has been given. make(1) lets you define a rule for converting an input file with extension E1 to an output file with extension E2. These rules will be applied in the absence of specific overrides. If you define a rule like ".xx.yy:" then make will use this to turn any *.xx file into a matching *.yy file. Then you can type, for example, "make frog.yy" and it will look for frog.xx and frog.yy, compare their timestamps, and if needed, apply your custom rule to generate the frog.yy file. While I'm giving examples, there's also Apache, which decides what Content-type header to generate for a given static file based on its extension. I would imagine other web servers do the same thing. And hey, I'm using mutt to compose and send this email. If I were to attach a file to this message, mutt would look at its extension to decide what MIME type to give it. Your notion that "most Unix programs use file(1) output to decide a file's content" is simply not universal. I don't even think it's *common*, especially given how inconsistent file's output is. Most programs that need to determine content types dynamically look at extensions. Even on Unix.
