[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/4] More ls improvements
From: |
Daniel Kiper |
Subject: |
Re: [PATCH 0/4] More ls improvements |
Date: |
Fri, 1 Mar 2024 15:39:10 +0100 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
On Thu, Feb 29, 2024 at 02:57:34PM -0600, Glenn Washburn wrote:
> Hi Daniel,
>
> On Thu, 14 Sep 2023 16:44:46 +0200
> Daniel Kiper <dkiper@net-space.pl> wrote:
>
> > On Mon, Aug 14, 2023 at 01:57:06PM -0500, Glenn Washburn wrote:
> > > Currently when given a path to a file, ls will open the file to determine
> > > if its is valid and then run the appropriate print function, in contrast
> > > to
> > > directory arguments that use the directory iterator and callback on each
> > > file. One issue with this is that opening a file does not allow access to
> > > its modification time information, whereas the info object from the
> > > callback
> > > called by the directory iterator does and the longlist print function will
> > > print the modification time if present. The result is that when
> > > longlisting
> > > ls arguments, directory arguments show moditication times but file
> > > arguments
> > > do not. Patch 2 rectifies this an in the process simplifies the code path
> > > by using the directory iterator for file arguments as well.
> > >
> > > The implementation of patch 2 exposed a bug in grub_disk_read() which is
> > > fixed in patch 1.
> > >
> > > Patches 3 and 4 aim to make the output of GRUB's ls look more like GNU's
> > > ls output. And patch 4 also fixes an issue where there are blank lines
> > > between consecutive file arguments.
> >
> > This series is nice improvement and does not pose significant regression
> > risk for the release. At least I cannot see it... :-)
> >
> > So, Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>...
>
> Now that the release is out, where are we with this?
I have to check with Vladimir he is OK with your comments. Sorry for delays...
Daniel
- Re: [PATCH 0/4] More ls improvements,
Daniel Kiper <=