Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #51042 > unrolled thread

Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc

Back to article view | Back to alt.os.linux

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Java Jive <java@evij.com.invalid> - 2018-10-01 20:25 +0100
    Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Java Jive <java@evij.com.invalid> - 2018-10-01 20:42 +0100
    Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc "J.O. Aho" <user@example.net> - 2018-10-01 21:50 +0200
    Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Jasen Betts <jasen@xnet.co.nz> - 2018-10-01 19:51 +0000
    Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Theo <theom+news@chiark.greenend.org.uk> - 2018-10-02 10:25 +0100
      Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Martin Gregorie <martin@mydomain.invalid> - 2018-10-02 10:44 +0000
    Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc J G Miller <miller@yoyo.org> - 2018-12-28 22:04 +0000
      Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Eef Hartman <E.J.M.Hartman@gmail.com> - 2018-12-29 01:13 +0000
    Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc "Carlos E.R." <robin_listas@es.invalid> - 2018-12-29 03:54 +0100
      Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Martin Gregorie <martin@mydomain.invalid> - 2019-02-08 18:53 +0000
        Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Mike Easter <MikeE@ster.invalid> - 2019-02-08 11:20 -0800
          Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Mike Easter <MikeE@ster.invalid> - 2019-02-08 12:15 -0800
          Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Martin Gregorie <martin@mydomain.invalid> - 2019-02-08 20:54 +0000
            Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Mike Easter <MikeE@ster.invalid> - 2019-02-08 13:02 -0800
            Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Pedro Valdez <pedro1492@lycos.com> - 2019-02-10 03:46 -0800
              Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Paul <nospam@needed.invalid> - 2019-02-10 08:23 -0500
        Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc "Carlos E.R." <robin_listas@es.invalid> - 2019-02-09 05:43 +0100
        Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Joe Beanfish <joebeanfish@nospam.duh> - 2019-02-11 14:58 +0000
          Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc Paul <nospam@needed.invalid> - 2019-02-11 11:56 -0500

#51042 — Re: How, in a script, to differentiate between Ubuntu and XUbuntu, LUbuntu, etc

Sorry, meant to post this to a different Linux group, and cross-post it 
to another, but having posted it here, might as well continue. 
Apologies for those who see this twice ...

As per subject, the usual methods of determining the distro don't give 
very useful info.  I can work out the release easily enough ...

	RELEASE="$(lsb_release -r -s | awk -F '.' '{print $1}')"

... but differentiating between Ubuntu and, say, XUbuntu, is not easy, 
and this makes it very difficult to write a script that customises the 
login screen, etc:

XUbuntu 14 & 18:

	lsb_release -i -s
	Ubuntu

	uname -a
	(ubuntu again)

	cat /etc/*-release
	(ubuntu again)

	cat /proc/version
	(ubuntu again)

Both Ubuntu in an Xfce session and XUbuntu have "About Xfce" in the main 
menu, so that's no good either.  XUbuntu 14 has a couple of XUbuntu 
entries in the menu, but they're not there on XUbuntu 18, so again that 
fails.

Er, what do I try now?

[toc] | [next] | [standalone]

#51043

On 01/10/2018 20:25, Java Jive wrote:
> 
> As per subject, the usual methods of determining the distro don't give 
> very useful info.  I can work out the release easily enough ...
> 
>      RELEASE="$(lsb_release -r -s | awk -F '.' '{print $1}')"
> 
> ... but differentiating between Ubuntu and, say, XUbuntu, is not easy, 
> and this makes it very difficult to write a script that customises the 
> login screen, etc:

This seems to work:

DISTRO="$(grep -i cdrom /etc/apt/sources.list | sed -r 
's~^#deb\s+cdrom:\[([A-Za-z]+)\s+.*$~\1~')"

[toc] | [prev] | [next] | [standalone]

#51044

On 10/1/18 9:25 PM, Java Jive wrote:

> As per subject, the usual methods of determining the distro don't give
> very useful info.  I can work out the release easily enough ...
> 
>     RELEASE="$(lsb_release -r -s | awk -F '.' '{print $1}')"
> 
> ... but differentiating between Ubuntu and, say, XUbuntu, is not easy,
> and this makes it very difficult to write a script that customises the
> login screen, etc:
> 
> XUbuntu 14 & 18:
> 
>     lsb_release -i -s
>     Ubuntu

As I don't use ubunt/xubuntu, but you could try with "lsb_release -d"
and see if you get a bit more information from there that you can
distinguish xubuntu from ubuntu, of course this string may look
completely different between releases/distros that it may be not
possible to make a simple sed/awk to get the data you want.


>     uname -a
>     (ubuntu again)
> 
>     cat /etc/*-release
>     (ubuntu again)
> 
>     cat /proc/version
>     (ubuntu again)

This should be the same as you do get with uname.


> Both Ubuntu in an Xfce session and XUbuntu have "About Xfce" in the main
> menu, so that's no good either.  XUbuntu 14 has a couple of XUbuntu
> entries in the menu, but they're not there on XUbuntu 18, so again that
> fails.
> 
> Er, what do I try now?

Look at the repository for the packages (apt), there should be one for
xubuntu specific packages which should be lacking for ubuntu.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#51045

On 2018-10-01, Java Jive <java@evij.com.invalid> wrote:
> Sorry, meant to post this to a different Linux group, and cross-post it 
> to another, but having posted it here, might as well continue. 
> Apologies for those who see this twice ...
>
> As per subject, the usual methods of determining the distro don't give 
> very useful info.  I can work out the release easily enough ...
>
> 	RELEASE="$(lsb_release -r -s | awk -F '.' '{print $1}')"

Yeah they are all re-badged ubuntu.

There's probably something in /etc/alternatives (look at where the
links point, of course this is reconfigurable)

 readlink /etc/alternatives/x-session-manager  

might be a good start.

Or you could look for comments (or entries for physical media) at the head of /etc/apt/sources-list 




-- 
     ت

[toc] | [prev] | [next] | [standalone]

#51049

In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
> Both Ubuntu in an Xfce session and XUbuntu have "About Xfce" in the main 
> menu, so that's no good either.  XUbuntu 14 has a couple of XUbuntu 
> entries in the menu, but they're not there on XUbuntu 18, so again that 
> fails.

Look for the presence of ubuntu-desktop, xubuntu-desktop, kubuntu-desktop,
etc packages.

Since it's all the same distro underneath, the user is free to install
multiple desktops on the same machine so you might have more than one.  If
you don't, it indicates what system was originally installed.  But each
'spin' is mostly about setting the list of default installed packages, so a
system can drift away from that list over time.

Theo

[toc] | [prev] | [next] | [standalone]

#51050

On Tue, 02 Oct 2018 10:25:18 +0100, Theo wrote:

> In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
>> Both Ubuntu in an Xfce session and XUbuntu have "About Xfce" in the
>> main menu, so that's no good either.  XUbuntu 14 has a couple of
>> XUbuntu entries in the menu, but they're not there on XUbuntu 18, so
>> again that fails.
> 
> Look for the presence of ubuntu-desktop, xubuntu-desktop,
> kubuntu-desktop, etc packages.
> 
> Since it's all the same distro underneath, the user is free to install
> multiple desktops on the same machine so you might have more than one. 
> If you don't, it indicates what system was originally installed.  But
> each 'spin' is mostly about setting the list of default installed
> packages, so a system can drift away from that list over time.
> 
The main differences I've noticed are the maintenance package (apt vs dnf)
and the archive format used.

It would be nice if there was a bit more commonality between desktops, 
though, especially when you look at the shedload of similar packages each 
of them seems to want to clutter your filing system with <cough>..<cough> 
kde <cough>
 

-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#52139

On Monday, October 1st, 2018, at 20:25:22h +0100, Java Jive wrote:

> ... but differentiating between Ubuntu and, say, XUbuntu, is not easy,

Indeed not, because they are both Ubuntu and the real difference is
between which desktop (window manager + associated widget related
packages) are installed.

However, the packagers of the different flavors usually go to a lot
of trouble in identifying their particular flavor for the grub menu
(because if you have various GNU/Linux flavors installed you need to be able to
easily see which one is Gnome, KDE, XFCE, Edubuntu, Mint, 32bit or 64 bit
you are selecting to boot) so you could check the menuentry items in
/boot/grub/grub.cfg for specific identifiers.

Do not forget that grub.cfg is actually created from the various components
in /etc/grub.d/* when grub-update is run, so it could be useful to look at
the scripts, particularly 10_linux or any earlier numbered one specific to
ubuntu (or flavor thereof) there to get an idea of how to uniquely identify
the system flavor.

[toc] | [prev] | [next] | [standalone]

#52143

In alt.comp.os.linux J G Miller <miller@yoyo.org> wrote:
> On Monday, October 1st, 2018, at 20:25:22h +0100, Java Jive wrote:
>> ... but differentiating between Ubuntu and, say, XUbuntu, is not easy,
> 
> Indeed not, because they are both Ubuntu and the real difference is
> between which desktop (window manager + associated widget related
> packages) are installed.

As the _default_ DE, it is well possible to install multiple DE's.
I.e. on my system I'v got xfce as default but kde as fall-back.
In fact I use the Kde Display Manager (kdm) to start either of them,
the default being set in the file $HOME/.dmrc

[toc] | [prev] | [next] | [standalone]

#52145

On 01/10/2018 21.25, Java Jive wrote:
> Sorry, meant to post this to a different Linux group, and cross-post it
> to another, but having posted it here, might as well continue. Apologies
> for those who see this twice ...
> 
> As per subject, the usual methods of determining the distro don't give
> very useful info.  I can work out the release easily enough ...
> 

...

>     cat /etc/*-release
>     (ubuntu again)

This is the cross-distribution current method, parsing /etc/os-release.
If all those *buntu flavours yield the same result, it is because they
are intended to be the same distribution. What desktop they use by
default is irrelevant.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#53684

On Sat, 29 Dec 2018 03:54:36 +0100, Carlos E.R. wrote:

> This is the cross-distribution current method, parsing /etc/os-release.
> If all those *buntu flavours yield the same result, it is because they
> are intended to be the same distribution. What desktop they use by
> default is irrelevant.

Does parsing /proc/version do any better? 

It looks potentially useful for Fedora, where it shows the Fedora version 
and build as well as the kernel version, so probably distinguishes it 
from RHEL, but totally useless for RaspberryPi, where it only shows the 
kernel version.

FWIW both also identify the gcc version .
 

-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#53688

Martin Gregorie wrote:
> Carlos E.R. wrote:
> 
>> This is the cross-distribution current method, parsing /etc/os-release.
>> If all those *buntu flavours yield the same result, it is because they
>> are intended to be the same distribution. What desktop they use by
>> default is irrelevant.
> 
> Does parsing /proc/version do any better?
> 
> It looks potentially useful for Fedora, where it shows the Fedora version
> and build as well as the kernel version, so probably distinguishes it
> from RHEL, but totally useless for RaspberryPi, where it only shows the
> kernel version.
> 
> FWIW both also identify the gcc version .
>   
You could dissect/examine/parse the inxi script to see what its System 
option

inxi -S

... uses.  Eg Mint 19.1 Cinnamon:

$ inxi -S
System:
   Host: mint Kernel: 4.15.0-20-generic x86_64 bits: 64
   Desktop: Cinnamon 4.0.8 Distro: Linux Mint 19.1 Tessa


https://github.com/smxi/inxi



-- 
Mike Easter

[toc] | [prev] | [next] | [standalone]

#53689

Mike Easter wrote:
> You could dissect/examine/parse the inxi script to see what its System 
> option
> 
> inxi -S
> 
> ... uses.

Ub 18.04.1 Mate

$ inxi -S
System:    Host: ubuntu-mate Kernel: 4.15.0-29-generic x86_64 bits: 64
            Desktop: MATE 1.20.1  Distro: Ubuntu 18.04.1 LTS

-- 
Mike Easter

[toc] | [prev] | [next] | [standalone]

#53692

On Fri, 08 Feb 2019 11:20:01 -0800, Mike Easter wrote:

> Martin Gregorie wrote:
>> Carlos E.R. wrote:
>> 
>>> This is the cross-distribution current method, parsing
>>> /etc/os-release.
>>> If all those *buntu flavours yield the same result, it is because they
>>> are intended to be the same distribution. What desktop they use by
>>> default is irrelevant.
>> 
>> Does parsing /proc/version do any better?
>> 
>> It looks potentially useful for Fedora, where it shows the Fedora
>> version and build as well as the kernel version, so probably
>> distinguishes it from RHEL, but totally useless for RaspberryPi, where
>> it only shows the kernel version.
>> 
>> FWIW both also identify the gcc version .
>>   
> You could dissect/examine/parse the inxi script to see what its System
> option
> 
> inxi -S
> 
> ... uses.  Eg Mint 19.1 Cinnamon:
> 
> $ inxi -S System:
>    Host: mint Kernel: 4.15.0-20-generic x86_64 bits: 64 Desktop:
>    Cinnamon 4.0.8 Distro: Linux Mint 19.1 Tessa
> 
> 
Its a supported package, 'inxi', for Fedora systems. Installed. Looks 
good.


-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#53694

Martin Gregorie wrote:
> Mike Easter wrote:
> 
>> You could dissect/examine/parse the inxi script to see what its System
>> option
>>
>> inxi -S
>>
>> ... uses. 
>>
> Its a supported package, 'inxi', for Fedora systems. Installed. Looks
> good.
> 

I LUV inxi.

Troubleshooting network inxi -Nni

... even gives the WAN IP.  Of course you could also get that with

curl icanhazip.com

Check out whatall inxi -h offers.


-- 
Mike Easter

[toc] | [prev] | [next] | [standalone]

#53722

On Saturday, February 9, 2019 at 4:54:49 AM UTC+8, Martin Gregorie wrote:
> > 
> Its a supported package, 'inxi', for Fedora systems. Installed. Looks 
> good.

In Suse, you have to install hddtemp and Mesa-demo-x to get inxi working.
It's worth it - the only thing it doesn't tell you is how much memory the
graphics card has - seems to be inordinately difficult to uncover.

[toc] | [prev] | [next] | [standalone]

#53723

Pedro Valdez wrote:
> On Saturday, February 9, 2019 at 4:54:49 AM UTC+8, Martin Gregorie wrote:
>> Its a supported package, 'inxi', for Fedora systems. Installed. Looks 
>> good.
> 
> In Suse, you have to install hddtemp and Mesa-demo-x to get inxi working.
> It's worth it - the only thing it doesn't tell you is how much memory the
> graphics card has - seems to be inordinately difficult to uncover.

paul@U1804:~$ inxi -G
Graphics:  Card: NVIDIA GP104 [GeForce GTX 1080]
            Display Server: x11 (X.Org 1.19.6 )
            drivers: nvidia (unloaded: modesetting,fbdev,vesa,nouveau)
            Resolution: 1440x900@59.89hz
            OpenGL: renderer: GeForce GTX 1080/PCIe/SSE2
            version: 4.6.0 NVIDIA 390.48

True. No memory info there.

*******

paul@U1804:~$ glxinfo

Memory info (GL_NVX_gpu_memory_info):
     Dedicated video memory: 8192 MB
     Total available memory: 8192 MB
     Currently available dedicated video memory: 7955 MB
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 1080/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 390.48
OpenGL core profile shading language version string: 4.60 NVIDIA

Now, the reason I knew to look for that, is because Windows
had a problem with OpenGL and a call that tells Windows
how much OpenGL memory was available. The excuse the video
card companies gave, was "Microsoft changed the memory management
model for video cards too many times for us to keep up". So
that reminded me, that the "leverage point" might come
from Mesa3D renderer or the proprietary renderer on the
Linux side.

At least on the above system, glxinfo seems to have the
details. Maybe someone running Nouveau can run that and
tell us what they get when the NVidia driver isn't running.

I think in fact, Nouveau will work too. And my indirect
evidence is, that OpenOffice Calc and chart insertion,
doesn't crash in Linux. Whereas it did in Windows, and
it's because the OpenGL call that indicates memory
remaining, wasn't working right at the time. That's
since been fixed in some version of WDDM video driver package,
although I haven't been re-trying the failure case on
OpenOffice constantly to see whether that's true or not.

    Paul

[toc] | [prev] | [next] | [standalone]

#53700

On 08/02/2019 19.53, Martin Gregorie wrote:
> On Sat, 29 Dec 2018 03:54:36 +0100, Carlos E.R. wrote:
> 
>> This is the cross-distribution current method, parsing /etc/os-release.
>> If all those *buntu flavours yield the same result, it is because they
>> are intended to be the same distribution. What desktop they use by
>> default is irrelevant.
> 
> Does parsing /proc/version do any better? 
> 
> It looks potentially useful for Fedora, where it shows the Fedora version 
> and build as well as the kernel version, so probably distinguishes it 
> from RHEL, but totally useless for RaspberryPi, where it only shows the 
> kernel version.
> 
> FWIW both also identify the gcc version .

On openSUSE it only displays kernel version, in detail:


Linux version 4.12.14-lp150.12.45-default (geeko@buildhost) (gcc version
7.3.1 20180323 [gcc-7-branch revision 258812] (SUSE Linux) ) #1 SMP Mon
Jan 14 20:29:59 UTC 2019 (7a62739)


That it says "SUSE Linux" only means that the kernel says so. It may be
about the machine where the kernel was compiled.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#53746

On Fri, 08 Feb 2019 18:53:24 +0000, Martin Gregorie wrote:

> On Sat, 29 Dec 2018 03:54:36 +0100, Carlos E.R. wrote:
> 
>> This is the cross-distribution current method, parsing /etc/os-release.
>> If all those *buntu flavours yield the same result, it is because they
>> are intended to be the same distribution. What desktop they use by
>> default is irrelevant.
> 
> Does parsing /proc/version do any better? 
> 
> It looks potentially useful for Fedora, where it shows the Fedora version 
> and build as well as the kernel version, so probably distinguishes it 
> from RHEL, but totally useless for RaspberryPi, where it only shows the 
> kernel version.
> 
> FWIW both also identify the gcc version .

Does *buntu have the lsb_release command? Try
   lsb_release -a

[toc] | [prev] | [next] | [standalone]

#53752

Joe Beanfish wrote:
> On Fri, 08 Feb 2019 18:53:24 +0000, Martin Gregorie wrote:
> 
>> On Sat, 29 Dec 2018 03:54:36 +0100, Carlos E.R. wrote:
>>
>>> This is the cross-distribution current method, parsing /etc/os-release.
>>> If all those *buntu flavours yield the same result, it is because they
>>> are intended to be the same distribution. What desktop they use by
>>> default is irrelevant.
>> Does parsing /proc/version do any better? 
>>
>> It looks potentially useful for Fedora, where it shows the Fedora version 
>> and build as well as the kernel version, so probably distinguishes it 
>> from RHEL, but totally useless for RaspberryPi, where it only shows the 
>> kernel version.
>>
>> FWIW both also identify the gcc version .
> 
> Does *buntu have the lsb_release command? Try
>    lsb_release -a

You can see it right on the media. The source file with the info.

ubuntu-18.04.1-desktop-amd64.iso/casper/filesystem.squashfs/etc/
     lsb-release

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS"

When you run it...

$ lsb_release -a

No LSB modules are available.

Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.1 LTS
Release:	18.04
Codename:	bionic

    Paul

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.linux

csiph-web