On all of the 7.x ported versions of gnuls, ls -l indefinitely shows no output, and never returns. I am not sure if others can reproduce this bug. misc/gnuls version 6.12 works fine. Fix: I am simply reporting this issue so that others may be aware of it, I'm not sure how to fix it. (I wrote an alternative to emacs' dired, so I no longer have a need for GNU ls) How-To-Repeat: on the shell, gnuls -l (my shell is tcsh)
Maintainer of misc/gnuls, Please note that PR ports/134311 has just been submitted. If it contains a patch for an upgrade, an enhancement or a bug fix you agree on, reply to this email stating that you approve the patch and a committer will take care of it. The full text of the PR can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/134311 -- Edwin Groothuis via the GNATS Auto Assign Tool edwin@FreeBSD.org
State Changed From-To: open->feedback Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
Responsible Changed From-To: freebsd-ports-bugs->wxs I'll take it.
I'm the listed maintainer of gnuls, but I do not currently have a FreeBSD 7 instance on which to test/debug this issue. -- -Brian Brian Clapper, http://www.clapper.org/bmc/ There can be no offense where none is taken. -- Japanese proverb
At Wed, 06 May 2009 18:09:12 -0400, Brian Clapper wrote: > > I'm the listed maintainer of gnuls, but I do not currently have a FreeBSD 7 > instance on which to test/debug this issue. > -- > -Brian > > Brian Clapper, http://www.clapper.org/bmc/ > There can be no offense where none is taken. > -- Japanese proverb Hi Brian, I was talking about the version of gnuls, not FreeBSD 6.x. I think it may also be an issue on FreeBSD 6.x, although I could be wrong... Regards
On 5/6/09 6:23 PM, Timothy Beyer wrote: > At Wed, 06 May 2009 18:09:12 -0400, > Brian Clapper wrote: >> I'm the listed maintainer of gnuls, but I do not currently have a FreeBSD 7 >> instance on which to test/debug this issue. >> -- >> -Brian >> >> Brian Clapper, http://www.clapper.org/bmc/ >> There can be no offense where none is taken. >> -- Japanese proverb > > Hi Brian, > > I was talking about the version of gnuls, not FreeBSD 6.x. I think it may also be an issue on FreeBSD 6.x, although I could be wrong... Thanks. Not sure when I'll get a chance to look at this. I should really load a more up-to-date version of FreeBSD first. The version running on my server is embarrassingly old. -- -Brian Brian Clapper, http://www.clapper.org/bmc/ Conceit causes more conversation than wit. -- LaRouchefoucauld
This is a followup that I made in a private email clarifying the specific details in my report. I apologize for not being more specific in the first place. I'm using UFS2 with softupdates on my filesystem, ACLs enabled. All of my filesystems are using geli. My shell is tcsh. I think I confused everyone when I was refering to 7.x, I mean the 7.x versions of gnuls, not of FreeBSD. (and for any other version numbers that I noted, I was referring to versions of gnuls) I would suspect that any problems I'm having with gnuls would exist on any version of FreeBSD, but I'm not sure why the old Makefile revision 1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls versions 7.1 and 7.2 do not work properly fo r me. Basically, the regular gnuls listing works for any of the newest port revisions, as well as the old, but the the gnuls -l does not work for the newest two port revisions. Perhaps my problem is some incompatibility in new gnuls versions with my chosen filesystem configuration? Regards, Tim
On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote: > The following reply was made to PR ports/134311; it has been noted by GNATS. > > From: Timothy Beyer <beyert@cs.ucr.edu> > To: bug-followup@FreeBSD.org > Cc: Timothy Beyer <beyert@cs.ucr.edu> > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions >= 7.x > Date: Fri, 08 May 2009 01:37:22 -0700 > > This is a followup that I made in a private email clarifying the > specific details in my report. I apologize for not being more > specific in the first place. > > I'm using UFS2 with softupdates on my filesystem, ACLs enabled. All > of my filesystems are using geli. My shell is tcsh. > > I think I confused everyone when I was refering to 7.x, I mean the > 7.x versions of gnuls, not of FreeBSD. (and for any other version > numbers that I noted, I was referring to versions of gnuls) I would > suspect that any problems I'm having with gnuls would exist on any > version of FreeBSD, but I'm not sure why the old Makefile revision > 1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but > the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls > versions 7.1 and 7.2 do not work properly fo r me. > > Basically, the regular gnuls listing works for any of the newest port > revisions, as well as the old, but the the gnuls -l does not work for > the newest two port revisions. > > Perhaps my problem is some incompatibility in new gnuls versions with > my chosen filesystem configuration? Quite possibly this is a local problem with your configuration. I, unfortunately don't have a solution nor the time to look into it. I'd be happy to commit any fix Brian can come up with as the maintainer. Brian, have you had any luck looking into this? -- WXS
On 6/1/09 1:08 PM, Wesley Shields wrote: > On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote: >> The following reply was made to PR ports/134311; it has been noted by GNATS. >> >> From: Timothy Beyer <beyert@cs.ucr.edu> >> To: bug-followup@FreeBSD.org >> Cc: Timothy Beyer <beyert@cs.ucr.edu> >> Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions >= 7.x >> Date: Fri, 08 May 2009 01:37:22 -0700 >> >> This is a followup that I made in a private email clarifying the >> specific details in my report. I apologize for not being more >> specific in the first place. >> >> I'm using UFS2 with softupdates on my filesystem, ACLs enabled. All >> of my filesystems are using geli. My shell is tcsh. >> >> I think I confused everyone when I was refering to 7.x, I mean the >> 7.x versions of gnuls, not of FreeBSD. (and for any other version >> numbers that I noted, I was referring to versions of gnuls) I would >> suspect that any problems I'm having with gnuls would exist on any >> version of FreeBSD, but I'm not sure why the old Makefile revision >> 1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but >> the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls >> versions 7.1 and 7.2 do not work properly fo r me. >> >> Basically, the regular gnuls listing works for any of the newest port >> revisions, as well as the old, but the the gnuls -l does not work for >> the newest two port revisions. >> >> Perhaps my problem is some incompatibility in new gnuls versions with >> my chosen filesystem configuration? > > Quite possibly this is a local problem with your configuration. I, > unfortunately don't have a solution nor the time to look into it. I'd be > happy to commit any fix Brian can come up with as the maintainer. > > Brian, have you had any luck looking into this? I have not, I'm afraid. I have an ancient version of FreeBSD on my server, which I cannot upgrade at the moment. Meanwhile, my current contract has sucked up enough of my time that I haven't had a chance to load something more reasonable and test this stuff. -- -Brian Brian Clapper, http://www.clapper.org/bmc/ Catch a wave and you're sitting on top of the world.
On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote: > The following reply was made to PR ports/134311; it has been noted by GNATS. > > From: Timothy Beyer <beyert@cs.ucr.edu> > To: bug-followup@FreeBSD.org > Cc: Timothy Beyer <beyert@cs.ucr.edu> > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions >= 7.x > Date: Fri, 08 May 2009 01:37:22 -0700 > > This is a followup that I made in a private email clarifying the > specific details in my report. I apologize for not being more > specific in the first place. > > I'm using UFS2 with softupdates on my filesystem, ACLs enabled. All > of my filesystems are using geli. My shell is tcsh. > > I think I confused everyone when I was refering to 7.x, I mean the > 7.x versions of gnuls, not of FreeBSD. (and for any other version > numbers that I noted, I was referring to versions of gnuls) I would > suspect that any problems I'm having with gnuls would exist on any > version of FreeBSD, but I'm not sure why the old Makefile revision > 1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but > the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls > versions 7.1 and 7.2 do not work properly fo r me. > > Basically, the regular gnuls listing works for any of the newest port > revisions, as well as the old, but the the gnuls -l does not work for > the newest two port revisions. > > Perhaps my problem is some incompatibility in new gnuls versions with > my chosen filesystem configuration? I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested, I don't have a machine using GELI) and I'm not sure how to proceed from here. Can you look into using truss or ktrace to provide us with more detailed information regarding the problem? -- WXS
At Mon, 15 Jun 2009 15:25:01 -0400, Wesley Shields wrote: > > On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote: > > The following reply was made to PR ports/134311; it has been noted by GNATS. > > > > From: Timothy Beyer <beyert@cs.ucr.edu> > > To: bug-followup@FreeBSD.org > > Cc: Timothy Beyer <beyert@cs.ucr.edu> > > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions >= 7.x > > Date: Fri, 08 May 2009 01:37:22 -0700 > > > > This is a followup that I made in a private email clarifying the > > specific details in my report. I apologize for not being more > > specific in the first place. > > > > I'm using UFS2 with softupdates on my filesystem, ACLs enabled. All > > of my filesystems are using geli. My shell is tcsh. > > > > I think I confused everyone when I was refering to 7.x, I mean the > > 7.x versions of gnuls, not of FreeBSD. (and for any other version > > numbers that I noted, I was referring to versions of gnuls) I would > > suspect that any problems I'm having with gnuls would exist on any > > version of FreeBSD, but I'm not sure why the old Makefile revision > > 1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but > > the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls > > versions 7.1 and 7.2 do not work properly fo r me. > > > > Basically, the regular gnuls listing works for any of the newest port > > revisions, as well as the old, but the the gnuls -l does not work for > > the newest two port revisions. > > > > Perhaps my problem is some incompatibility in new gnuls versions with > > my chosen filesystem configuration? > > I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested, > I don't have a machine using GELI) and I'm not sure how to proceed from > here. Can you look into using truss or ktrace to provide us with more > detailed information regarding the problem? > > -- WXS Hi, I will try those tools and report my results. Tim
At Mon, 15 Jun 2009 15:25:01 -0400, Wesley Shields wrote: > > On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote: > > The following reply was made to PR ports/134311; it has been noted by GNATS. > > > > From: Timothy Beyer <beyert@cs.ucr.edu> > > To: bug-followup@FreeBSD.org > > Cc: Timothy Beyer <beyert@cs.ucr.edu> > > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions >= 7.x > > Date: Fri, 08 May 2009 01:37:22 -0700 > > > > This is a followup that I made in a private email clarifying the > > specific details in my report. I apologize for not being more > > specific in the first place. > > > > I'm using UFS2 with softupdates on my filesystem, ACLs enabled. All > > of my filesystems are using geli. My shell is tcsh. > > > > I think I confused everyone when I was refering to 7.x, I mean the > > 7.x versions of gnuls, not of FreeBSD. (and for any other version > > numbers that I noted, I was referring to versions of gnuls) I would > > suspect that any problems I'm having with gnuls would exist on any > > version of FreeBSD, but I'm not sure why the old Makefile revision > > 1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but > > the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls > > versions 7.1 and 7.2 do not work properly fo r me. > > > > Basically, the regular gnuls listing works for any of the newest port > > revisions, as well as the old, but the the gnuls -l does not work for > > the newest two port revisions. > > > > Perhaps my problem is some incompatibility in new gnuls versions with > > my chosen filesystem configuration? > > I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested, > I don't have a machine using GELI) and I'm not sure how to proceed from > here. Can you look into using truss or ktrace to provide us with more > detailed information regarding the problem? > > -- WXS Here is the output of truss and gnuls -l on /usr/local/bin. Note that doesn't do anything after __acl_get_file calls. [beyert@aeonserv.aeonnet] > cd /usr/local/bin/ [beyert@aeonserv.aeonnet] > sudo truss /usr/local/bin/gnuls -l __sysctl(0xbfbfe864,0x2,0xbfbfe86c,0xbfbfe870,0x0,0x0) = 0 (0x0) mmap(0x0,296,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 868827136 (0x33c94000) munmap(0x33c94000,296) = 0 (0x0) __sysctl(0xbfbfe8c8,0x2,0x33c90e5c,0xbfbfe8d0,0x0,0x0) = 0 (0x0) mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868827136 (0x33c94000) issetugid(0x33c89f8c,0xbfbfe990,0x104,0x0,0x0,0x0) = 0 (0x0) open("/etc/libmap.conf",O_RDONLY,0666) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=24791,size=3766,blksize=4096 }) = 0 (0x0) read(3,"# /etc/libmap.conf for FreeBSD 6"...,4096) = 3766 (0xeb6) read(3,0x33c98000,4096) = 0 (0x0) close(3) = 0 (0x0) open("/var/run/ld-elf.so.hints",O_RDONLY,00) = 3 (0x3) read(3,"Ehnt\^A\0\0\0\M^@\0\0\0x\^B\0\0"...,128) = 128 (0x80) mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868859904 (0x33c9c000) lseek(3,0x80,SEEK_SET) = 128 (0x80) read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,632) = 632 (0x278) close(3) = 0 (0x0) access("/lib/libc.so.7",0) = 0 (0x0) open("/lib/libc.so.7",O_RDONLY,00) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=16584,size=1058208,blksize=4096 }) = 0 (0x0) read(3,"\^?ELF\^A\^A\^A\t\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000) mmap(0x0,1056768,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) = 868896768 (0x33ca5000) mprotect(0x33d8c000,4096,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0) mprotect(0x33d8c000,4096,PROT_READ|PROT_EXEC) = 0 (0x0) mmap(0x33d8d000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xe8000) = 869847040 (0x33d8d000) mmap(0x33d93000,81920,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 869871616 (0x33d93000) close(3) = 0 (0x0) sysarch(0xa,0xbfbfe930,0x33c6a21b,0x33c8f814,0x33c7b619,0x33c8f814) = 0 (0x0) mmap(0x0,872,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000) munmap(0x33da7000,872) = 0 (0x0) mmap(0x0,21176,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000) munmap(0x33da7000,21176) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) __sysctl(0xbfbfe8e4,0x2,0x33d93ae0,0xbfbfe8ec,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) open("/usr/share/locale/en_US.UTF-8/LC_COLLATE",O_RDONLY,0666) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=950042,size=4642,blksize=4096 }) = 0 (0x0) __sysctl(0xbfbfe458,0x2,0x33d978c0,0xbfbfe464,0x0,0x0) = 0 (0x0) __sysctl(0xbfbfdf68,0x2,0x33da405c,0xbfbfdf70,0x0,0x0) = 0 (0x0) __sysctl(0xbfbfdfb8,0x2,0xbfbfdfc4,0xbfbfdfc8,0x0,0x0) = 0 (0x0) readlink("/etc/malloc.conf",0xbfbfe057,1024) ERR#2 'No such file or directory' issetugid(0x33d84ec0,0xbfbfe057,0x400,0xbfbfe464,0x0,0x0) = 0 (0x0) break(0x8100000) = 0 (0x0) __sysctl(0xbfbfe2d4,0x2,0xbfbfe2dc,0xbfbfe2e0,0x0,0x0) = 0 (0x0) mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 869953536 (0x33da7000) mmap(0x33ea7000,364544,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 871002112 (0x33ea7000) munmap(0x33da7000,364544) = 0 (0x0) read(3,"1.2\n\0\0\0\0\0\0\0\0\0\^A\0\0\0"...,4096) = 4096 (0x1000) read(3,"\0\M-?\0\0\0\0\0\0\0\M-@\0\0\0\0"...,4096) = 546 (0x222) close(3) = 0 (0x0) open("/usr/share/locale/en_US.UTF-8/LC_CTYPE",O_RDONLY,0666) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0) fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0) lseek(3,0x0,SEEK_CUR) = 0 (0x0) lseek(3,0x0,SEEK_SET) = 0 (0x0) read(3,"RuneMag1UTF-8\0\0\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000) read(3,"@\^D\b\0\0\0\n\M-<\0\0\n\M-E@\^D"...,4096) = 4096 (0x1000) read(3,"\0\0\^AJ\0\0\^AJ\0\0\^AK\0\0\^AL"...,4096) = 4096 (0x1000) read(3,"\0\0\^_\^O\0\0\^_\0\0\0\^_\^X\0"...,4096) = 4096 (0x1000) read(3,"\0\0\^^T\0\0\^^W\0\0\^^W\0\0\^^V"...,4096) = 4096 (0x1000) read(3,"@\^D\M^I\0@\^D\^Y\0@\^D\M^I\0@"...,4096) = 4096 (0x1000) read(3,"@$\b\0@$\b\0@$\b\0@$\b\0@$\b\0@$"...,4096) = 4096 (0x1000) read(3,"@\^D(\0@\^D(\0@\^D(\0@\^D(\0@\^D"...,4096) = 4096 (0x1000) read(3,"\M^@$\b\0\M^@$\b\0\M^@$\b\0\M^@$"...,4096) = 4096 (0x1000) read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000) read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000) read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) read(3,"@\^D\M^I\0@\^D\M^I\0@\^D\M^I\0@"...,4096) = 2404 (0x964) close(3) = 0 (0x0) open("/usr/share/locale/en_US.UTF-8/LC_MONETARY",O_RDONLY,06370000000) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=974091,size=34,blksize=4096 }) = 0 (0x0) read(3,"USD \n$\n.\n,\n3;3\n\n-\n2\n2\n1"...,34) = 34 (0x22) close(3) = 0 (0x0) open("/usr/share/locale/en_US.UTF-8/LC_NUMERIC",O_RDONLY,042) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=975978,size=8,blksize=4096 }) = 0 (0x0) read(3,".\n,\n3;3\n",8) = 8 (0x8) close(3) = 0 (0x0) open("/usr/share/locale/en_US.UTF-8/LC_TIME",O_RDONLY,010) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=976068,size=377,blksize=4096 }) = 0 (0x0) read(3,"Jan\nFeb\nMar\nApr\nMay\nJun\nJu"...,377) = 377 (0x179) close(3) = 0 (0x0) open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES",O_RDONLY,0571) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=975871,size=18,blksize=4096 }) = 0 (0x0) read(3,"^[yYsS].*\n^[nN].*\n",18) = 18 (0x12) close(3) = 0 (0x0) ioctl(1,TIOCGETA,0xbfbfea38) = 0 (0x0) ioctl(1,TIOCGWINSZ,0xbfbfeaa8) = 0 (0x0) stat(".",{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0) open(".",O_NONBLOCK,06) = 3 (0x3) fstat(3,{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0) fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) fstatfs(0x3,0xbfbfe6a4,0x1,0x2,0x1,0x33c8fe14) = 0 (0x0) getdirentries(0x3,0x33e18000,0x1000,0x33e010e4,0x0,0x33c96200) = 4096 (0x1000) lstat("lua50",{ mode=drwxr-xr-x ,inode=927745,size=512,blksize=4096 }) = 0 (0x0) __acl_get_file(0xbfbfe770,0x0,0x33e0c240,0xbfbfe770,0x33e12008,0x33e12000) = 0 (0x0) __acl_get_file(0xbfbfe770,0x1,0x33e0c240,0x33cfcb81,0x2d,0x33e0c240) = 0 (0x0)
On Mon, Jun 15, 2009 at 03:09:10PM -0700, Timothy Beyer wrote: > At Mon, 15 Jun 2009 15:25:01 -0400, > Wesley Shields wrote: > > > > On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote: > > > The following reply was made to PR ports/134311; it has been noted by GNATS. > > > > > > From: Timothy Beyer <beyert@cs.ucr.edu> > > > To: bug-followup@FreeBSD.org > > > Cc: Timothy Beyer <beyert@cs.ucr.edu> > > > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions >= 7.x > > > Date: Fri, 08 May 2009 01:37:22 -0700 > > > > > > This is a followup that I made in a private email clarifying the > > > specific details in my report. I apologize for not being more > > > specific in the first place. > > > > > > I'm using UFS2 with softupdates on my filesystem, ACLs enabled. All > > > of my filesystems are using geli. My shell is tcsh. > > > > > > I think I confused everyone when I was refering to 7.x, I mean the > > > 7.x versions of gnuls, not of FreeBSD. (and for any other version > > > numbers that I noted, I was referring to versions of gnuls) I would > > > suspect that any problems I'm having with gnuls would exist on any > > > version of FreeBSD, but I'm not sure why the old Makefile revision > > > 1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but > > > the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls > > > versions 7.1 and 7.2 do not work properly fo r me. > > > > > > Basically, the regular gnuls listing works for any of the newest port > > > revisions, as well as the old, but the the gnuls -l does not work for > > > the newest two port revisions. > > > > > > Perhaps my problem is some incompatibility in new gnuls versions with > > > my chosen filesystem configuration? > > > > I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested, > > I don't have a machine using GELI) and I'm not sure how to proceed from > > here. Can you look into using truss or ktrace to provide us with more > > detailed information regarding the problem? > > > > -- WXS > > Here is the output of truss and gnuls -l on /usr/local/bin. Note that doesn't do anything after __acl_get_file calls. > > [beyert@aeonserv.aeonnet] > cd /usr/local/bin/ > [beyert@aeonserv.aeonnet] > sudo truss /usr/local/bin/gnuls -l > __sysctl(0xbfbfe864,0x2,0xbfbfe86c,0xbfbfe870,0x0,0x0) = 0 (0x0) > mmap(0x0,296,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 868827136 (0x33c94000) > munmap(0x33c94000,296) = 0 (0x0) > __sysctl(0xbfbfe8c8,0x2,0x33c90e5c,0xbfbfe8d0,0x0,0x0) = 0 (0x0) > mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868827136 (0x33c94000) > issetugid(0x33c89f8c,0xbfbfe990,0x104,0x0,0x0,0x0) = 0 (0x0) > open("/etc/libmap.conf",O_RDONLY,0666) = 3 (0x3) > fstat(3,{ mode=-r--r--r-- ,inode=24791,size=3766,blksize=4096 }) = 0 (0x0) > read(3,"# /etc/libmap.conf for FreeBSD 6"...,4096) = 3766 (0xeb6) > read(3,0x33c98000,4096) = 0 (0x0) > close(3) = 0 (0x0) > open("/var/run/ld-elf.so.hints",O_RDONLY,00) = 3 (0x3) > read(3,"Ehnt\^A\0\0\0\M^@\0\0\0x\^B\0\0"...,128) = 128 (0x80) > mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868859904 (0x33c9c000) > lseek(3,0x80,SEEK_SET) = 128 (0x80) > read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,632) = 632 (0x278) > close(3) = 0 (0x0) > access("/lib/libc.so.7",0) = 0 (0x0) > open("/lib/libc.so.7",O_RDONLY,00) = 3 (0x3) > fstat(3,{ mode=-r--r--r-- ,inode=16584,size=1058208,blksize=4096 }) = 0 (0x0) > read(3,"\^?ELF\^A\^A\^A\t\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000) > mmap(0x0,1056768,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) = 868896768 (0x33ca5000) > mprotect(0x33d8c000,4096,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0) > mprotect(0x33d8c000,4096,PROT_READ|PROT_EXEC) = 0 (0x0) > mmap(0x33d8d000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xe8000) = 869847040 (0x33d8d000) > mmap(0x33d93000,81920,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 869871616 (0x33d93000) > close(3) = 0 (0x0) > sysarch(0xa,0xbfbfe930,0x33c6a21b,0x33c8f814,0x33c7b619,0x33c8f814) = 0 (0x0) > mmap(0x0,872,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000) > munmap(0x33da7000,872) = 0 (0x0) > mmap(0x0,21176,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000) > munmap(0x33da7000,21176) = 0 (0x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > __sysctl(0xbfbfe8e4,0x2,0x33d93ae0,0xbfbfe8ec,0x0,0x0) = 0 (0x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > open("/usr/share/locale/en_US.UTF-8/LC_COLLATE",O_RDONLY,0666) = 3 (0x3) > fstat(3,{ mode=-r--r--r-- ,inode=950042,size=4642,blksize=4096 }) = 0 (0x0) > __sysctl(0xbfbfe458,0x2,0x33d978c0,0xbfbfe464,0x0,0x0) = 0 (0x0) > __sysctl(0xbfbfdf68,0x2,0x33da405c,0xbfbfdf70,0x0,0x0) = 0 (0x0) > __sysctl(0xbfbfdfb8,0x2,0xbfbfdfc4,0xbfbfdfc8,0x0,0x0) = 0 (0x0) > readlink("/etc/malloc.conf",0xbfbfe057,1024) ERR#2 'No such file or directory' > issetugid(0x33d84ec0,0xbfbfe057,0x400,0xbfbfe464,0x0,0x0) = 0 (0x0) > break(0x8100000) = 0 (0x0) > __sysctl(0xbfbfe2d4,0x2,0xbfbfe2dc,0xbfbfe2e0,0x0,0x0) = 0 (0x0) > mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 869953536 (0x33da7000) > mmap(0x33ea7000,364544,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 871002112 (0x33ea7000) > munmap(0x33da7000,364544) = 0 (0x0) > read(3,"1.2\n\0\0\0\0\0\0\0\0\0\^A\0\0\0"...,4096) = 4096 (0x1000) > read(3,"\0\M-?\0\0\0\0\0\0\0\M-@\0\0\0\0"...,4096) = 546 (0x222) > close(3) = 0 (0x0) > open("/usr/share/locale/en_US.UTF-8/LC_CTYPE",O_RDONLY,0666) = 3 (0x3) > fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0) > fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0) > lseek(3,0x0,SEEK_CUR) = 0 (0x0) > lseek(3,0x0,SEEK_SET) = 0 (0x0) > read(3,"RuneMag1UTF-8\0\0\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000) > read(3,"@\^D\b\0\0\0\n\M-<\0\0\n\M-E@\^D"...,4096) = 4096 (0x1000) > read(3,"\0\0\^AJ\0\0\^AJ\0\0\^AK\0\0\^AL"...,4096) = 4096 (0x1000) > read(3,"\0\0\^_\^O\0\0\^_\0\0\0\^_\^X\0"...,4096) = 4096 (0x1000) > read(3,"\0\0\^^T\0\0\^^W\0\0\^^W\0\0\^^V"...,4096) = 4096 (0x1000) > read(3,"@\^D\M^I\0@\^D\^Y\0@\^D\M^I\0@"...,4096) = 4096 (0x1000) > read(3,"@$\b\0@$\b\0@$\b\0@$\b\0@$\b\0@$"...,4096) = 4096 (0x1000) > read(3,"@\^D(\0@\^D(\0@\^D(\0@\^D(\0@\^D"...,4096) = 4096 (0x1000) > read(3,"\M^@$\b\0\M^@$\b\0\M^@$\b\0\M^@$"...,4096) = 4096 (0x1000) > read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000) > read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000) > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > read(3,"@\^D\M^I\0@\^D\M^I\0@\^D\M^I\0@"...,4096) = 2404 (0x964) > close(3) = 0 (0x0) > open("/usr/share/locale/en_US.UTF-8/LC_MONETARY",O_RDONLY,06370000000) = 3 (0x3) > fstat(3,{ mode=-r--r--r-- ,inode=974091,size=34,blksize=4096 }) = 0 (0x0) > read(3,"USD \n$\n.\n,\n3;3\n\n-\n2\n2\n1"...,34) = 34 (0x22) > close(3) = 0 (0x0) > open("/usr/share/locale/en_US.UTF-8/LC_NUMERIC",O_RDONLY,042) = 3 (0x3) > fstat(3,{ mode=-r--r--r-- ,inode=975978,size=8,blksize=4096 }) = 0 (0x0) > read(3,".\n,\n3;3\n",8) = 8 (0x8) > close(3) = 0 (0x0) > open("/usr/share/locale/en_US.UTF-8/LC_TIME",O_RDONLY,010) = 3 (0x3) > fstat(3,{ mode=-r--r--r-- ,inode=976068,size=377,blksize=4096 }) = 0 (0x0) > read(3,"Jan\nFeb\nMar\nApr\nMay\nJun\nJu"...,377) = 377 (0x179) > close(3) = 0 (0x0) > open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES",O_RDONLY,0571) = 3 (0x3) > fstat(3,{ mode=-r--r--r-- ,inode=975871,size=18,blksize=4096 }) = 0 (0x0) > read(3,"^[yYsS].*\n^[nN].*\n",18) = 18 (0x12) > close(3) = 0 (0x0) > ioctl(1,TIOCGETA,0xbfbfea38) = 0 (0x0) > ioctl(1,TIOCGWINSZ,0xbfbfeaa8) = 0 (0x0) > stat(".",{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0) > open(".",O_NONBLOCK,06) = 3 (0x3) > fstat(3,{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0) > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) > fstatfs(0x3,0xbfbfe6a4,0x1,0x2,0x1,0x33c8fe14) = 0 (0x0) > getdirentries(0x3,0x33e18000,0x1000,0x33e010e4,0x0,0x33c96200) = 4096 (0x1000) > lstat("lua50",{ mode=drwxr-xr-x ,inode=927745,size=512,blksize=4096 }) = 0 (0x0) > __acl_get_file(0xbfbfe770,0x0,0x33e0c240,0xbfbfe770,0x33e12008,0x33e12000) = 0 (0x0) > __acl_get_file(0xbfbfe770,0x1,0x33e0c240,0x33cfcb81,0x2d,0x33e0c240) = 0 (0x0) Does this happen on every directory or just this particular one? Can you give me the output of ls -l for any particular directory which causes the problem and any ACLs set in there? Thanks! -- WXS
At Mon, 15 Jun 2009 21:36:14 -0400, Wesley Shields wrote: > > On Mon, Jun 15, 2009 at 03:09:10PM -0700, Timothy Beyer wrote: > > At Mon, 15 Jun 2009 15:25:01 -0400, > > Wesley Shields wrote: > > > > > > On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote: > > > > The following reply was made to PR ports/134311; it has been noted by GNATS. > > > > > > > > From: Timothy Beyer <beyert@cs.ucr.edu> > > > > To: bug-followup@FreeBSD.org > > > > Cc: Timothy Beyer <beyert@cs.ucr.edu> > > > > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions >= 7.x > > > > Date: Fri, 08 May 2009 01:37:22 -0700 > > > > > > > > This is a followup that I made in a private email clarifying the > > > > specific details in my report. I apologize for not being more > > > > specific in the first place. > > > > > > > > I'm using UFS2 with softupdates on my filesystem, ACLs enabled. All > > > > of my filesystems are using geli. My shell is tcsh. > > > > > > > > I think I confused everyone when I was refering to 7.x, I mean the > > > > 7.x versions of gnuls, not of FreeBSD. (and for any other version > > > > numbers that I noted, I was referring to versions of gnuls) I would > > > > suspect that any problems I'm having with gnuls would exist on any > > > > version of FreeBSD, but I'm not sure why the old Makefile revision > > > > 1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but > > > > the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls > > > > versions 7.1 and 7.2 do not work properly fo r me. > > > > > > > > Basically, the regular gnuls listing works for any of the newest port > > > > revisions, as well as the old, but the the gnuls -l does not work for > > > > the newest two port revisions. > > > > > > > > Perhaps my problem is some incompatibility in new gnuls versions with > > > > my chosen filesystem configuration? > > > > > > I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested, > > > I don't have a machine using GELI) and I'm not sure how to proceed from > > > here. Can you look into using truss or ktrace to provide us with more > > > detailed information regarding the problem? > > > > > > -- WXS > > > > Here is the output of truss and gnuls -l on /usr/local/bin. Note that doesn't do anything after __acl_get_file calls. > > > > [beyert@aeonserv.aeonnet] > cd /usr/local/bin/ > > [beyert@aeonserv.aeonnet] > sudo truss /usr/local/bin/gnuls -l > > __sysctl(0xbfbfe864,0x2,0xbfbfe86c,0xbfbfe870,0x0,0x0) = 0 (0x0) > > mmap(0x0,296,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 868827136 (0x33c94000) > > munmap(0x33c94000,296) = 0 (0x0) > > __sysctl(0xbfbfe8c8,0x2,0x33c90e5c,0xbfbfe8d0,0x0,0x0) = 0 (0x0) > > mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868827136 (0x33c94000) > > issetugid(0x33c89f8c,0xbfbfe990,0x104,0x0,0x0,0x0) = 0 (0x0) > > open("/etc/libmap.conf",O_RDONLY,0666) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=24791,size=3766,blksize=4096 }) = 0 (0x0) > > read(3,"# /etc/libmap.conf for FreeBSD 6"...,4096) = 3766 (0xeb6) > > read(3,0x33c98000,4096) = 0 (0x0) > > close(3) = 0 (0x0) > > open("/var/run/ld-elf.so.hints",O_RDONLY,00) = 3 (0x3) > > read(3,"Ehnt\^A\0\0\0\M^@\0\0\0x\^B\0\0"...,128) = 128 (0x80) > > mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868859904 (0x33c9c000) > > lseek(3,0x80,SEEK_SET) = 128 (0x80) > > read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,632) = 632 (0x278) > > close(3) = 0 (0x0) > > access("/lib/libc.so.7",0) = 0 (0x0) > > open("/lib/libc.so.7",O_RDONLY,00) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=16584,size=1058208,blksize=4096 }) = 0 (0x0) > > read(3,"\^?ELF\^A\^A\^A\t\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000) > > mmap(0x0,1056768,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) = 868896768 (0x33ca5000) > > mprotect(0x33d8c000,4096,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0) > > mprotect(0x33d8c000,4096,PROT_READ|PROT_EXEC) = 0 (0x0) > > mmap(0x33d8d000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xe8000) = 869847040 (0x33d8d000) > > mmap(0x33d93000,81920,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 869871616 (0x33d93000) > > close(3) = 0 (0x0) > > sysarch(0xa,0xbfbfe930,0x33c6a21b,0x33c8f814,0x33c7b619,0x33c8f814) = 0 (0x0) > > mmap(0x0,872,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000) > > munmap(0x33da7000,872) = 0 (0x0) > > mmap(0x0,21176,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000) > > munmap(0x33da7000,21176) = 0 (0x0) > > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) > > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > > __sysctl(0xbfbfe8e4,0x2,0x33d93ae0,0xbfbfe8ec,0x0,0x0) = 0 (0x0) > > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) > > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_COLLATE",O_RDONLY,0666) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=950042,size=4642,blksize=4096 }) = 0 (0x0) > > __sysctl(0xbfbfe458,0x2,0x33d978c0,0xbfbfe464,0x0,0x0) = 0 (0x0) > > __sysctl(0xbfbfdf68,0x2,0x33da405c,0xbfbfdf70,0x0,0x0) = 0 (0x0) > > __sysctl(0xbfbfdfb8,0x2,0xbfbfdfc4,0xbfbfdfc8,0x0,0x0) = 0 (0x0) > > readlink("/etc/malloc.conf",0xbfbfe057,1024) ERR#2 'No such file or directory' > > issetugid(0x33d84ec0,0xbfbfe057,0x400,0xbfbfe464,0x0,0x0) = 0 (0x0) > > break(0x8100000) = 0 (0x0) > > __sysctl(0xbfbfe2d4,0x2,0xbfbfe2dc,0xbfbfe2e0,0x0,0x0) = 0 (0x0) > > mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 869953536 (0x33da7000) > > mmap(0x33ea7000,364544,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 871002112 (0x33ea7000) > > munmap(0x33da7000,364544) = 0 (0x0) > > read(3,"1.2\n\0\0\0\0\0\0\0\0\0\^A\0\0\0"...,4096) = 4096 (0x1000) > > read(3,"\0\M-?\0\0\0\0\0\0\0\M-@\0\0\0\0"...,4096) = 546 (0x222) > > close(3) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_CTYPE",O_RDONLY,0666) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0) > > fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0) > > lseek(3,0x0,SEEK_CUR) = 0 (0x0) > > lseek(3,0x0,SEEK_SET) = 0 (0x0) > > read(3,"RuneMag1UTF-8\0\0\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0\0\0\n\M-<\0\0\n\M-E@\^D"...,4096) = 4096 (0x1000) > > read(3,"\0\0\^AJ\0\0\^AJ\0\0\^AK\0\0\^AL"...,4096) = 4096 (0x1000) > > read(3,"\0\0\^_\^O\0\0\^_\0\0\0\^_\^X\0"...,4096) = 4096 (0x1000) > > read(3,"\0\0\^^T\0\0\^^W\0\0\^^W\0\0\^^V"...,4096) = 4096 (0x1000) > > read(3,"@\^D\M^I\0@\^D\^Y\0@\^D\M^I\0@"...,4096) = 4096 (0x1000) > > read(3,"@$\b\0@$\b\0@$\b\0@$\b\0@$\b\0@$"...,4096) = 4096 (0x1000) > > read(3,"@\^D(\0@\^D(\0@\^D(\0@\^D(\0@\^D"...,4096) = 4096 (0x1000) > > read(3,"\M^@$\b\0\M^@$\b\0\M^@$\b\0\M^@$"...,4096) = 4096 (0x1000) > > read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\M^I\0@\^D\M^I\0@\^D\M^I\0@"...,4096) = 2404 (0x964) > > close(3) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_MONETARY",O_RDONLY,06370000000) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=974091,size=34,blksize=4096 }) = 0 (0x0) > > read(3,"USD \n$\n.\n,\n3;3\n\n-\n2\n2\n1"...,34) = 34 (0x22) > > close(3) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_NUMERIC",O_RDONLY,042) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=975978,size=8,blksize=4096 }) = 0 (0x0) > > read(3,".\n,\n3;3\n",8) = 8 (0x8) > > close(3) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_TIME",O_RDONLY,010) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=976068,size=377,blksize=4096 }) = 0 (0x0) > > read(3,"Jan\nFeb\nMar\nApr\nMay\nJun\nJu"...,377) = 377 (0x179) > > close(3) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES",O_RDONLY,0571) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=975871,size=18,blksize=4096 }) = 0 (0x0) > > read(3,"^[yYsS].*\n^[nN].*\n",18) = 18 (0x12) > > close(3) = 0 (0x0) > > ioctl(1,TIOCGETA,0xbfbfea38) = 0 (0x0) > > ioctl(1,TIOCGWINSZ,0xbfbfeaa8) = 0 (0x0) > > stat(".",{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0) > > open(".",O_NONBLOCK,06) = 3 (0x3) > > fstat(3,{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0) > > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) > > fstatfs(0x3,0xbfbfe6a4,0x1,0x2,0x1,0x33c8fe14) = 0 (0x0) > > getdirentries(0x3,0x33e18000,0x1000,0x33e010e4,0x0,0x33c96200) = 4096 (0x1000) > > lstat("lua50",{ mode=drwxr-xr-x ,inode=927745,size=512,blksize=4096 }) = 0 (0x0) > > __acl_get_file(0xbfbfe770,0x0,0x33e0c240,0xbfbfe770,0x33e12008,0x33e12000) = 0 (0x0) > > __acl_get_file(0xbfbfe770,0x1,0x33e0c240,0x33cfcb81,0x2d,0x33e0c240) = 0 (0x0) > > Does this happen on every directory or just this particular one? Can you > give me the output of ls -l for any particular directory which causes > the problem and any ACLs set in there? > > Thanks! > > -- WXS Hi, Thus far, it doesn't terminate on any directory that I have tried. (/var ,/tmp /external, /proc, /root, ~/, /usr/local/bin, /usr/bin, and dozens of other directories that don't actually use ACLs, among many of which are deep subdirectories on a filesystem) For what it's worth, I've never actually used ACLs on any file on my computer, I merely enabled ACLs on all of my filesystems. All of the outputs of truss mentioned above end with something like the following: (the first hexidecimal number varies based on directory and if current working directory is used instead of directly specifying the path) __acl_get_file(0xbfbfebd9,0x0,0x33e0c240,0xbfbfebd9,0x33e12008,0x33e12000) = 0 (0x0) __acl_get_file(0xbfbfebd9,0x1,0x33e0c240,0x33cfcb81,0x2d,0x33e0c240) = 0 (0x0) None terminate, except when a non-existent directory is given as a parameter. (but then it gives a "No such file or directory" error as it should) Tim
At Mon, 15 Jun 2009 21:36:14 -0400, Wesley Shields wrote: > > On Mon, Jun 15, 2009 at 03:09:10PM -0700, Timothy Beyer wrote: > > At Mon, 15 Jun 2009 15:25:01 -0400, > > Wesley Shields wrote: > > > > > > On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote: > > > > The following reply was made to PR ports/134311; it has been noted by GNATS. > > > > > > > > From: Timothy Beyer <beyert@cs.ucr.edu> > > > > To: bug-followup@FreeBSD.org > > > > Cc: Timothy Beyer <beyert@cs.ucr.edu> > > > > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions >= 7.x > > > > Date: Fri, 08 May 2009 01:37:22 -0700 > > > > > > > > This is a followup that I made in a private email clarifying the > > > > specific details in my report. I apologize for not being more > > > > specific in the first place. > > > > > > > > I'm using UFS2 with softupdates on my filesystem, ACLs enabled. All > > > > of my filesystems are using geli. My shell is tcsh. > > > > > > > > I think I confused everyone when I was refering to 7.x, I mean the > > > > 7.x versions of gnuls, not of FreeBSD. (and for any other version > > > > numbers that I noted, I was referring to versions of gnuls) I would > > > > suspect that any problems I'm having with gnuls would exist on any > > > > version of FreeBSD, but I'm not sure why the old Makefile revision > > > > 1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but > > > > the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls > > > > versions 7.1 and 7.2 do not work properly fo r me. > > > > > > > > Basically, the regular gnuls listing works for any of the newest port > > > > revisions, as well as the old, but the the gnuls -l does not work for > > > > the newest two port revisions. > > > > > > > > Perhaps my problem is some incompatibility in new gnuls versions with > > > > my chosen filesystem configuration? > > > > > > I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested, > > > I don't have a machine using GELI) and I'm not sure how to proceed from > > > here. Can you look into using truss or ktrace to provide us with more > > > detailed information regarding the problem? > > > > > > -- WXS > > > > Here is the output of truss and gnuls -l on /usr/local/bin. Note that doesn't do anything after __acl_get_file calls. > > > > [beyert@aeonserv.aeonnet] > cd /usr/local/bin/ > > [beyert@aeonserv.aeonnet] > sudo truss /usr/local/bin/gnuls -l > > __sysctl(0xbfbfe864,0x2,0xbfbfe86c,0xbfbfe870,0x0,0x0) = 0 (0x0) > > mmap(0x0,296,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 868827136 (0x33c94000) > > munmap(0x33c94000,296) = 0 (0x0) > > __sysctl(0xbfbfe8c8,0x2,0x33c90e5c,0xbfbfe8d0,0x0,0x0) = 0 (0x0) > > mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868827136 (0x33c94000) > > issetugid(0x33c89f8c,0xbfbfe990,0x104,0x0,0x0,0x0) = 0 (0x0) > > open("/etc/libmap.conf",O_RDONLY,0666) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=24791,size=3766,blksize=4096 }) = 0 (0x0) > > read(3,"# /etc/libmap.conf for FreeBSD 6"...,4096) = 3766 (0xeb6) > > read(3,0x33c98000,4096) = 0 (0x0) > > close(3) = 0 (0x0) > > open("/var/run/ld-elf.so.hints",O_RDONLY,00) = 3 (0x3) > > read(3,"Ehnt\^A\0\0\0\M^@\0\0\0x\^B\0\0"...,128) = 128 (0x80) > > mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868859904 (0x33c9c000) > > lseek(3,0x80,SEEK_SET) = 128 (0x80) > > read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,632) = 632 (0x278) > > close(3) = 0 (0x0) > > access("/lib/libc.so.7",0) = 0 (0x0) > > open("/lib/libc.so.7",O_RDONLY,00) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=16584,size=1058208,blksize=4096 }) = 0 (0x0) > > read(3,"\^?ELF\^A\^A\^A\t\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000) > > mmap(0x0,1056768,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) = 868896768 (0x33ca5000) > > mprotect(0x33d8c000,4096,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0) > > mprotect(0x33d8c000,4096,PROT_READ|PROT_EXEC) = 0 (0x0) > > mmap(0x33d8d000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xe8000) = 869847040 (0x33d8d000) > > mmap(0x33d93000,81920,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 869871616 (0x33d93000) > > close(3) = 0 (0x0) > > sysarch(0xa,0xbfbfe930,0x33c6a21b,0x33c8f814,0x33c7b619,0x33c8f814) = 0 (0x0) > > mmap(0x0,872,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000) > > munmap(0x33da7000,872) = 0 (0x0) > > mmap(0x0,21176,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000) > > munmap(0x33da7000,21176) = 0 (0x0) > > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) > > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > > __sysctl(0xbfbfe8e4,0x2,0x33d93ae0,0xbfbfe8ec,0x0,0x0) = 0 (0x0) > > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) > > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_COLLATE",O_RDONLY,0666) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=950042,size=4642,blksize=4096 }) = 0 (0x0) > > __sysctl(0xbfbfe458,0x2,0x33d978c0,0xbfbfe464,0x0,0x0) = 0 (0x0) > > __sysctl(0xbfbfdf68,0x2,0x33da405c,0xbfbfdf70,0x0,0x0) = 0 (0x0) > > __sysctl(0xbfbfdfb8,0x2,0xbfbfdfc4,0xbfbfdfc8,0x0,0x0) = 0 (0x0) > > readlink("/etc/malloc.conf",0xbfbfe057,1024) ERR#2 'No such file or directory' > > issetugid(0x33d84ec0,0xbfbfe057,0x400,0xbfbfe464,0x0,0x0) = 0 (0x0) > > break(0x8100000) = 0 (0x0) > > __sysctl(0xbfbfe2d4,0x2,0xbfbfe2dc,0xbfbfe2e0,0x0,0x0) = 0 (0x0) > > mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 869953536 (0x33da7000) > > mmap(0x33ea7000,364544,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 871002112 (0x33ea7000) > > munmap(0x33da7000,364544) = 0 (0x0) > > read(3,"1.2\n\0\0\0\0\0\0\0\0\0\^A\0\0\0"...,4096) = 4096 (0x1000) > > read(3,"\0\M-?\0\0\0\0\0\0\0\M-@\0\0\0\0"...,4096) = 546 (0x222) > > close(3) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_CTYPE",O_RDONLY,0666) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0) > > fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0) > > lseek(3,0x0,SEEK_CUR) = 0 (0x0) > > lseek(3,0x0,SEEK_SET) = 0 (0x0) > > read(3,"RuneMag1UTF-8\0\0\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0\0\0\n\M-<\0\0\n\M-E@\^D"...,4096) = 4096 (0x1000) > > read(3,"\0\0\^AJ\0\0\^AJ\0\0\^AK\0\0\^AL"...,4096) = 4096 (0x1000) > > read(3,"\0\0\^_\^O\0\0\^_\0\0\0\^_\^X\0"...,4096) = 4096 (0x1000) > > read(3,"\0\0\^^T\0\0\^^W\0\0\^^W\0\0\^^V"...,4096) = 4096 (0x1000) > > read(3,"@\^D\M^I\0@\^D\^Y\0@\^D\M^I\0@"...,4096) = 4096 (0x1000) > > read(3,"@$\b\0@$\b\0@$\b\0@$\b\0@$\b\0@$"...,4096) = 4096 (0x1000) > > read(3,"@\^D(\0@\^D(\0@\^D(\0@\^D(\0@\^D"...,4096) = 4096 (0x1000) > > read(3,"\M^@$\b\0\M^@$\b\0\M^@$\b\0\M^@$"...,4096) = 4096 (0x1000) > > read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000) > > read(3,"@\^D\M^I\0@\^D\M^I\0@\^D\M^I\0@"...,4096) = 2404 (0x964) > > close(3) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_MONETARY",O_RDONLY,06370000000) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=974091,size=34,blksize=4096 }) = 0 (0x0) > > read(3,"USD \n$\n.\n,\n3;3\n\n-\n2\n2\n1"...,34) = 34 (0x22) > > close(3) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_NUMERIC",O_RDONLY,042) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=975978,size=8,blksize=4096 }) = 0 (0x0) > > read(3,".\n,\n3;3\n",8) = 8 (0x8) > > close(3) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_TIME",O_RDONLY,010) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=976068,size=377,blksize=4096 }) = 0 (0x0) > > read(3,"Jan\nFeb\nMar\nApr\nMay\nJun\nJu"...,377) = 377 (0x179) > > close(3) = 0 (0x0) > > open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES",O_RDONLY,0571) = 3 (0x3) > > fstat(3,{ mode=-r--r--r-- ,inode=975871,size=18,blksize=4096 }) = 0 (0x0) > > read(3,"^[yYsS].*\n^[nN].*\n",18) = 18 (0x12) > > close(3) = 0 (0x0) > > ioctl(1,TIOCGETA,0xbfbfea38) = 0 (0x0) > > ioctl(1,TIOCGWINSZ,0xbfbfeaa8) = 0 (0x0) > > stat(".",{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0) > > open(".",O_NONBLOCK,06) = 3 (0x3) > > fstat(3,{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0) > > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) > > fstatfs(0x3,0xbfbfe6a4,0x1,0x2,0x1,0x33c8fe14) = 0 (0x0) > > getdirentries(0x3,0x33e18000,0x1000,0x33e010e4,0x0,0x33c96200) = 4096 (0x1000) > > lstat("lua50",{ mode=drwxr-xr-x ,inode=927745,size=512,blksize=4096 }) = 0 (0x0) > > __acl_get_file(0xbfbfe770,0x0,0x33e0c240,0xbfbfe770,0x33e12008,0x33e12000) = 0 (0x0) > > __acl_get_file(0xbfbfe770,0x1,0x33e0c240,0x33cfcb81,0x2d,0x33e0c240) = 0 (0x0) > > Does this happen on every directory or just this particular one? Can you > give me the output of ls -l for any particular directory which causes > the problem and any ACLs set in there? > > Thanks! > > -- WXS To add to my previous comment: Having tried it on /usr/bin right now, when the directory is not given as a parameter, it terminates properly. That is the only directory that works properly, thus far. Tim
On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote: > To add to my previous comment: > > Having tried it on /usr/bin right now, when the directory is not > given as a parameter, it terminates properly. That is the only > directory that works properly, thus far. I've just now been able to reproduce this problem. I completely forgot that I wasn't mounting my test volume with the acls option. Sorry about that. I've also noticed that there are newer versions of gnuls released since then. The latest (7.4) appears to solve this problem. I've attached a patch to update the port and would like Brian's approval to commit it. To satisfy my own curiosity, what is the reason for using gnuls over the base ls? Is there some option the base one does not provide? -- WXS
On 6/22/09 10:10 AM, Wesley Shields wrote: > On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote: >> To add to my previous comment: >> >> Having tried it on /usr/bin right now, when the directory is not >> given as a parameter, it terminates properly. That is the only >> directory that works properly, thus far. > > I've just now been able to reproduce this problem. I completely forgot > that I wasn't mounting my test volume with the acls option. Sorry about > that. > > I've also noticed that there are newer versions of gnuls released since > then. The latest (7.4) appears to solve this problem. I've attached a > patch to update the port and would like Brian's approval to commit it. > > To satisfy my own curiosity, what is the reason for using gnuls over the > base ls? Is there some option the base one does not provide? I created the gnuls port years ago (more than a decade), when I started using FreeBSD. I'd already been using Linux. I was accustomed to GNU ls on Linux--in particular, its specific way of configuring colorization. I wanted consistency between Linux and FreeBSD, so I created a port. That's really the only reason the port exists at all. -- -Brian Brian Clapper, http://www.clapper.org/bmc/ Life is a whim of several billion cells to be you for a while.
On Mon, Jun 22, 2009 at 10:23:14AM -0400, Brian Clapper wrote: > On 6/22/09 10:10 AM, Wesley Shields wrote: > > On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote: > >> To add to my previous comment: > >> > >> Having tried it on /usr/bin right now, when the directory is not > >> given as a parameter, it terminates properly. That is the only > >> directory that works properly, thus far. > > > > I've just now been able to reproduce this problem. I completely forgot > > that I wasn't mounting my test volume with the acls option. Sorry about > > that. > > > > I've also noticed that there are newer versions of gnuls released since > > then. The latest (7.4) appears to solve this problem. I've attached a > > patch to update the port and would like Brian's approval to commit it. > > > > To satisfy my own curiosity, what is the reason for using gnuls over the > > base ls? Is there some option the base one does not provide? > > I created the gnuls port years ago (more than a decade), when I started using > FreeBSD. I'd already been using Linux. I was accustomed to GNU ls on Linux--in > particular, its specific way of configuring colorization. I wanted consistency > between Linux and FreeBSD, so I created a port. That's really the only reason > the port exists at all. Fair enough. I'm not questioning the existence of the port, but am mostly interested in why Timothy was using it specifically. If there is a glaringly obvious deficiency in our ls we may want to address that. In any case, the patch appears to fix the problem by updating to a new version. Can you approve it? -- WXS
wxs 2009-06-22 14:49:51 UTC FreeBSD ports repository Modified files: misc/gnuls Makefile distinfo Log: - Update to 7.4 which should solve the ACL issue. PR: ports/134311 Submitted by: Timothy Beyer <beyert@cs.ucr.edu> Approved by: Brian Clapper <bmc@clapper.org> (maintainer) Revision Changes Path 1.26 +1 -1 ports/misc/gnuls/Makefile 1.12 +3 -3 ports/misc/gnuls/distinfo _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: feedback->closed Updated to 7.4 which solves this problem. Thanks for your patience!
At Mon, 22 Jun 2009 10:10:47 -0400, Wesley Shields wrote: > > [1 <text/plain; us-ascii (7bit)>] > On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote: > > To add to my previous comment: > > > > Having tried it on /usr/bin right now, when the directory is not > > given as a parameter, it terminates properly. That is the only > > directory that works properly, thus far. > > I've just now been able to reproduce this problem. I completely forgot > that I wasn't mounting my test volume with the acls option. Sorry about > that. > > I've also noticed that there are newer versions of gnuls released since > then. The latest (7.4) appears to solve this problem. I've attached a > patch to update the port and would like Brian's approval to commit it. > > To satisfy my own curiosity, what is the reason for using gnuls over the > base ls? Is there some option the base one does not provide? > > -- WXS Oh, The only reason why I cared about gnuls at all was because dired, at least in XEmacs only works with it, you have to modify the regular expressions to get bsd ls working. However, I wrote my only replacement for dired which uses my own "ls" program, as well as bsd ls, so it is no longer an issue. I just thought that it would be nice to report the problem. I actually don't use gnuls at all anymore, since bsd ls has all the same features, approximately the same performance profile, and a better license. Tim
At Mon, 22 Jun 2009 10:26:20 -0400, Wesley Shields wrote: > > On Mon, Jun 22, 2009 at 10:23:14AM -0400, Brian Clapper wrote: > > On 6/22/09 10:10 AM, Wesley Shields wrote: > > > On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote: > > >> To add to my previous comment: > > >> > > >> Having tried it on /usr/bin right now, when the directory is not > > >> given as a parameter, it terminates properly. That is the only > > >> directory that works properly, thus far. > > > > > > I've just now been able to reproduce this problem. I completely forgot > > > that I wasn't mounting my test volume with the acls option. Sorry about > > > that. > > > > > > I've also noticed that there are newer versions of gnuls released since > > > then. The latest (7.4) appears to solve this problem. I've attached a > > > patch to update the port and would like Brian's approval to commit it. > > > > > > To satisfy my own curiosity, what is the reason for using gnuls over the > > > base ls? Is there some option the base one does not provide? > > > > I created the gnuls port years ago (more than a decade), when I started using > > FreeBSD. I'd already been using Linux. I was accustomed to GNU ls on Linux--in > > particular, its specific way of configuring colorization. I wanted consistency > > between Linux and FreeBSD, so I created a port. That's really the only reason > > the port exists at all. > > Fair enough. I'm not questioning the existence of the port, but am > mostly interested in why Timothy was using it specifically. If there is > a glaringly obvious deficiency in our ls we may want to address that. > No deficiencies, although it would be nice to have more control over the way dates are formatted in bsd ls. The performance of the both is generally so good that I don't think that performance is a compelling advantage for gnuls. For what it's worth, I no longer use gnuls. (see my other response) > In any case, the patch appears to fix the problem by updating to a new > version. Can you approve it? > > -- WXS
At Mon, 22 Jun 2009 10:26:20 -0400, Wesley Shields wrote: > > On Mon, Jun 22, 2009 at 10:23:14AM -0400, Brian Clapper wrote: > > On 6/22/09 10:10 AM, Wesley Shields wrote: > > > On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote: > > >> To add to my previous comment: > > >> > > >> Having tried it on /usr/bin right now, when the directory is not > > >> given as a parameter, it terminates properly. That is the only > > >> directory that works properly, thus far. > > > > > > I've just now been able to reproduce this problem. I completely forgot > > > that I wasn't mounting my test volume with the acls option. Sorry about > > > that. > > > > > > I've also noticed that there are newer versions of gnuls released since > > > then. The latest (7.4) appears to solve this problem. I've attached a > > > patch to update the port and would like Brian's approval to commit it. > > > > > > To satisfy my own curiosity, what is the reason for using gnuls over the > > > base ls? Is there some option the base one does not provide? > > > > I created the gnuls port years ago (more than a decade), when I started using > > FreeBSD. I'd already been using Linux. I was accustomed to GNU ls on Linux--in > > particular, its specific way of configuring colorization. I wanted consistency > > between Linux and FreeBSD, so I created a port. That's really the only reason > > the port exists at all. > > Fair enough. I'm not questioning the existence of the port, but am > mostly interested in why Timothy was using it specifically. If there is > a glaringly obvious deficiency in our ls we may want to address that. > > In any case, the patch appears to fix the problem by updating to a new > version. Can you approve it? > > -- WXS Also, thanks for the effort you and Brian have put into this, I am glad to see a solution to the problem in sight. Mostly because if gnuls isn't working properly, it might turn off Linux users from FreeBSD, more than anything else. Tim