Re: file-exists-p on empty string

Re: file-exists-p on empty string

[lg.zevlg]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]


> So the (not (string-empty-p fn)) test just reflects the tool's semantics and is not an artifact of some suboptimal behavior of file-exists-p.
I gree, but there is not a line about empty strings in doc-string.  It is great that this is mentioned in documentation, but anyway behaviour was quite unexpected

--
lg

[-- Attachment #2: Type: text/html, Size: 858 bytes --]

Re: file-exists-p on empty string

[Stefan Monnier]

>> So the (not (string-empty-p fn)) test just reflects the tool's semantics
>> and is not an artifact of some suboptimal behavior of file-exists-p.
> I gree, but there is not a line about empty strings in doc-string.
> It is great that this is mentioned in documentation, but anyway
> behaviour was quite unexpected

The problem is that docstrings describe the behavior of a specific
function, so they usually don't mention the more general aspects that
affect all functions of a given subsystem, such as here the general
treatment of the empty string when used as a file name.

Otherwise, every file-name-manipulating function would have to repeat
this information in its docstring.


        Stefan

RE: file-exists-p on empty string

[Drew Adams]

> > I gree, but there is not a line about empty strings in doc-string.
> > It is great that this is mentioned in documentation, but anyway
> > behaviour was quite unexpected
> 
> The problem is that docstrings describe the behavior of a specific
> function, so they usually don't mention the more general aspects that
> affect all functions of a given subsystem, such as here the general
> treatment of the empty string when used as a file name.
> 
> Otherwise, every file-name-manipulating function would have to repeat
> this information in its docstring.

Every such function _should_ have this info in
its doc string.  There's no reason not to.

In terms of the _implementation_ this might be
a "general aspect that affects all functions of
a given subsystem".  But in terms of the doc for
a given such function this is not (only) a
general subsystem aspect - it is part of the
individual function's definition & description.

Even if this weren't such a gotcha, the doc for
the function should describe the return value,
including for any particular input cases.

A user might well start with `C-h f', and not
with some reading of the general-subsystem doc
(assuming there is such doc).  Such info is
pretty important to understanding the particular
function.

Re: file-exists-p on empty string

[Stefan Monnier]

> Every such function _should_ have this info in
> its doc string.  There's no reason not to.
> In terms of the _implementation_ this might be
> a "general aspect that affects all functions of
> a given subsystem".  But in terms of the doc for
> a given such function this is not (only) a
> general subsystem aspect - it is part of the
> individual function's definition & description.

By the same reasoning, file-exists-p should explain that filenames are
represented as strings, and that if a file-name is not absolute it will
be interpreted according to default-directory, and that it is subject to
file-name-handlers-alist, and `file-attributes` should additionally
explain how &optional arguments are passed, ...

So, yes, there is a reason not to: it's because duplicating such info in
every docstrings is madness.  Maybe a more sane way to provide a similar
information would be to make "filename" (in the docstring) into
a hyperlink to the Elisp refman that describes how file names work
(including things like "", file-name-handlers-alist, and default-directory).


        Stefan

Re: file-exists-p on empty string

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> So the (not (string-empty-p fn)) test just reflects the tool's semantics
>>> and is not an artifact of some suboptimal behavior of file-exists-p.
>> I gree, but there is not a line about empty strings in doc-string.
>> It is great that this is mentioned in documentation, but anyway
>> behaviour was quite unexpected
>
> The problem is that docstrings describe the behavior of a specific
> function, so they usually don't mention the more general aspects that
> affect all functions of a given subsystem, such as here the general
> treatment of the empty string when used as a file name.
>
> Otherwise, every file-name-manipulating function would have to repeat
> this information in its docstring.

What about the appended patch? It does not touch the docstrings, but it
explains the situation more verbose in the Lisp manual.

>         Stefan

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff, Size: 1601 bytes --]

*** /tmp/ediffq2yDYg	2019-03-06 10:49:17.961600214 +0100
--- /home/albinus/src/emacs-26/doc/lispref/files.texi	2019-03-06 10:39:51.804376822 +0100
***************
*** 16,22 ****
  names.  A file name is a string.  Most of these functions expand file
  name arguments using the function @code{expand-file-name}, so that
  @file{~} is handled correctly, as are relative file names (including
! @file{../}).  @xref{File Name Expansion}.
  
    In addition, certain @dfn{magic} file names are handled specially.
  For example, when a remote file name is specified, Emacs accesses the
--- 16,22 ----
  names.  A file name is a string.  Most of these functions expand file
  name arguments using the function @code{expand-file-name}, so that
  @file{~} is handled correctly, as are relative file names (including
! @file{../} and the empty string).  @xref{File Name Expansion}.
  
    In addition, certain @dfn{magic} file names are handled specially.
  For example, when a remote file name is specified, Emacs accesses the
***************
*** 2409,2414 ****
--- 2409,2425 ----
  superroot above the root directory @file{/}.  On other filesystems,
  @file{/../} is interpreted exactly the same as @file{/}.
  
+ Expanding @file{.} or the empty string returns the default directory:
+ 
+ @example
+ @group
+ (expand-file-name "." "/usr/spool/")
+      @result{} "/usr/spool"
+ (expand-file-name "" "/usr/spool/")
+      @result{} "/usr/spool"
+ @end group
+ @end example
+ 
  Note that @code{expand-file-name} does @emph{not} expand environment
  variables; only @code{substitute-in-file-name} does that:
  

Re: file-exists-p on empty string

[Stefan Monnier]

> What about the appended patch? It does not touch the docstrings, but it
> explains the situation more verbose in the Lisp manual.

Fine by me.  Maybe we should add a node that talks specifically about
the way Emacs treats file names differently from the host system.


        Stefan

Re: file-exists-p on empty string

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What about the appended patch? It does not touch the docstrings, but it
>> explains the situation more verbose in the Lisp manual.
>
> Fine by me.

Thanks. I've pushed this to the emacs-26 branch.

>         Stefan

Best regards, Michael.

Re: file-exists-p on empty string

[lg.zevlg]

> The problem is that docstrings describe the behavior of a specific function, so they usually don't mention the more general aspects that affect all functions of a given subsystem, such as here the general treatment of the empty string when used as a file name. Otherwise, every file-name-manipulating function would have to repeat this information in its docstring.

So, maybe FILENAME argument at least could be renamed to NAME to give at least some hint that this is not a filename, but just a name hint which will be expanded and canonised to real filename?

--
lg

RE: file-exists-p on empty string

[Drew Adams]

> > The problem is that docstrings describe the behavior of a specific
> function, so they usually don't mention the more general aspects that
> affect all functions of a given subsystem, such as here the general
> treatment of the empty string when used as a file name. Otherwise,
> every file-name-manipulating function would have to repeat this
> information in its docstring.
> 
> So, maybe FILENAME argument at least could be renamed to NAME to give
> at least some hint that this is not a filename, but just a name hint
> which will be expanded and canonised to real filename?

That's not good enough.  It might make sense
to you now, now that you know something about
how the input is interpreted as a file name.

The parameter name FILENAME is more appropriate
than NAME.  But the doc string should say more
about it.  You can't rely on just the parameter
name to convey all of the meaning that you're
(now) reading into it.

Re: file-exists-p on empty string

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

чт, 28 февр. 2019 г. в 01:24, Drew Adams <drew.adams@oracle.com>:

> > > The problem is that docstrings describe the behavior of a specific
> > function, so they usually don't mention the more general aspects that
> > affect all functions of a given subsystem, such as here the general
> > treatment of the empty string when used as a file name. Otherwise,
> > every file-name-manipulating function would have to repeat this
> > information in its docstring.
> >
> > So, maybe FILENAME argument at least could be renamed to NAME to give
> > at least some hint that this is not a filename, but just a name hint
> > which will be expanded and canonised to real filename?
>
> That's not good enough.  It might make sense
> to you now, now that you know something about
> how the input is interpreted as a file name.
>
> The parameter name FILENAME is more appropriate
> than NAME.  But the doc string should say more
> about it.  You can't rely on just the parameter
> name to convey all of the meaning that you're
> (now) reading into it.
>

But what to do with `file-name-directory` function, which returns `nil` to
empty string, while `file-exists-p` returns `t', and both of them gets
FILENAME as argument ?

-- 
lg

[-- Attachment #2: Type: text/html, Size: 1784 bytes --]

RE: file-exists-p on empty string

[Drew Adams]

> > > > The problem is that docstrings describe the behavior of a specific
> > > > function, so they usually don't mention the more general aspects that
> > > > affect all functions of a given subsystem, such as here the general
> > > > treatment of the empty string when used as a file name. Otherwise,
> > > > every file-name-manipulating function would have to repeat this
> > >
> > > 
> > > So, maybe FILENAME argument at least could be renamed to NAME to give
> > > at least some hint that this is not a filename, but just a name hint
> > > which will be expanded and canonised to real filename?
> >
> > That's not good enough.  It might make sense
> > to you now, now that you know something about
> > how the input is interpreted as a file name.
> >
> > The parameter name FILENAME is more appropriate
> > than NAME.  But the doc string should say more
> > about it.  You can't rely on just the parameter
> > name to convey all of the meaning that you're
> > (now) reading into it.
>
> But what to do with `file-name-directory` function,
> which returns `nil` to empty string, while
> `file-exists-p` returns `t', and both of them gets
> FILENAME as argument ?

The doc string of each should describe its parameters
and return values.  Formal parameter names are a help,
nothing more.  Sometimes a parameter name is clear
enough that it can be used inline in a sentence in
such a way that the sentence clarifies its meaning
or its name clarifies the sentence.  Sometimes not.

If a parameter name is truly misleading then it should
be changed.  I don't think that's the case here (for
either of the functions you mention).  But others
might have different opinions.

The point is that the doc string should describe the
function: its behavior, its inputs, its return value,
and its side effects.

Re: file-exists-p on empty string

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

чт, 28 февр. 2019 г. в 02:23, Drew Adams <drew.adams@oracle.com>:

> > > > > The problem is that docstrings describe the behavior of a specific
> > > > > function, so they usually don't mention the more general aspects
> that
> > > > > affect all functions of a given subsystem, such as here the general
> > > > > treatment of the empty string when used as a file name. Otherwise,
> > > > > every file-name-manipulating function would have to repeat this
> > > >
> > > >
> > > > So, maybe FILENAME argument at least could be renamed to NAME to give
> > > > at least some hint that this is not a filename, but just a name hint
> > > > which will be expanded and canonised to real filename?
> > >
> > > That's not good enough.  It might make sense
> > > to you now, now that you know something about
> > > how the input is interpreted as a file name.
> > >
> > > The parameter name FILENAME is more appropriate
> > > than NAME.  But the doc string should say more
> > > about it.  You can't rely on just the parameter
> > > name to convey all of the meaning that you're
> > > (now) reading into it.
> >
> > But what to do with `file-name-directory` function,
> > which returns `nil` to empty string, while
> > `file-exists-p` returns `t', and both of them gets
> > FILENAME as argument ?
>
> The doc string of each should describe its parameters
> and return values.  Formal parameter names are a help,
> nothing more.  Sometimes a parameter name is clear
> enough that it can be used inline in a sentence in
> such a way that the sentence clarifies its meaning
> or its name clarifies the sentence.  Sometimes not.
>
> If a parameter name is truly misleading then it should
> be changed.  I don't think that's the case here (for
> either of the functions you mention).  But others
> might have different opinions.
>
> The point is that the doc string should describe the
> function: its behavior, its inputs, its return value,
> and its side effects.
>

Totally, that is why "Emacs is an extensible self-documenting editor"


-- 
lg

[-- Attachment #2: Type: text/html, Size: 2825 bytes --]

Re: file-exists-p on empty string

[Stefan Monnier]

> But what to do with `file-name-directory` function, which returns `nil` to
> empty string,

It also returns `nil` for "a" or ".".
That's just its way to say "there is no directory part in this file name".
So it seems completely consistent with file-exists-p returning t for "".


        Stefan

file-exists-p on empty string

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

It was quite surprising for me that

  (file-exists-p "")
  ==> t

I thought that `file-exists-p` resembles stat, such as

  $ stat ""
  No such file or directory

This is because `file-exists-p` uses `expand-file-name`, which returns
current directory for empty string

Would not it be more correct for `file-exists-p` to return `nil` for empty
string, and if someone wants current directory he will use "." as filename?

Thanks

-- 
lg

[-- Attachment #2: Type: text/html, Size: 796 bytes --]

Re: file-exists-p on empty string

[Michael Albinus]

Evgeny Zajcev <lg.zevlg@gmail.com> writes:

Hi Evgeny,

> It was quite surprising for me that
>
>   (file-exists-p "")
>   ==> t
>
> I thought that `file-exists-p` resembles stat, such as
>   
>   $ stat ""
>   No such file or directory
>
> This is because `file-exists-p` uses `expand-file-name`, which returns
> current directory for empty string
>
> Would not it be more correct for `file-exists-p` to return `nil` for
> empty string, and if someone wants current directory he will use "."
> as filename?

I believe the current behavior is correct. file-exists-p calls
expand-file-name, and (expand-file-name "") returns always
default-directory.

> Thanks

Best regards, Michael.

Re: file-exists-p on empty string

[Troy Hinckley]

I agree with Evgeny. A user would not normally expect (file-exists-p “”) to return t. At least I wouldn’t. 

- Troy Hinckley

> On Feb 27, 2019, at 7:15 AM, Michael Albinus <michael.albinus@gmx.de> wrote:
> 
> Evgeny Zajcev <lg.zevlg@gmail.com> writes:
> 
> Hi Evgeny,
> 
>> It was quite surprising for me that
>> 
>>  (file-exists-p "")
>>  ==> t
>> 
>> I thought that `file-exists-p` resembles stat, such as
>> 
>>  $ stat ""
>>  No such file or directory
>> 
>> This is because `file-exists-p` uses `expand-file-name`, which returns
>> current directory for empty string
>> 
>> Would not it be more correct for `file-exists-p` to return `nil` for
>> empty string, and if someone wants current directory he will use "."
>> as filename?
> 
> I believe the current behavior is correct. file-exists-p calls
> expand-file-name, and (expand-file-name "") returns always
> default-directory.
> 
>> Thanks
> 
> Best regards, Michael.
> 

Re: file-exists-p on empty string

[Robert Pluim]

Michael Albinus <michael.albinus@gmx.de> writes:

> Evgeny Zajcev <lg.zevlg@gmail.com> writes:
>
> Hi Evgeny,
>
>> It was quite surprising for me that
>>
>>   (file-exists-p "")
>>   ==> t
>>
>> I thought that `file-exists-p` resembles stat, such as
>>   
>>   $ stat ""
>>   No such file or directory
>>
>> This is because `file-exists-p` uses `expand-file-name`, which returns
>> current directory for empty string
>>
>> Would not it be more correct for `file-exists-p` to return `nil` for
>> empty string, and if someone wants current directory he will use "."
>> as filename?
>
> I believe the current behavior is correct. file-exists-p calls
> expand-file-name, and (expand-file-name "") returns always
> default-directory.

Thatʼs not described in the doc-string though, so itʼs surprising
behaviour.

Robert

Re: file-exists-p on empty string

[Michael Albinus]

Robert Pluim <rpluim@gmail.com> writes:

>> I believe the current behavior is correct. file-exists-p calls
>> expand-file-name, and (expand-file-name "") returns always
>> default-directory.
>
> Thatʼs not described in the doc-string though, so itʼs surprising
> behaviour.

Agreed, shall be documented at least. But I'm pretty sure there's code
in the wild which depends on this behavior. Maybe not explicitly, but
via calling file-exists-p with an empty string, which has been computed somehow.

I would expect this for example for Tramp. Do we want to change such
basic behavior?

Btw, several other basic file name operations behave similar. Try
(file-attributes "") or (file-readable-p "") or (file-directory-p "") .

> Robert

Best regards, Michael.

Re: file-exists-p on empty string

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Wed, 27 Feb 2019 17:01:29 +0100
> 
> Btw, several other basic file name operations behave similar. Try
> (file-attributes "") or (file-readable-p "") or (file-directory-p "") .

All of them call expand-file-name internally, no?

Re: file-exists-p on empty string

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Albinus <michael.albinus@gmx.de>
>> Date: Wed, 27 Feb 2019 17:01:29 +0100
>> 
>> Btw, several other basic file name operations behave similar. Try
>> (file-attributes "") or (file-readable-p "") or (file-directory-p "") .
>
> All of them call expand-file-name internally, no?

Yes for file-attributes and file-readable-p. For file-directory-p I
don't see it immediately, but I guess so.

Best regards, Michael.

Re: file-exists-p on empty string

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Wed, 27 Feb 2019 16:43:29 +0100
> Cc: Evgeny Zajcev <lg.zevlg@gmail.com>, emacs-devel <emacs-devel@gnu.org>
> 
> Thatʼs not described in the doc-string though, so itʼs surprising
> behaviour.

It's a corner use case that comes up once in 10 years, so I'm not sure
we should care enough about it to describe it in the doc string.

Re: file-exists-p on empty string

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Wed, 27 Feb 2019 16:43:29 +0100
>> Cc: Evgeny Zajcev <lg.zevlg@gmail.com>, emacs-devel <emacs-devel@gnu.org>
>> 
>> Thatʼs not described in the doc-string though, so itʼs surprising
>> behaviour.
>
> It's a corner use case that comes up once in 10 years, so I'm not sure
> we should care enough about it to describe it in the doc string.

I was advocating for changing the behaviour, then we donʼt need to
describe it (but hysterical raisins and backwards compatibility and
all that.....)

Robert

Re: file-exists-p on empty string

[Andreas Schwab]

On Feb 27 2019, Robert Pluim <rpluim@gmail.com> wrote:

> Thatʼs not described in the doc-string though, so itʼs surprising
> behaviour.

It's described in the manual, see (elisp) Files.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: file-exists-p on empty string

[lg.zevlg]

> 27 февр. 2019 г., в 18:43, Robert Pluim <rpluim@gmail.com> написал(а):
> 
> Michael Albinus <michael.albinus@gmx.de> writes:
> 
>> Evgeny Zajcev <lg.zevlg@gmail.com> writes:
>> 
>> Hi Evgeny,
>> 
>>> It was quite surprising for me that
>>> 
>>>  (file-exists-p "")
>>>  ==> t
>>> 
>>> I thought that `file-exists-p` resembles stat, such as
>>> 
>>>  $ stat ""
>>>  No such file or directory
>>> 
>>> This is because `file-exists-p` uses `expand-file-name`, which returns
>>> current directory for empty string
>>> 
>>> Would not it be more correct for `file-exists-p` to return `nil` for
>>> empty string, and if someone wants current directory he will use "."
>>> as filename?
>> 
>> I believe the current behavior is correct. file-exists-p calls
>> expand-file-name, and (expand-file-name "") returns always
>> default-directory.
> 
> Thatʼs not described in the doc-string though, so itʼs surprising
> behaviour.
> 

Yeah, exactly, I’m ok with the current behaviour if it was described in doc-string!

—
lg

Re: file-exists-p on empty string

[Stefan Monnier]

>   (file-exists-p "")
>   ==> t

Elisp doesn't handle file names quite like POSIX, indeed.

I don't think we can change the above behavior without introducing other
odd behaviors.  E.g. currently (file-name-nondirectory "/a/b/") return "",
which is consistent with the above behavior.


        Stefan

Re: file-exists-p on empty string

[Robert Pluim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>   (file-exists-p "")
>>   ==> t
>
> Elisp doesn't handle file names quite like POSIX, indeed.
>
> I don't think we can change the above behavior without introducing other
> odd behaviors.  E.g. currently (file-name-nondirectory "/a/b/") return "",
> which is consistent with the above behavior.

? file-name-nodirectory doesnʼt use expand-file-name anywhere, and we
can fix file-exists-p without changing expand-file-name, so I donʼt
follow you here.

Robert

Re: file-exists-p on empty string

[Stefan Monnier]

>> I don't think we can change the above behavior without introducing other
>> odd behaviors.  E.g. currently (file-name-nondirectory "/a/b/") return "",
>> which is consistent with the above behavior.
>
> ? file-name-nondirectory doesnʼt use expand-file-name anywhere, and we
> can fix file-exists-p without changing expand-file-name, so I donʼt
> follow you here.

It considers "" as the name of the directory, just like `file-exists-p`
and `expand-file-name` (and pretty much all other operations that take
a file name).

This is really not specific to `file-exists-p`: it's a general design of
Elisp's handling of file names.

If we consider "" as an invalid file name, then I think
(file-name-nondirectory "/a/b/") should be changed to return ".", and
I'd be surprised if it's the only change we'd need to do.


        Stefan

Re: file-exists-p on empty string

[Eli Zaretskii]

> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Wed, 27 Feb 2019 15:29:53 +0300
> 
> It was quite surprising for me that
> 
>   (file-exists-p "")
>   ==> t

  http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00528.html

Nothing is new under the sun...

Re: file-exists-p on empty string

[lg.zevlg]

>> From: Evgeny Zajcev <lg.zevlg@gmail.com>
>> Date: Wed, 27 Feb 2019 15:29:53 +0300
>> 
>> It was quite surprising for me that
>> 
>>  (file-exists-p "")
>>  ==> t
> 
>  http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00528.html

Ah! I’m sorry, I searched for it, google answered nothing 

I use `(and (not (string-empty-p fn)) (file-exists-p fn))` at the moment, but its kind of ugly


—
lg

Re: file-exists-p on empty string

[Eli Zaretskii]

> From: lg.zevlg@gmail.com
> Date: Wed, 27 Feb 2019 21:42:46 +0300
> Cc: emacs-devel@gnu.org
> 
> I use `(and (not (string-empty-p fn)) (file-exists-p fn))` at the moment, but its kind of ugly

Why do you need to reject empty strings?

Re: file-exists-p on empty string

[lg.zevlg]

27 февр. 2019 г., в 21:46, Eli Zaretskii <eliz@gnu.org> написал(а):

>> From: lg.zevlg@gmail.com
>> Date: Wed, 27 Feb 2019 21:42:46 +0300
>> Cc: emacs-devel@gnu.org
>> 
>> I use `(and (not (string-empty-p fn)) (file-exists-p fn))` at the moment, but its kind of ugly
> Why do you need to reject empty strings?

Filenames are generated externally, and the tool uses empty string notion for no-file semantic

—
lg

Re: file-exists-p on empty string

[Eli Zaretskii]

> From: lg.zevlg@gmail.com
> Date: Wed, 27 Feb 2019 22:04:15 +0300
> Cc: emacs-devel@gnu.org
> 
> > Why do you need to reject empty strings?
> 
> Filenames are generated externally, and the tool uses empty string notion for no-file semantic

Isn't that un-Emacsy?  Why not nil?

Re: file-exists-p on empty string

[lg.zevlg]

27 февр. 2019 г., в 22:16, Eli Zaretskii <eliz@gnu.org> написал(а):

>> From: lg.zevlg@gmail.com
>> Date: Wed, 27 Feb 2019 22:04:15 +0300
>> Cc: emacs-devel@gnu.org
>> 
>>> Why do you need to reject empty strings?
>> 
>> Filenames are generated externally, and the tool uses empty string notion for no-file semantic
> 
> Isn't that un-Emacsy?  Why not nil?

That thing is out of my control, however `nil` is something specific and need to be handled in special way, strings are universal

Another exmaple is just a text file with filenames on each line, where empty lines occurs, you also need to check for empty string filenames

—
lg

Re: file-exists-p on empty string

[Stefan Monnier]

>>> I use `(and (not (string-empty-p fn)) (file-exists-p fn))` at the
>>> moment, but its kind of ugly
>> Why do you need to reject empty strings?
> Filenames are generated externally, and the tool uses empty string
> notion for no-file semantic

So the (not (string-empty-p fn)) test just reflects the tool's semantics
and is not an artifact of some suboptimal behavior of file-exists-p.


        Stefan