Re: uzip extfs sanity patch

[Pavel Roskin <proski gnu org>]

Hello!

> > > Well, if fish-like format was used, something like
> > >
> > > Nfile_name
> > > Dsome_unparsable_junk
> > > Prwxr--r--
> > >
> > > would be passed to midnight. Midnight would refuse to interpret date,

OK, I see it now.  In fact, it can be even more useful for extfs than for
fish, because different scripts deal with different output.  Some scripts
can assume that the date has 3 space-separated fields, some cannot.

> > Well, that would be great, but it would implicate updating (and
> > complicating, or even rewriting in Perl, like Pavel R. said) every
> > extfs script - so it looks like it's not worth the effort.

Nothing forbids having more than one format in the date parser.  I don't
like having separate lines, but if the script knows the exact number of
fields belonging to the date, it could concatenate them e.g. by an
underscore and prepend some marker.  Another marker could be used for
time_t format.  The parser would check markers first (in which case
exactly one column would be processed)  and then fall back to the standard
procedure.  Examples:

10 Dec 2002 15:37:26
D_10_Dec_2002_15:37:26
T_1031158228

> Well, if correctness is not worth the effort... :-(. It could be done
> one script at a time...

Agreed.

> Imagine what happens with filenames like "2001 Space odysey" etc.

It was reported at least 3 times, but with ftpfs.  The problem with FTP is
that the date format is not known.  However, we can make some guesses.  I
don't think I have ever seen a year immediately following the
hours:minutes[:seconds] field.  Most time only one of those fields is
present, and if both are present, something is between them, either the
timezone (see "date" output) or the month and the date.

-- 
Regards,
Pavel Roskin