Bug in ange-ftp parsing of ls output

Bug in ange-ftp parsing of ls output

[Kim F. Storm]

In CVS emacs:

I'm using redhat 9.0, whose ftp server identifies itself as
 FTP server (Version 5.60) ready.

I've digged out the following line from the response to an
ls -al command:

-rw-------    1 kfs             0 May 27  2003 .autorun.lck

Now, if I position the cursor at the beginning of that line
and enter

M-: (ange-ftp-parse-filename) RET

it returns:

"27  2003 .autorun.lck"

If I do
M-: (re-search-forward ange-ftp-date-regexp nil t) RET
at that position, point moves to the "M" in May.

This is obviously wrong, but the ange-ftp-date-regexp is beyond me:

"[0-9] \\(\\(\\([A-Za-z]\\|[^\0-\x7f]\\)\\([A-Za-z]\\|[^\0-\x7f]\\)+[.]?,? * [ 0-3][0-9][.]?\\|[ 0-3][0-9][.]? \\([A-Za-z]\\|[^\0-\x7f]\\)\\([A-Za-z]\\|[^\0-\x7f]\\)+[.]?,? *\\)\\|[ 0-1][0-9][^\0-\x7f] [ 0-3][0-9][.]?[^\0-\x7f]\\) "


If I change the line to

-rw-------    1 kfs            10 May 27  2003 .autorun.lck

it still fails, but this line works:

-rw-------    1 kfs           100 May 27  2003 .autorun.lck

What's going on?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug in ange-ftp parsing of ls output

[Michael Albinus]

storm@cua.dk (Kim F. Storm) writes:

> I've digged out the following line from the response to an
> ls -al command:
>
> -rw-------    1 kfs             0 May 27  2003 .autorun.lck
>
> Now, if I position the cursor at the beginning of that line
> and enter
>
> M-: (ange-ftp-parse-filename) RET
>
> it returns:
>
> "27  2003 .autorun.lck"
>
> If I do
> M-: (re-search-forward ange-ftp-date-regexp nil t) RET
> at that position, point moves to the "M" in May.
>
> This is obviously wrong, but the ange-ftp-date-regexp is beyond me:
>
> "[0-9] \\(\\(\\([A-Za-z]\\|[^\0-\x7f]\\)\\([A-Za-z]\\|[^\0-\x7f]\\)+[.]?,? * [ 0-3][0-9][.]?\\|[ 0-3][0-9][.]? \\([A-Za-z]\\|[^\0-\x7f]\\)\\([A-Za-z]\\|[^\0-\x7f]\\)+[.]?,? *\\)\\|[ 0-1][0-9][^\0-\x7f] [ 0-3][0-9][.]?[^\0-\x7f]\\) "

This way the regexp is beyond me, too. Fortunately, it is well
documented in the ange-ftp.el sources.

The problem is that the line you've digged does not contain a group
id. That's why, "kfs 0" is regarded as a date.

> If I change the line to
>
> -rw-------    1 kfs            10 May 27  2003 .autorun.lck

Same problem. "kfs 10" is regarded as a date.

> it still fails, but this line works:
>
> -rw-------    1 kfs           100 May 27  2003 .autorun.lck

"kfs 100" is not a date because "100" exceeds the range of days :-)

> What's going on?

I've submitted a fix which should solve your problem. I cannot check
whether it breaks the syntax for Japanese dates - could somebody,
please, check it?

Best regards, Michael.

Re: Bug in ange-ftp parsing of ls output

[Stefan Monnier]

> I've submitted a fix which should solve your problem. I cannot check
> whether it breaks the syntax for Japanese dates - could somebody,
> please, check it?

Is there any hope we could get dired.el and ange-ftp.el to share the
same regexp.  The dired regexp is kept fairly well uptodate, so if ange-ftp
could use it, it might help,


        Stefan

Re: Bug in ange-ftp parsing of ls output

[Michael Albinus]

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

>> I've submitted a fix which should solve your problem. I cannot check
>> whether it breaks the syntax for Japanese dates - could somebody,
>> please, check it?
>
> Is there any hope we could get dired.el and ange-ftp.el to share the
> same regexp.  The dired regexp is kept fairly well uptodate, so if ange-ftp
> could use it, it might help,

You're right, `dired-move-to-filename-regexp' looks more robust than
`ange-ftp-date-regexp' (and it hasn't the bug Kim reported). But for
common use, this regexp should be moved to a more general package
(files.el?, simple.el?) in order to avoid dependencies on dired.

Other packages, like tramp, could benefit also from this.

>         Stefan

Best regards, Michael.

Re: Bug in ange-ftp parsing of ls output

[Stefan Monnier]

> You're right, `dired-move-to-filename-regexp' looks more robust than
> `ange-ftp-date-regexp' (and it hasn't the bug Kim reported).  But for
> common use, this regexp should be moved to a more general package
> (files.el?, simple.el?) in order to avoid dependencies on dired.

I'd put it in files.el nearby insert-directory.


        Stefan

Re: Bug in ange-ftp parsing of ls output

[Richard M. Stallman]

    You're right, `dired-move-to-filename-regexp' looks more robust than
    `ange-ftp-date-regexp' (and it hasn't the bug Kim reported). But for
    common use, this regexp should be moved to a more general package
    (files.el?, simple.el?) in order to avoid dependencies on dired.

Let's move it to files.el and rename it to
directory-listing-before-filename-regexp

Would you like to do it?

Re: Bug in ange-ftp parsing of ls output

[Michael Albinus]

"Richard M. Stallman" <rms@gnu.org> writes:

> Let's move it to files.el and rename it to
> directory-listing-before-filename-regexp
>
> Would you like to do it?

Done. Changed files are files.el, dired.el, dired-x.el, locate.el,
vc.el and ange-ftp.el.

locate.el and vc.el use local values of
directory-listing-before-filename-regexp. In locate.el it doesn't seem
to be noteworthy; it is derived from the default value.

vc.el uses its own regexp, which is similar to
directory-listing-before-filename-regexp. Bringing this case into
directory-listing-before-filename-regexp would require to change it to
a macro, which might not be desirable. Or am I too stupid to see how
to handle an empty vc-SYS-dired-state-info?

Best regards, Michael.

Re: Bug in ange-ftp parsing of ls output

[Richard M. Stallman]

    vc.el uses its own regexp, which is similar to
    directory-listing-before-filename-regexp. Bringing this case into
    directory-listing-before-filename-regexp would require to change it to
    a macro, which might not be desirable. Or am I too stupid to see how
    to handle an empty vc-SYS-dired-state-info?

For now, let's leave it alone.  I hope Spiegel will start responding
again and that he will eventually DTRT.  Could you add a comment
next to that variable, explaining this issue and what needs to be done?

Re: Bug in ange-ftp parsing of ls output

[Michael Albinus]

"Richard M. Stallman" <rms@gnu.org> writes:

> For now, let's leave it alone.  I hope Spiegel will start responding
> again and that he will eventually DTRT.  Could you add a comment
> next to that variable, explaining this issue and what needs to be done?

Done.

Best regards, Michael.

Re: Bug in ange-ftp parsing of ls output

[Daniel Brockman]

On Fri, 21 Oct 2005 18:19:45 -0400,
in <E1ET5En-0003kt-9y@fencepost.gnu.org>,

"Richard M. Stallman" <rms@gnu.org> wrote:

> Let's move it to files.el and rename it to
> directory-listing-before-filename-regexp

Quoting the GNU coding standards, updated January 1, 2005,

      Please do not use the term "pathname" that is used in Unix
   documentation; use "file name" (two words) instead.  We use the term
   "path" only for search paths, which are lists of directory names.

                    --- Section 6.1, (info "(standards)GNU Manuals")

The document explicitly states that "file name" should be spelled
with two words.  If that's no longer considered important, perhaps
the standards document should be updated to reflect this?

-- 
Daniel Brockman <daniel@brockman.se>

Re: Bug in ange-ftp parsing of ls output

[Richard M. Stallman]

The text you quoted applies primarily to documentation.
In Lisp symbols it is ok to write `filename' as one word,
though it might be better to use two words.