Bug 445293 - ls -l | tail gets confused, while ls -l | head works as expected
Summary: ls -l | tail gets confused, while ls -l | head works as expected
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 8
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-05 23:48 UTC by Michael Hyde
Modified: 2008-05-22 14:50 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-22 14:50:41 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michael Hyde 2008-05-05 23:48:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080416 Fedora/2.0.0.14-1.fc8 Firefox/2.0.0.14 pango-text

Description of problem:
ls -l produces a list of files of the working directory.  When I pipe the output of ls -l to tail, I get this error message:

     tail: cannot follow `-' by name

Piping ls -l to head does not produce any errors.


Version-Release number of selected component (if applicable):
coreutils-6.9-17.fc8

How reproducible:
Always


Steps to Reproduce:
1. At a terminal, type  ls -l, then press ENTER
2.
3.

Actual Results:
Updated my system.

Expected Results:
Hoped that the problem would have been caught and resolved by now.

Additional info:

Comment 1 Ondrej Vasik 2008-05-12 15:52:33 UTC
Thanks for report, but I'm not able to reproduce the problem on my machine with
the coreutils package you have specified. Is the rpm -V coreutils silent(or
without unexpected things)?
Could you please provide strace of the piped tail? I mean `ls -l | strace tail`
. Thanks.

Comment 2 Michael Hyde 2008-05-17 04:45:00 UTC
The following command produces no output (on my machine):
rpm -V coreutils

The output to `ls -l | strace tail` is as follows:

execve("/usr/bin/tail", ["tail"], [/* 45 vars */]) = 0
brk(0)                                  = 0x9a1f000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=101232, ...}) = 0
mmap2(NULL, 101232, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f1c000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360tD\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1692524, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f1b000
mmap2(0x431000, 1410608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x431000
mmap2(0x584000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x153) = 0x584000
mmap2(0x587000, 9776, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x587000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f1a000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f1a6c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0x584000, 8192, PROT_READ)     = 0
mprotect(0x42d000, 4096, PROT_READ)     = 0
munmap(0xb7f1c000, 101232)              = 0
brk(0)                                  = 0x9a1f000
brk(0x9a40000)                          = 0x9a40000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=77962480, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d1a000
close(3)                                = 0
fstat64(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
read(0, "total 4\n-rw-rw-r-- 1 mike mike 0"..., 8192) = 61
read(0, "", 8192)                       = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f34000
write(1, "total 4\n", 8)                = 8
write(1, "-rw-rw-r-- 1 mike mike 0 2008-05"..., 53) = 53
close(0)                                = 0
close(1)                                = 0
munmap(0xb7f34000, 4096)                = 0
close(2)                                = 0
exit_group(0)                           = ?


Comment 3 Ondrej Vasik 2008-05-19 10:07:13 UTC
Thanks for rpm -V info and strace output - but it shows correct output with "no
cannot follow `-' by name" error message. I need strace output from the error
case - as this one shows correct behaviour of the "ls -l | tail" command... This
command works without troubles for me, therefore without strace of the failure
or an 100% reproducer I can't do anything with that report.


Comment 4 Michael Hyde 2008-05-19 14:44:15 UTC
The output that I provided of `ls -l | strace tail` was performed in the same
directory as was done without strace.  As far as I know, I did provide the
strace of the case were I am having the error message regarding "-".  

Perhaps there is nothing wrong with coreutilities -- but there may be another
culprit: SELinux.

I have SELinux running, but in permissive mode. I've noticed that even then, it
should simply report things it would otherwise block. However, sometimes it will
block things, especially when I perform a yum update.

I have little understanding of strace, and even less of SELinx.  Any advice?

Comment 5 Ondrej Vasik 2008-05-22 14:06:17 UTC
Ok, just a little explanation of strace is just providing system calls - and
this could be used for analyze of error case. Strace you provided doesn't show
the problem - it shows just common scenario of the `ls -l | tail` - and I'm not
able to reproduce the problem on my machine - therefore I need strace of the
errorneus case - you will see "tail: cannot follow `-' by name" in the strace log.

This issue is IMHO not a problem of SELinux - as there is no problem with access... 

I could reproduce the issue if you have alias tail="tail -F" - because if you
use follow by name (which is not default), that behaviour is expected. Could you
please confirm that alias suspection?

Comment 6 Michael Hyde 2008-05-22 14:43:23 UTC
As you suspected, I do have an alias for tail, namely

alias tail='tail -s5 -n99 -F'

I have since fixed that, and now `ls -l | tail` works correctly.

Thanks for the help!


Comment 7 Ondrej Vasik 2008-05-22 14:50:41 UTC
Ok, closing NOTABUG.


Note You need to log in before you can comment on or make changes to this bug.