<div dir="auto">AFK, but I'm using glibc too, from Debian testing. </div><br><div class="gmail_quote"><div dir="ltr">On Sat, May 5, 2018, 16:01 Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/05/2018 02:14 PM, enh wrote:<br>
> On Sat, May 5, 2018 at 10:53 AM, Rob Landley <<a href="mailto:rob@landley.net" target="_blank" rel="noreferrer">rob@landley.net</a>> wrote:<br>
> well, strictly i think only the ELF case actually needs this<br>
> currently. we could fix the logic for the non-ELF cases (see below)<br>
> and only copy to a temporary file for the ELF case. (alternatively, we<br>
> could always read into memory and unify the cases that way --- from<br>
> strace that seems to be what FSF file does?)<br>
<br>
I prefer to have one codepath that works for everything and gets all the<br>
testing. (The performance penalty was terrible enough I couldn't do it with<br>
"tail" but that's why it's an exception. :)<br>
<br>
>>> [PATCH] Implement `file -`.<br>
>>><br>
>>> Previously we'd just always bogusly report "empty".<br>
>><br>
>> That's not what I was seeing before this patch.<br>
>><br>
>>   $ zcat ../filesystems.tar.gz | file -<br>
>>   /dev/stdin: POSIX tar archive (GNU)<br>
>>   $ zcat ../filesystems.tar.gz | ./file -<br>
>>   -: POSIX tar archive (GNU)<br>
>><br>
>> Even with input from a pipe, we're detecting stuff?<br>
>><br>
>> Could you clarify what problem this patch is trying to solve? I don't understand.<br>
> <br>
> i don't think you're accidentally running FSF file there, or you're<br>
> accidentally running toybox file _with_ my patch.<br>
> <br>
> here's a clean toybox checkout:<br>
<br>
$ git clone <a href="https://github.com/landley/toybox" rel="noreferrer noreferrer" target="_blank">https://github.com/landley/toybox</a> walrus<br>
Cloning into 'walrus'...<br>
$ cd walrus<br>
$ make defconfig<br>
...<br>
$ make<br>
...<br>
<br>
Ok, got a fresh copy, what are the tests...<br>
<br>
> $ ./toybox file - < README<br>
> -: empty<br>
> $ ./toybox file - < toybox<br>
> -: empty<br>
> $ ./toybox file - < tests/files/tar/tar.tgz<br>
> -: empty<br>
> $ cat tests/files/tar/tar.tgz | ./toybox file -<br>
> -: empty<br>
> $ zcat tests/files/tar/tar.tgz | ./toybox file -<br>
> -: empty<br>
> $<br>
<br>
Alright:<br>
<br>
$ ./toybox file - < README<br>
-: ASCII text<br>
<br>
That's built against glibc, you're building against bionic?<br>
<br>
$ ./toybox file - < toybox<br>
-: file: mmap: Cannot allocate memory<br>
ELF executable, 64-bit LSB x86-64$<br>
<br>
Yeah, mmap is broken and the stdout/stderr out of sequence flushing produces a<br>
screwed up shell prompt due to missing newline afterwards. *jazzhands*<br>
<br>
$ ./toybox file - < ../filesystems.tar.gz<br>
-: gzip compressed data<br>
$ zcat ../filesystems.tar.gz | ./toybox file -<br>
-: POSIX tar archive (GNU)<br>
<br>
It looks like glibc is behaving very differently than what you're seeing.<br>
<br>
Anything I build for x86-64 on the NDK segfaults before main() on the AMD C60 in<br>
this netbook (although I ordered a new netbook from system76 today, which cost<br>
the year the constitution was written _before_ shipping so maybe I'll have<br>
better luck with that than the $200 thing from target I upgraded the RAM on)...<br>
<br>
Let's try a static build against musl-libc...<br>
<br>
$ zcat ../filesystems.tar.gz | ./toybox file -<br>
-: empty<br>
$ ./toybox file - < toybox<br>
-: empty<br>
$ ./toybox file - < README<br>
-: empty<br>
<br>
Huh. Ok, that's weird. Yes, glibc is doing something that other C libraries are<br>
not doing, I'll see if I can track it down now that I can reproduce it...<br>
<br>
Rob<br>
</blockquote></div>