the FSF file(1) is inconsistent too, in a way that suggests it's being
clever:
~$ file /dev/zero
/dev/zero: character special (1/5)
~$ file - < /dev/zero
/dev/stdin: data
~$
On Thu, May 3, 2018, 18:36 Rob Landley wrote:
> On 05/03/2018 06:40 PM, enh wrote:
> > +// If we're working on stdi
On 05/03/2018 06:40 PM, enh wrote:
> +// If we're working on stdin, copy to a temporary file and then use
> +// an fd for that file. That way the rest of the code doesn't have to
> +// worry about non-seekable/non-mmap'able input.
Hmmm, in the old code:
$ ./file ../filesystems.tar.gz
Previously we'd just always bogusly report "empty".
---
tests/file.test | 2 ++
toys/posix/file.c | 20 +---
2 files changed, 19 insertions(+), 3 deletions(-)
From fe3639f24995cc96f5a05eacae52f0b624f3af7c Mon Sep 17 00:00:00 2001
From: Elliott Hughes
Date: Thu, 3 May 2018 16:39
seems like '.' (as opposed to '#') doesn't actually work? generates a
`FLAGS_.` and breaks the build if i try to use it. nothing's using it
yet, and the place i was going to use it ended up better off with
xparsetime anyway.
(also the code.html docs are out of date wrt to the corresponding big
com
On Thu, May 3, 2018 at 2:31 PM, Rob Landley wrote:
>
> On 05/03/2018 12:55 AM, enh wrote:
> > i was surprised to see all the files in `ls` output indented by one
> > space today. turns out that was because there was a file with a space
> > in the name in that directory.
>
> I worked out that the r
LTP uses `top -d 0.1`, which isn't convincingly useful, but general
support for other time units might be useful, and switching to xparsetime
addresses both at once.
Also fix 3169d948c049664bcf7216d4c4ae751881099d3e where I mistakenly
treated `rev` and `toys.optflags&FLAG_b` as interchangeable. (W
On 05/03/2018 12:55 AM, enh wrote:
> i was surprised to see all the files in `ls` output indented by one
> space today. turns out that was because there was a file with a space
> in the name in that directory.
I worked out that the reason ls had two spaces between columns is if an entry
ends with
