When I use "ls -al" on a directory, for files with only owner read/write permission, the displayed attributes are "-rw-", not "-rw-------". That means the file names don't line up with other files in the directory, which makes the listing harder to read. What changed where and how do I fix that?
Am 25.10.2019 um 23:44 schrieb Kenneth Porter:
When I use "ls -al" on a directory, for files with only owner read/write permission, the displayed attributes are "-rw-", not "-rw-------". That means the file names don't line up with other files in the directory, which makes the listing harder to read. What changed where and how do I fix that?
Hm?
[adalloz@centos8 ~]$ touch foo [adalloz@centos8 ~]$ chmod u=rw,go= foo [adalloz@centos8 ~]$ ls -Al insgesamt 12 -rw-r--r--. 1 adalloz adalloz 18 11. Mai 02:16 .bash_logout -rw-r--r--. 1 adalloz adalloz 141 11. Mai 02:16 .bash_profile -rw-r--r--. 1 adalloz adalloz 312 11. Mai 02:16 .bashrc -rw-------. 1 adalloz adalloz 0 26. Okt 00:02 foo [adalloz@centos8 ~]$ LANG=C stat foo File: foo Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd02h/64770d Inode: 788575 Links: 1 Access: (0600/-rw-------) Uid: ( 1000/ adalloz) Gid: ( 1000/ adalloz) Context: unconfined_u:object_r:user_home_t:s0 Access: 2019-10-26 00:02:37.707079231 +0200 Modify: 2019-10-26 00:02:37.707079231 +0200 Change: 2019-10-26 00:04:26.920196480 +0200 Birth: -
Not sure what you were doing.
Alexander
--On Saturday, October 26, 2019 1:07 AM +0200 Alexander Dalloz ad+lists@uni-x.org wrote:
Not sure what you were doing.
An example:
[root@rocinante ~]# ls -al total 76 dr-xr-x---. 8 root root 4096 Oct 25 14:37 . dr-xr-xr-x. 18 root root 4096 Oct 21 09:36 .. -rw-. 1 root root 1481 Oct 24 10:35 .bash_history -rw-r--r--. 1 root root 18 May 11 08:33 .bash_logout -rw-r--r--. 1 root root 176 May 11 08:33 .bash_profile -rw-r--r--. 1 root root 176 May 11 08:33 .bashrc
[more output follow]
Note the permissions on .bash_history.
It seems to be system-wide as it also happens when I use a mortal (non-root) account.
Found it. It happens from the process buffer inside Lugaru Epsilon. I think ls thinks it's doing a DIRED output instead of a shell output. Now I need to figure out why it thinks that. This wasn't happening in CentOS 7.
--On Friday, October 25, 2019 6:13 PM -0700 Kenneth Porter shiva@sewingwitch.com wrote:
Found it. It happens from the process buffer inside Lugaru Epsilon. I think ls thinks it's doing a DIRED output instead of a shell output. Now I need to figure out why it thinks that. This wasn't happening in CentOS 7.
I'm puzzled. I can't find anything in the Gnu coreutils manual to describe this format. I do note that outside Epsilon, the sort order changes, ignoring leading dots and the case of filenames. So it seems like a locale thing.
https://www.gnu.org/software/coreutils/manual/coreutils.html#Directory-listing
Notable environment variable differences:
Outside, LS_COLORS has a very long string. LANG=en_US.UTF-8. TERM=xterm.
Inside, LS_COLORS is present but empty. LANG=C. TERM=dumb.
Changing these doesn't seem to fix the abbreviated permissions field. Setting LANG does change the sort order so at least I understand that.
I may have to pull the coreutils-8.30-6.el8.x86_64 sources to see how ls makes these decisions.
--On Friday, October 25, 2019 6:39 PM -0700 Kenneth Porter shiva@sewingwitch.com wrote:
I may have to pull the coreutils-8.30-6.el8.x86_64 sources to see how ls makes these decisions.
I pulled the coreutils SRPM and it won't build because it wants texinfo and dnf says it doesn't exist, using either the builddep or search subcommands. (There may be other builddep issues but texinfo is notable for being in the vault's SRPMs but not on the mirrors.)
I think the problem likes in the strmode API used in ls.c and it seems like that comes from libbsd, but I can't be sure until I get a workable build tree so the coreutils SRPM will install.
BTW, another data point: I chmod'd a file to 0000 and now all I get is "-." for the mode string. It completely chops everything but the file type and the ACL indicator. OTOH, if I set it to 0660, I get the full string. It doesn't truncate the last octet.
[ken@rocinante src]$ chmod 0000 yes.c [ken@rocinante src]$ ls -l yes.c -. 1 ken ken 3895 May 13 2018 yes.c [ken@rocinante src]$ chmod 0006 yes.c [ken@rocinante src]$ ls -al yes.c -rw-. 1 ken ken 3895 May 13 2018 yes.c [ken@rocinante src]$ chmod 0060 yes.c [ken@rocinante src]$ ls -al yes.c ----rw----. 1 ken ken 3895 May 13 2018 yes.c [ken@rocinante src]$ chmod 0600 yes.c [ken@rocinante src]$ ls -al yes.c -rw-. 1 ken ken 3895 May 13 2018 yes.c
--On Friday, October 25, 2019 8:18 PM -0700 Kenneth Porter shiva@sewingwitch.com wrote:
I pulled the coreutils SRPM and it won't build because it wants texinfo and dnf says it doesn't exist, using either the builddep or search subcommands. (There may be other builddep issues but texinfo is notable for being in the vault's SRPMs but not on the mirrors.)
A source package for texinfo exists here:
http://archive.kernel.org/centos-vault/8.0.1905/BaseOS/Source/SPackages/
I see no binary package for it here:
https://mirrors.edge.kernel.org/centos/8.0.1905/BaseOS/x86_64/os/Packages/
I tried "dnf builddep" on the texinfo source package and it wants help2man. I can't find either a source or binary package for that. (I see one in the CentOS 7 repo.)
Another missing dependency is 'perl(Unicode::EastAsianWidth)'. dnf can't find a package that supplies that.
(The end goal is to figure out where ls.c is getting an implementation of strmode() which is doing weird things, truncating the mode string when the user or group field is zero.)
I figured it out. The missing dependencies are in the PowerTools repo, which is disabled by default. The following command worked:
dnf builddep --enablerepo=PowerTools coreutils-8.30-6.el8.src.rpm
Now to resume working on the ls bug...
-
Alexander Dalloz -
Kenneth Porter