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 at centos8 ~]$ touch foo [adalloz at centos8 ~]$ chmod u=rw,go= foo [adalloz at 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 at 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 at uni-x.org> wrote:> Not sure what you were doing.An example: [root at 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.
Stephen John Smoogen
2019-Oct-26 15:05 UTC
[CentOS] ls permissions format changed in CentOS 8
On Fri, 25 Oct 2019 at 20:14, Kenneth Porter <shiva at 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. >Lugaru Epsilon? I think you need to give a lot more explanation on what is going on because I (at least) have no idea how you are using a non-shipped text editor . Usually if a tool is not giving similar results... I usually start by setting up a new account and unset all SHELL variables in said account. I then see if the problem occurs. If it doesn't, I make changes one by one from the other shells variables to see if it does. [Well I probably do the Wise Old Owl from the tootsy pop commercial.. once I hit three I start moving files until I get it.. sometimes it turns out that it is some weird config setting I didn't know in a file I didn't think would affect things.] I am going to expect that TERM=DUMB might be the problem.. but not sure.> _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos-- Stephen J Smoogen.
It's not a ls bug. I've stepped through the code with gdb and it looks just fine. At this point I think Epsilon (a 32-bit app) is corrupting the image of its child process in a strange way. I'm working with the author at Lugaru (who's very responsive) to track it down. He couldn't reproduce it right away. I just reproduced it on a virgin CentOS 8 image at Linode with utterly no modifications. I just spun up the VM, logged in, scp'd the Epsilon RPM, dnf installed it, and demonstrated the issue. I extracted the formatting code from the ls source to create a short test program that doesn't rely on anything external like a file's actual modes. It's just the code that builds the string from the mode word. It looks like it mysteriously skips the middle of the routine for no reason when spawned either as a grandchild through bash or directly via whatever Epsilon uses to spawn a child process. It's definitely a spooky Halloween bug!