Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Checking for installed package
6 views
Skip to first unread message
Kip Warner
May 25, 2013, 1:40:01 AM5/25/13
to
Hey list,
I'd like to know the most reliable way for a bash script to verify that
a package is installed on the user's system. I've looked already at
dpkg, dpkg-query, and aptitude. These are the constraints:
1. It needs to work on any stock Debian based system, e.g.
aptitude not always present, so can't rely on it.
2. It needs to be i18n safe, e.g. no reliance on grepping for
"Installed:" output of apt-cache policy <package> because that
is en locale specific.
3. It needs to be able to distinguish a package that is
installed from any other condition with only the former we care
about. That means the exit code, for instance, of the query
should be never be the same for a package that is installed
versus one that is not installed - and not available anywhere.
Any help appreciated.
--
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
I'd like to know the most reliable way for a bash script to verify that
a package is installed on the user's system. I've looked already at
dpkg, dpkg-query, and aptitude. These are the constraints:
1. It needs to work on any stock Debian based system, e.g.
aptitude not always present, so can't rely on it.
2. It needs to be i18n safe, e.g. no reliance on grepping for
"Installed:" output of apt-cache policy <package> because that
is en locale specific.
3. It needs to be able to distinguish a package that is
installed from any other condition with only the former we care
about. That means the exit code, for instance, of the query
should be never be the same for a package that is installed
versus one that is not installed - and not available anywhere.
Any help appreciated.
--
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
Dom
May 25, 2013, 2:10:01 AM5/25/13
to
On 25/05/13 06:30, Kip Warner wrote:
> Hey list,
>
> I'd like to know the most reliable way for a bash script to verify that
> a package is installed on the user's system. I've looked already at
> dpkg, dpkg-query, and aptitude. These are the constraints:
>
> 1. It needs to work on any stock Debian based system, e.g.
> aptitude not always present, so can't rely on it.
>
> 2. It needs to be i18n safe, e.g. no reliance on grepping for
> "Installed:" output of apt-cache policy<package> because that
> is en locale specific.
>
> 3. It needs to be able to distinguish a package that is
> installed from any other condition with only the former we care
> about. That means the exit code, for instance, of the query
> should be never be the same for a package that is installed
> versus one that is not installed - and not available anywhere.
>
> Any help appreciated.
>
LANGUAGE="C" dpkg -l $packagename | grep -q "^ii "
> Hey list,
>
> I'd like to know the most reliable way for a bash script to verify that
> a package is installed on the user's system. I've looked already at
> dpkg, dpkg-query, and aptitude. These are the constraints:
>
> 1. It needs to work on any stock Debian based system, e.g.
> aptitude not always present, so can't rely on it.
>
> 2. It needs to be i18n safe, e.g. no reliance on grepping for
> "Installed:" output of apt-cache policy<package> because that
> is en locale specific.
>
> 3. It needs to be able to distinguish a package that is
> installed from any other condition with only the former we care
> about. That means the exit code, for instance, of the query
> should be never be the same for a package that is installed
> versus one that is not installed - and not available anywhere.
>
> Any help appreciated.
>
will return 0 if the package is installed and 1 for any other state.
--
Dom
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51A053F6...@rpdom.net
Kip Warner
May 25, 2013, 10:30:02 AM5/25/13
to
On Sat, 2013-05-25 at 07:02 +0100, Dom wrote:
> LANGUAGE="C" dpkg -l $packagename | grep -q "^ii "
>
> will return 0 if the package is installed and 1 for any other state.
Hey Dom. I don't know why I didn't think to set the environment variable
> LANGUAGE="C" dpkg -l $packagename | grep -q "^ii "
>
> will return 0 if the package is installed and 1 for any other state.
before executing the query. That surely will work. Thanks a lot.
By the way, where can I read more on specifically the meaning of the C
locale and how it is the same or different from en_US?
Further, is C locale guaranteed to be present on any properly
functioning system, independent of whether the user's preferred locale
is, say, Russian?
Andrei POPESCU
May 25, 2013, 10:50:02 AM5/25/13
to
On Sb, 25 mai 13, 07:26:49, Kip Warner wrote:
>
> By the way, where can I read more on specifically the meaning of the C
> locale and how it is the same or different from en_US?
Which en_US locale?
>
> By the way, where can I read more on specifically the meaning of the C
> locale and how it is the same or different from en_US?
$ grep en_US /etc/locale_gen
# en_US ISO-8859-1
# en_US.ISO-8859-15 ISO-8859-15
# en_US.UTF-8 UTF-8
> Further, is C locale guaranteed to be present on any properly
> functioning system, independent of whether the user's preferred locale
> is, say, Russian?
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
Slavko
May 25, 2013, 11:10:01 AM5/25/13
to
Dňa 25.05.2013 16:26 Kip Warner wrote / napísal(a):
> Further, is C locale guaranteed to be present on any properly
> functioning system, independent of whether the user's preferred locale
> is, say, Russian?
Consider LANG=C not as locale, but as built-in strings, because the app
> Further, is C locale guaranteed to be present on any properly
> functioning system, independent of whether the user's preferred locale
> is, say, Russian?
must have some strings (if it uses strings for communication) :-)
Then all systems have "C", but not all must have "en-GB", for example.
There can be one problem, the C is not defined by language base, then
virtually it can be any language (by author choice) - but the English is
rule.
regards
--
Slavko
http://slavino.sk
David
May 25, 2013, 9:10:02 PM5/25/13
to
On 26/05/2013, Kip Warner <k...@thevertigo.com> wrote:
>
> By the way, where can I read more on specifically the meaning of the C
> locale and how it is the same or different from en_US?
http://mywiki.wooledge.org/locale
>
> By the way, where can I read more on specifically the meaning of the C
> locale and how it is the same or different from en_US?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kip Warner
May 26, 2013, 2:40:02 AM5/26/13
to
On Sat, 2013-05-25 at 17:01 +0200, Slavko wrote:
> Consider LANG=C not as locale, but as built-in strings, because the app
> must have some strings (if it uses strings for communication) :-)
>
> Then all systems have "C", but not all must have "en-GB", for example.
> There can be one problem, the C is not defined by language base, then
> virtually it can be any language (by author choice) - but the English is
> rule.
Thanks Slavko.
> Consider LANG=C not as locale, but as built-in strings, because the app
> must have some strings (if it uses strings for communication) :-)
>
> Then all systems have "C", but not all must have "en-GB", for example.
> There can be one problem, the C is not defined by language base, then
> virtually it can be any language (by author choice) - but the English is
> rule.
Kip Warner
May 26, 2013, 2:40:02 AM5/26/13
to
On Sat, 2013-05-25 at 17:47 +0300, Andrei POPESCU wrote:
> Which en_US locale?
>
> $ grep en_US /etc/locale_gen
> # en_US ISO-8859-1
> # en_US.ISO-8859-15 ISO-8859-15
> # en_US.UTF-8 UTF-8
The latter.
> Which en_US locale?
>
> $ grep en_US /etc/locale_gen
> # en_US ISO-8859-1
> # en_US.ISO-8859-15 ISO-8859-15
> # en_US.UTF-8 UTF-8
> Yes, AFAIK the C locale is built into libc.
Kip Warner
May 26, 2013, 2:50:01 AM5/26/13
to
On Sun, 2013-05-26 at 11:04 +1000, David wrote:
> On 26/05/2013, Kip Warner <k...@thevertigo.com> wrote:
> >
> > By the way, where can I read more on specifically the meaning of the C
> > locale and how it is the same or different from en_US?
>
> http://mywiki.wooledge.org/locale
Thanks David.
> On 26/05/2013, Kip Warner <k...@thevertigo.com> wrote:
> >
> > By the way, where can I read more on specifically the meaning of the C
> > locale and how it is the same or different from en_US?
>
> http://mywiki.wooledge.org/locale
0 new messages