On Sat, Jul 29, 2023 at 10:02:00AM +0100, Joseph Wright wrote:
> On 29/07/2023 08:37, LARONDE Thierry wrote:
> > On Sat, Jul 29, 2023 at 08:07:54AM +0100, Joseph Wright wrote:
> > > On 29/07/2023 06:46, LARONDE Thierry wrote:
> > > > On Fri, Jul 28, 2023 at 08:31:53PM +0100, David Carlisle wrote:
> > > > > 
> > > > > % If this option is set to true, `tex a.b' will look first for a.b.tex
> > > > > % (within each path element), and then for a.b, i.e., we try standard
> > > > > % extensions first.  If this is false, we first look for a.b and then
> > > > > % a.b.tex, i.e., we try the name as-is first.
> > > > > %
> > > > > % Both names are always tried; the difference is the order in which they
> > > > > % are tried.  The setting applies to all searches, not just .tex.
> > > > > %
> > > > > % This setting only affects names being looked up which *already* have
> > > > > % an extension.  A name without an extension (e.g., `tex story') will
> > > > > % always have an extension added first.
> > > > > %
> > > > > % The default is true, because we already avoid adding the standard
> > > > > % extension(s) in the usual cases.  E.g., babel.sty will only look for
> > > > > % babel.sty, not babel.sty.tex, regardless of this setting.
> > > > > try_std_extension_first = t
> > > > 
> > > > I suppose that this behavior is in LaTeX code, not an engine?
> > > 
> > > That's from texmf.cnf, so affects most engines. (LuaMetaTeX like unaffected:
> > > I'd have to check.)
> > 
> > This does mean that this behavior is not in the engine but in the glue
> > code (the opening routines implemented in web2c/kpathsea)? So its
> > setting is done at configuration level in the distribution, and LaTeX
> > has no way to switch things from its macro files?
> 
> Yes, as file handling is of course not part of the portable TeX code.

OK, let's go to "TeX: The Program": m.537 (p 214):

---8<---
@ Let's turn now to the procedure that is used to initiate file reading 
when an `\.{\\input}' command is being processed.
Beware: For historic reasons, this code foolishly conserves a tiny bit
of string pool space; but that can confuse the interactive `\.E' option.

@^system dependencies@>
  
@p procedure start_input; {\TeX\ will \.{\\input} something}
label done;
begin scan_file_name; {set |cur_name| to desired file name}
if cur_ext="" then cur_ext:=".tex";
pack_cur_name;
loop@+  begin begin_file_reading; {set up |cur_file| and new level of
input}    
  if a_open_in(cur_file) then goto done;
  if cur_area="" then
    begin pack_file_name(cur_name,TEX_area,cur_ext);
    if a_open_in(cur_file) then goto done;
    end;    
  end_file_reading; {remove the level that didn't work}
  prompt_file_name("input file name",".tex"); 
  end;
done: name:=a_make_name_string(cur_file);
---8<---

(Note for myself: I can simplify the code to not stutter, because the
second search will do exactly the same thing as the first since there
is no difference in "areas": searching is done "near" for user file, and
then in the kerTeX hierarchy.)

In this code, scan_file_name sets cur_name, cur_area and cur_ext.

Before trying to open, if cur_ext is the empty string, ".tex" is
assumed.

Then the filename is constructed with pack_cur_name, that will hence add
the ".tex" if there was no extension.

So, when you refer to "TeX" behavior, you are not referring to D.E.K.'s
program but to the way "it has been done" by web2c?

There is an ambiguity here. Because, in "TeX: The Program", D.E.K.
writes "The extension of an input file or a write file is assumed
to be `.tex' unless otherwise specified." (m.511, p. 206).

But the first alinea says "The following programs show what is required
for one particular operating system; similar routines for other systems
are not difficult to devise." So it's ambiguous: is the extensions a
part of the contract with the user, or a system dependent part?

My view was to implement searched routines according to the system, but
so that TeX behaves the same, for the user, according, this time, to
the TeXbook.

And in the TeXbook, it is written (chapter 3, p.7 for example):

"For example, you might type
	\input MS
which (as we will see later) causes TeX to begin reading a file called
`MS.tex'; the string of characters `\input' is a control sequence."

So, for me, adding ".tex" is a requirement (the TeXbook). Searching and
the way the files are organized is a system dependency and priorities
(when searching) are system dependencies too.

So can you (I mean the LaTeX team) tell me:

1) What do you call "TeX behavior"? As written by D.E.K. both in the
implementation: "TeX: The Program" AND the manual: "The TeXbook"? Or are
you referring to one particular implementation?

2) For me, it is not possible, if one respects the TeXbook---it is
ambiguous in "TeX: The Program" because @^system dependencies@> can mean
part of the code, or all---it is not possible to \input a file without
an extension.

So can you show me where I misread D.E.K.'s books---it is possible that
I misread; it's large---and/or tell me if LaTeX relies on things that
are "implementation dependent"---you are not able to point me to the
code or the manual (TeX: The Program or TeXbook) but well: "this is it"
and this is what LaTeX is expecting. (For now and for what I see, I
don't have to do acrobatics like web2c but simply make the new file
primitive behave as \input---this does mean that a file without an
extension is unreachable.)

I need to have things stated so that I can see what I have to modify
and to decide where I will make the modification: in the engine: Prote?
Or in the distribution: kerTeX?.

TIA,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C