Strange `file-name-sans-extension' behavior

Strange `file-name-sans-extension' behavior

[Jens Schmidt]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.1 (i386-msvc-nt4.0.1381)
 of 2001-10-22 on buffy

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

(file-name-sans-extension "sys/types.h")

-> "c:/home/jschmidt/sys/types"

I would have expected the result "sys/types".

What about the following version of `file-name-sans-extension':

(defun file-name-sans-extension (filename)
  "Return FILENAME sans final \"extension\".
The extension, in a file name, is the part that follows the last `.'."
  (let ((file (file-name-sans-versions (file-name-nondirectory filename)))
	  directory)
      (if (string-match "\\.[^.]*\\'" file)
	  (if (setq directory (file-name-directory filename))
	      (concat (file-name-as-directory directory)
                      (substring file 0 (match-beginning 0)))
	    (substring file 0 (match-beginning 0)))
	filename)))

Regards

Jens

Re: Strange `file-name-sans-extension' behavior

[Richard Stallman]

Does this fix it?

*** files.el.~1.598.~	Fri Jul 26 11:47:31 2002
--- files.el	Sat Jul 27 14:16:42 2002
***************
*** 2468,2475 ****
        (if (and (string-match "\\.[^.]*\\'" file)
  	       (not (eq 0 (match-beginning 0))))
  	  (if (setq directory (file-name-directory filename))
! 	      (expand-file-name (substring file 0 (match-beginning 0))
! 				directory)
  	    (substring file 0 (match-beginning 0)))
  	filename))))
  
--- 2468,2476 ----
        (if (and (string-match "\\.[^.]*\\'" file)
  	       (not (eq 0 (match-beginning 0))))
  	  (if (setq directory (file-name-directory filename))
! 	      ;; Don't use expand-file-name here; if DIRECTORY is relative,
! 	      ;; we don't want to expand it.
! 	      (concat directory (substring file 0 (match-beginning 0)))
  	    (substring file 0 (match-beginning 0)))
  	filename))))

Re: Strange `file-name-sans-extension' behavior

[Stefan Monnier]

> Does this fix it?
> 
> *** files.el.~1.598.~	Fri Jul 26 11:47:31 2002
> --- files.el	Sat Jul 27 14:16:42 2002
> ***************
> *** 2468,2475 ****
>         (if (and (string-match "\\.[^.]*\\'" file)
>   	       (not (eq 0 (match-beginning 0))))
>   	  (if (setq directory (file-name-directory filename))
> ! 	      (expand-file-name (substring file 0 (match-beginning 0))
> ! 				directory)
>   	    (substring file 0 (match-beginning 0)))
>   	filename))))
>   
> --- 2468,2476 ----
>         (if (and (string-match "\\.[^.]*\\'" file)
>   	       (not (eq 0 (match-beginning 0))))
>   	  (if (setq directory (file-name-directory filename))
> ! 	      ;; Don't use expand-file-name here; if DIRECTORY is relative,
> ! 	      ;; we don't want to expand it.
> ! 	      (concat directory (substring file 0 (match-beginning 0)))
>   	    (substring file 0 (match-beginning 0)))
>   	filename))))

Could we introduce a new function for that or some way to tell
`expand-file-name' not to do the expansion if the dir is relative ?
The current elisp primitives make it very difficult to reconstruct
a file name that was just taken apart.  The missing piece is
indeed this "concat a (potentially relative) directory name
and a file name but without making it absolute and without
adding "./" in front".


	Stefan

Re: Strange `file-name-sans-extension' behavior

[Richard Stallman]

    Could we introduce a new function for that or some way to tell
    `expand-file-name' not to do the expansion if the dir is relative ?

In principle this is ok, but why is concat not correct?
In this very limited situation, it ought to be correct as
far as I can tell.

Re: Strange `file-name-sans-extension' behavior

[Stefan Monnier]

>     Could we introduce a new function for that or some way to tell
>     `expand-file-name' not to do the expansion if the dir is relative ?
> 
> In principle this is ok, but why is concat not correct?
> In this very limited situation, it ought to be correct as
> far as I can tell.

Is it correct for VMS ?
Maybe in practice it works for all systems we care about, but in theory
string concatenation has nothing to do intrinsically with generating
a filename by combining a relative directory name and a relative filename.


	Stefan

Re: Strange `file-name-sans-extension' behavior

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> 
> Is it correct for VMS ?
> Maybe in practice it works for all systems we care about, but in theory
> string concatenation has nothing to do intrinsically with generating
> a filename by combining a relative directory name and a relative filename.

Strictly speaking, it isn't correct even for Windows, as this
example shows:

	c: + bar -> c:./bar, not c:/bar

Re: Strange `file-name-sans-extension' behavior

[Andreas Schwab]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

|> > From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
|> > 
|> > Is it correct for VMS ?
|> > Maybe in practice it works for all systems we care about, but in theory
|> > string concatenation has nothing to do intrinsically with generating
|> > a filename by combining a relative directory name and a relative filename.
|> 
|> Strictly speaking, it isn't correct even for Windows, as this
|> example shows:
|> 
|> 	c: + bar -> c:./bar, not c:/bar

But c:bar should be correct.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Strange `file-name-sans-extension' behavior

[Richard Stallman]

    Strictly speaking, it isn't correct even for Windows, as this
    example shows:

	    c: + bar -> c:./bar, not c:/bar

I don't understand this example, partly because the two parts
are not labeled as to what they mean.  "c: + bar -> c:./bar"
could be a statement of what something actually does (what something?),
or it could be a statement of what something ought to do.
I can't tell which.

Re: Strange `file-name-sans-extension' behavior

[Eli Zaretskii]

> Date: Tue, 13 Aug 2002 16:47:00 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> 
> 	    c: + bar -> c:./bar, not c:/bar
> 
> I don't understand this example

It means that to produce a full file name from a relative directory
"c:" and a relative file name "bar", a function should yield
"c:./bar".

Re: Strange `file-name-sans-extension' behavior

[Richard Stallman]

    It means that to produce a full file name from a relative directory
    "c:" and a relative file name "bar", a function should yield
    "c:./bar".

Is this really relevant to file-name-sans-extension?
The directory it uses is the one that was in the argument file name.
If it was valid there, it should be equally valid in the result.
If it is not valid in the result, I guess it was not valid in
the argument.

Re: Strange `file-name-sans-extension' behavior

[Eli Zaretskii]

> Date: Wed, 14 Aug 2002 17:14:22 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> 
>     It means that to produce a full file name from a relative directory
>     "c:" and a relative file name "bar", a function should yield
>     "c:./bar".
> 
> Is this really relevant to file-name-sans-extension?

Perhaps not, I admit that I don't fully understand the precise
context of this discussion.

I was replying to the question whether `concat' is a universally
correct way of constructing file names from a directory name and a
file name.

> The directory it uses is the one that was in the argument file name.
> If it was valid there, it should be equally valid in the result.
> If it is not valid in the result, I guess it was not valid in
> the argument.

The problem is the slash you append to the directory if it doesn't
end in a slash.

Re: Strange `file-name-sans-extension' behavior

[Richard Stallman]

    > The directory it uses is the one that was in the argument file name.
    > If it was valid there, it should be equally valid in the result.
    > If it is not valid in the result, I guess it was not valid in
    > the argument.

    The problem is the slash you append to the directory if it doesn't
    end in a slash.

I don't see any code in file-name-sans-extension to append a slash to
the directory name.  It gets the directory name with
file-name-directory and uses it without further change.

Where is the slash appended?

`concat' a dir and a file (was: Strange `file-name-sans-extension' behavior )

[Stefan Monnier]

>     > The directory it uses is the one that was in the argument file name.
>     > If it was valid there, it should be equally valid in the result.
>     > If it is not valid in the result, I guess it was not valid in
>     > the argument.
> 
>     The problem is the slash you append to the directory if it doesn't
>     end in a slash.
> 
> I don't see any code in file-name-sans-extension to append a slash to
> the directory name.  It gets the directory name with
> file-name-directory and uses it without further change.
> 
> Where is the slash appended?

The `Subject:' had not been updated, so it was misleading.
The discussion is about whether or not we need a new function
that is like expand-file-name but does not necessarily return
an absolute file name.   Currently when you need to combine a
relative dir with a file name, you need to use
(concat (file-name-as-directory foo) bar), but the fact that `concat'
works for this is purely accidental (and might not even be always true
for currently supported systems, according to Eli).

I've sometimes tried to use
  (let ((default-directory nil)) (expand-file-name bar foo))
or
  (let ((default-directory "")) (expand-file-name bar foo))

but it prepends "/" or "./" to the result.


	Stefan

Re: `concat' a dir and a file (was: Strange `file-name-sans-extension' behavior )

[Richard Stallman]

    The `Subject:' had not been updated, so it was misleading.
    The discussion is about whether or not we need a new function
    that is like expand-file-name but does not necessarily return
    an absolute file name.

I treated that as a subtopic of the issue of what to do with
file-name-sans-extension, and considered it only in reference to that
main topic.  Now I will address the new topic

As far as I can see, if you don't insist on an absolute file name,
it is correct to use concat.  As far as I can see, Eli's example
is only an issue if you want an absolute file name:

>     It means that to produce a full file name from a relative directory
>     "c:" and a relative file name "bar", a function should yield
>     "c:./bar".

Eli, is c:bar an invalid file name on MSDOS?

So it seems that in the case where you are happy to have
a non-absolute file name as the result, there is no problem.

    I've sometimes tried to use
      (let ((default-directory nil)) (expand-file-name bar foo))
    or
      (let ((default-directory "")) (expand-file-name bar foo))

    but it prepends "/" or "./" to the result.

Is that what you had in mind when you spoke of appending a slash?  It
would follow that these methods are not good ones.  However, that
doesn't say anything about whether concat is a good method.

Re: `concat' a dir and a file (was: Strange `file-name-sans-extension' behavior )

[Eli Zaretskii]

> Date: Fri, 16 Aug 2002 22:51:10 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> 
> As far as I can see, if you don't insist on an absolute file name,
> it is correct to use concat.  As far as I can see, Eli's example
> is only an issue if you want an absolute file name:
> 
> >     It means that to produce a full file name from a relative directory
> >     "c:" and a relative file name "bar", a function should yield
> >     "c:./bar".
> 
> Eli, is c:bar an invalid file name on MSDOS?

"c:bar" is a valid file name on DOS and Windows file systems.  It
means `bar' in the default directory of the C: drive.  In other words,
it's the same as "c:./bar".

> So it seems that in the case where you are happy to have
> a non-absolute file name as the result, there is no problem.

There should be no problem if none of the functions involved convert
"c:" to "c:/".  I don't recall if that's so and don't have time to
check, but I wouldn't be surprised if Emacs primitives already take
care of this.

It's the case of application code doing (concat dir "/" file) is what
worries me.

Re: `concat' a dir and a file (was: Strange `file-name-sans-extension' behavior )

[Stefan Monnier]

> It's the case of application code doing (concat dir "/" file) is what
> worries me.

These are wrong anyway.  (concat (file-name-as-directory dir) file) is
what they should use instead (at least as long as there is no
expand-relative-file-name function).


	Stefan

Re: `concat' a dir and a file (was: Strange `file-name-sans-extension' behavior )

[Richard Stallman]

    It's the case of application code doing (concat dir "/" file) is what
    worries me.

That is a different case--if dir is really a directory name, it is
simply incorrect to add an explicit slash.  You must be thinking of a
case where DIR is a directory file name rather than a directory name.
The right way to handle that situation is

  (concat (file-name-as-directory dirfile) file)

Do you see any case where that would give incorrect result
on MS systems?

I will update the documentation in lispref/files.texi to discuss
this issue.

Re: `concat' a dir and a file (was: Strange `file-name-sans-extension' behavior )

[Eli Zaretskii]

> Date: Mon, 19 Aug 2002 12:39:16 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> 
> The right way to handle that situation is
> 
>   (concat (file-name-as-directory dirfile) file)
> 
> Do you see any case where that would give incorrect result
> on MS systems?

Looks like file-name-as-directory needs some work on MS systems:

  M-: (file-name-as-directory "d:") RET => "d:/"

This is wrong (I verified that the cwd on drive D: is not the root
directory).

I'll try to see how to fix that.

Re: Strange `file-name-sans-extension' behavior

[Richard Stallman]

    > In principle this is ok, but why is concat not correct?
    > In this very limited situation, it ought to be correct as
    > far as I can tell.

    Is it correct for VMS ?

I think so.