Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: zsh/stat: output atime/mtime/ctime with nanoseconds
- X-seq: zsh-workers 43070
- From: dana <dana@xxxxxxx>
- To: Vincent Lefevre <vincent@xxxxxxxxxx>
- Subject: Re: zsh/stat: output atime/mtime/ctime with nanoseconds
- Date: Tue, 19 Jun 2018 12:32:19 -0500
- Cc: zsh-workers@xxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dana-is.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S4Ctg179hvNx+mcqvNvbFl8e+KH7he3Z+aLQxuF3iGU=; b=qC9JacQ5wnArOb9h0LXB+cx8qpqeIwNHgy97EVxVTx651U30/VKmNCCazI0ZqUXxxk O929E/TGS82tdoanx7qcIfG99VrtReiRHXasMIG16Kmg0N0hQgyQ+XAjj4ap7ag6Db30 CqFe+4TsGVC3/Bhi+Wb91V7I2kaL3xCM8XIutkNDzgf7yz4W2S4LqsU5lBmpJeDvP374 LUkdSR94A+7h2IS0bKI1KAthQw8yjJYNVb38hGOxm5+AnnT8ksk93esEWz10LLgOkHib Lw6I6x55vcB8aqq7zCafixBlY2yV6N0i6clVlm+XbfomPS+0WmULr66VKEOx0XjsKTMY 8AXA==
- In-reply-to: <20180619141851.GA16101@zira.vinc17.org>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20180619141851.GA16101@zira.vinc17.org>
On 19 Jun 2018, at 09:18, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
>Under Linux, the stat utility from GNU Coreutils outputs
>atime/mtime/ctime with nanoseconds.
>
>IMHO, zsh should do the same.
The GNU tools that support nanoseconds in time strings tend to use Gnulib's
nstrftime(), which provides their %N extension to the standard strftime(3)
stuff.
zsh has a similar function, ztrftime(), which zsh/stat uses. The first problem
is that the module doesn't pass the file's sub-second time information to the
function, and the second problem is that, even if it did, ztrftime() only
supports microsecond granularity. I think it would be very easy to change both
of those things, but there may be some portability issues with getting the
nanosecond information itself.
(Also, not all file systems even record times to the nanosecond — HFS+ only has
whole-second granularity for example — but that's another thing.)
If nobody has any objections i might look into this later; there've been a few
times i wanted '%9.' myself.
dana
Messages sorted by:
Reverse Date,
Date,
Thread,
Author