Re: ls flag to show number of hard links
On Tue, 9 Apr 2024, Tony Freeman wrote: I seem to recall that some years ago ls -l would show the number of hard links to a file. Yes with "ls -l" it's the first number you see (after the permissions string). Or you can use "stat -c %h filename" to just grab that number specifically. Carl
ls flag to show number of hard links
I seem to recall that some years ago ls -l would show the number of hard links to a file. This may have been on an AIX system. I needed to use this today on a red hat 8 machine but couldn't figure it out. So I used ls -i | sort Am I overlooking a flag to ls that would show me the number of hard links?
bug#35247: [PATCH] Add alacritty to terminal list supporting colors
I am not trying to spam this mailing list, but I received several DMARC reports after sending the previous mail (never happened to me before, no idea why). So I am trying again from a different domain, in case the email wasn't received at all. Sorry for the inconvenience. Regards Eike Gebauer On 28/03/2024 17:58, Eike Gebauer wrote: By now alacritty has been packaged for Fedora for quite a while (https://packages.fedoraproject.org/pkgs/rust-alacritty/alacritty/) and is used by a relatively large community (>50k Stars on Github). The corresponding issue on the alacritty side has sadly been closed as "wontfix" (https://github.com/alacritty/alacritty/issues/2210), so I would like to ask you to add `TERM alacritty` to dircolors.hin instead, as originally requested by Doron Behar. Regards, Eike PS I did not find a way to reply to the old thread from the mailing list archive with the correct `In-Reply-To` header, so this might not be threaded correctly with the original messages from 2019. On Sat, 11 May 2019 16:57:40 +0300, Doron Behar wrote: > Well I'm not a developer of alacritty, just a humble user. I had only > taken the effort to investigate why I dircolors wouldn't define colors > for me when in this terminal. > > Under it's installation section of the README, listed the supported > packages for the various distros: > > https://github.com/jwilm/alacritty#installation > > On Fri, May 10, 2019 at 08:24:09AM -0700, Pádraig Brady wrote:On 28/03/2024 17:34, bug-coreutils-requ...@gnu.org wrote: > > On 12/04/19 12:20, address@hidden wrote: > > > From: Doron Behar > > > > > > https://github.com/jwilm/alacritty > > > --- > > > src/dircolors.hin | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/src/dircolors.hin b/src/dircolors.hin > > > index 3aa445bfa..424ed5b19 100644 > > > --- a/src/dircolors.hin > > > +++ b/src/dircolors.hin > > > @@ -12,6 +12,7 @@ > > > # against the TERM environment variable to determine if it is colorizable. > > > TERM Eterm > > > TERM ansi > > > +TERM alacritty > > > TERM *color* > > > TERM con[0-9]*x[0-9]* > > > TERM cons25 > > > > > > > I don't see this terminal packaged for Feodra at least. > > Why does it need its own TERM ? > > If it does, could one add 'color' to get the existing matching? > > > > thanks, > > Pádraig
bug#70298: uname -i returns unknown since fedora 38
On 09/04/2024 10:17, Collin Funk wrote: On 4/9/24 12:57 AM, Paul Eggert wrote: Indeed there is, and I merged your bug report into that old one. It'd be nice if someone could get to the bottom of that bug. I decided to look into this a bit, since I also have an unknown 'uname -i' and 'uname -p'. It seems that this option is a Solaris thing. I found the commit that it was introduced [1]. It also adds some other Solaris compatibility stuff, so everything seems to add up so far. The first function it tries is sysinfo (SI_PLATFORM, ...) which seems to be a Solaris thing [2]. I think Linux has sysinfo but not SI_PLATFORM. Then it tries sysctl (...) with a UNAME_HARDWARE_PLATFORM macro to deal with the BSDs. I think OpenBSD might be missing that definition in the #ifdef, but I have no way of testing it at the moment [3]. I'm not sure if 'uname -i', 'uname -p', or 'uname -m' are supposed to be any different from each other. Maybe someone who knows Solaris can help more? Illumios defines 'sysinfo' as an alias to 'systeminfo' [4]. There it returns an 'extern char *platform' in the given buffer when passed SI_PLATFORM [5]. I've found the definition of the variable, but I don't know where it is actually set to something useful [6]. Hopefully that information helps someone... [1] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=aaeb7a61c4662fd28cf2bc161b740352711538d2 [2] https://github.com/illumos/illumos-gate/blob/cf618897f43ea305e3a426f93bbcef4e8106829c/usr/src/uts/common/sys/systeminfo.h#L86 [3] https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/uname.c#n36 [4] https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/common/sys/sysinfo.S [5] https://github.com/illumos/illumos-gate/blob/cf618897f43ea305e3a426f93bbcef4e8106829c/usr/src/uts/common/syscall/systeminfo.c#L124 [6] https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/conf/param.c#L533 Thanks for looking at this. From the Fedora side, they dropped a Fedora specific patch for Fedora 38. https://bugzilla.redhat.com/show_bug.cgi?id=548834 https://bugzilla.redhat.com/show_bug.cgi?id=2208048 cheers, Pádraig.
bug#70298: uname -i returns unknown since fedora 38
On 4/9/24 12:57 AM, Paul Eggert wrote: > Indeed there is, and I merged your bug report into that old one. It'd be nice > if someone could get to the bottom of that bug. I decided to look into this a bit, since I also have an unknown 'uname -i' and 'uname -p'. It seems that this option is a Solaris thing. I found the commit that it was introduced [1]. It also adds some other Solaris compatibility stuff, so everything seems to add up so far. The first function it tries is sysinfo (SI_PLATFORM, ...) which seems to be a Solaris thing [2]. I think Linux has sysinfo but not SI_PLATFORM. Then it tries sysctl (...) with a UNAME_HARDWARE_PLATFORM macro to deal with the BSDs. I think OpenBSD might be missing that definition in the #ifdef, but I have no way of testing it at the moment [3]. I'm not sure if 'uname -i', 'uname -p', or 'uname -m' are supposed to be any different from each other. Maybe someone who knows Solaris can help more? Illumios defines 'sysinfo' as an alias to 'systeminfo' [4]. There it returns an 'extern char *platform' in the given buffer when passed SI_PLATFORM [5]. I've found the definition of the variable, but I don't know where it is actually set to something useful [6]. Hopefully that information helps someone... [1] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=aaeb7a61c4662fd28cf2bc161b740352711538d2 [2] https://github.com/illumos/illumos-gate/blob/cf618897f43ea305e3a426f93bbcef4e8106829c/usr/src/uts/common/sys/systeminfo.h#L86 [3] https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/uname.c#n36 [4] https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/common/sys/sysinfo.S [5] https://github.com/illumos/illumos-gate/blob/cf618897f43ea305e3a426f93bbcef4e8106829c/usr/src/uts/common/syscall/systeminfo.c#L124 [6] https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/conf/param.c#L533 Collin
bug#70298: uname -i returns unknown since fedora 38
On 2024-04-08 10:59, Ondrej Mejzlik wrote: The command uname returns "unknown" on Fedora 38,39 and probably 40. There is a similar very old bug here which has not been fixed https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34905 Indeed there is, and I merged your bug report into that old one. It'd be nice if someone could get to the bottom of that bug.
