Proper location to install shell function libraries?

[Andreas Kusalananda Kähäri]

Hi,

I'm hoping this is the correct forum for this query. If not, kindly
point me elsewhere.

I'm developing a tiny set of shell scripts (sh, ksh93, bash) for use in
testing behaviour of shell constructs under various shells.

The scripts use GNU autoconf for finding the absolute paths to either
ksh93 or bash on the system it's being installed on, and for simply
placing a bug reporting address and project version number in the
generated scripts (really, nothing fancy at all).

The scripts make use of a common set of shell functions, defined in
their own file. This is currently sourced like this:

prefix="@prefix@"
exec_prefix="@exec_prefix@"
. "@libexecdir@/toolbox.shlib"

Then, in the configure.ac file, I have a line like

AC_CONFIG_FILES([src/script], [chmod +x src/script])

for each script, so that it's generated from the corresponding script.in
file upon running configure.

My query is this: Would libexecdir be the best place to put a file that
is architecture dependent, but *not* meant to be executed separatedly
(it's a library). Or should it actually be stored under libdir (which
I've never seen done with a shell library of functions)?

Regards,
Andreas

[Ralf Corsepius]

Post by Andreas Kusalananda Kähäri
My query is this: Would libexecdir be the best place to put a file that
is architecture dependent, but *not* meant to be executed separatedly
(it's a library). Or should it actually be stored under libdir

$libexecdir is meant to take a suite's/package's
"internal/sub-programs/executables/scripts" (typically with executable
permissions). Think of it as a auxiliary $bindir, which is supposed not
to be in $PATH.

$libdir/<subdir>/ (e.g. %libdir/<package>) is the playground a package
can install more or less whatever it wants, comprising executables.

As your "scripts" don't seem to be "programs", $libdir/<subdir> probably
is what you are looking for.

Post by Andreas Kusalananda Kähäri
(which
I've never seen done with a shell library of functions)?

Storing script fragments or scripts in $libdir would be unusual and
discussworthy, but installing these to $libdir/<packages>/ is quite common.

Ralf

[Russ Allbery]

$libdir/<subdir>/ (e.g. %libdir/<package>) is the playground a package can
install more or less whatever it wants, comprising executables.
As your "scripts" don't seem to be "programs", $libdir/<subdir> probably
is what you are looking for.

$datadir/<subdir>, no? Script libraries are almost certainly
architecture-independent.

[Basin Ilya]

I agree. Consider RHEL/CentOS where you can simultanneously install both .i686 and .x86_64 versions of one package. The packages are allowed to have overlapping files, if these files don't differ.

If one puts script libraries to $libdir/<subdir>, CentOS will have duplicate files in /lib/<subdir> and /lib64/<subdir>, but in case of $datadir there will be only one /usr/share/<subpackage>

Post by Russ Allbery

$libdir/<subdir>/ (e.g. %libdir/<package>) is the playground a package can
install more or less whatever it wants, comprising executables.
As your "scripts" don't seem to be "programs", $libdir/<subdir> probably
is what you are looking for.

$datadir/<subdir>, no? Script libraries are almost certainly
architecture-independent.

[Ralf Corsepius]

Post by Basin Ilya
I agree. Consider RHEL/CentOS where you can simultanneously install both .i686 and .x86_64 versions of one package. The packages are allowed to have overlapping files, if these files don't differ.
If one puts script libraries to $libdir/<subdir>, CentOS will have duplicate files in /lib/<subdir> and /lib64/<subdir>, but in case of $datadir there will be only one /usr/share/<subpackage>

Right, but this is only applicable if all files are arch-independent and
guaranteed to stay so for ever.

Ralf

[Andreas Kusalananda Kähäri]

Post by Basin Ilya
I agree. Consider RHEL/CentOS where you can simultanneously install both .i686 and .x86_64 versions of one package. The packages are allowed to have overlapping files, if these files don't differ.
If one puts script libraries to $libdir/<subdir>, CentOS will have duplicate files in /lib/<subdir> and /lib64/<subdir>, but in case of $datadir there will be only one /usr/share/<subpackage>

If you install architecture-dependent shell function library files into
$datadir and then mount that hierarchy on different architectures,
this will fail. Different architectures in this case means OpenBSD,
NetBSD, Solaris and Ubuntu, and the architecture dependance comes from
the location of certain utilities used by the shell library (GNU "grep"
is /usr/local/bin/ggrep on OpenBSD, /usr/pkg/bin/ggrep on NetBSD,
/usr/bin/ggrep on Solaris, while it's /bin/grep on Ubuntu).

Andreas

Post by Basin Ilya

Post by Russ Allbery

$libdir/<subdir>/ (e.g. %libdir/<package>) is the playground a package can
install more or less whatever it wants, comprising executables.
As your "scripts" don't seem to be "programs", $libdir/<subdir> probably
is what you are looking for.

$datadir/<subdir>, no? Script libraries are almost certainly
architecture-independent.

_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

[Nick Bowler]

Hello,

On 3/1/17, Andreas Kusalananda Kähäri <***@icm.uu.se> wrote:
[...]

Post by Andreas Kusalananda Kähäri
The scripts make use of a common set of shell functions, defined in
Then, in the configure.ac file, I have a line like
AC_CONFIG_FILES([src/script], [chmod +x src/script])
for each script, so that it's generated from the corresponding script.in
file upon running configure.
My query is this: Would libexecdir be the best place to put a file that
is architecture dependent, but *not* meant to be executed separatedly
(it's a library). Or should it actually be stored under libdir (which
I've never seen done with a shell library of functions)?

Seems fine. If you are installing more than one file (or think you
might do so in the future) I suggest putting them in a subdirectory
thereof -- if you use Automake then this will define the pkglibexecdir
variable by default to install files into a subdirectory with the
same name as your package.

The definition of these install variables comes from the GNU Coding
Standards[1]. You mention the installed scripts are machine-dependent
so they should be installed in either libdir or libexecdir. GCS says:

"libexecdir: The directory for installing executable programs to be
run by other programs rather than by users ..."

"libdir: The directory for object files and libraries of object
code ..."

Which doesn't really help us decide where to install non-executable
machine-dependent shell fragments. Based on this information alone,
libexecdir seems like a reasonable choice. However, looking at what
packages installed on my computer do, libdir seems to be much more
commonly used. So I'd say do whatever you prefer.

[1] https://www.gnu.org/prep/standards/

Cheers,
Nick

[Ralf Corsepius]

Post by Nick Bowler
The definition of these install variables comes from the GNU Coding
Standards[1]. You mention the installed scripts are machine-dependent
"libexecdir: The directory for installing executable programs to be
run by other programs rather than by users ..."
"libdir: The directory for object files and libraries of object
code ..."
Which doesn't really help us decide where to install non-executable
machine-dependent shell fragments.

Note the term "executable programs" in the section on "libexecdir", you
cited above. Shell fragment usually aren't "executable".

Post by Nick Bowler
Based on this information alone,
libexecdir seems like a reasonable choice. However, looking at what
packages installed on my computer do, libdir seems to be much more
commonly used.

This observation has its reasons (at least under Linux).

- Many distros do not support or did not support libexecdir and favor
$libdir/<package>.
- Many packages do not use libexecdir.
- Putting everything into $libdir/<package> is easier to use.

Ralf

[Nick Bowler]

Post by Ralf Corsepius

Post by Nick Bowler
The definition of these install variables comes from the GNU Coding
Standards[1]. You mention the installed scripts are machine-dependent
"libexecdir: The directory for installing executable programs to be
run by other programs rather than by users ..."
"libdir: The directory for object files and libraries of object
code ..."
Which doesn't really help us decide where to install non-executable
machine-dependent shell fragments.

Note the term "executable programs" in the section on "libexecdir",
you cited above. Shell fragment usually aren't "executable".

I agree, but such fragments are also definitely not "object files" nor
are they "libraries of object code", hence why neither description is
particularly helpful in this case.

On the face of it a sourceable shell fragment seems closer to being an
executable program than it does to being an object file, so...

Cheers,
Nick

[Andreas Kusalananda Kähäri]

Post by Andreas Kusalananda Kähäri
Hi,

[cut]

Post by Andreas Kusalananda Kähäri
The scripts make use of a common set of shell functions, defined in
Then, in the configure.ac file, I have a line like
AC_CONFIG_FILES([src/script], [chmod +x src/script])
for each script, so that it's generated from the corresponding script.in
file upon running configure.
My query is this: Would libexecdir be the best place to put a file that
is architecture dependent, but *not* meant to be executed separatedly
(it's a library). Or should it actually be stored under libdir (which
I've never seen done with a shell library of functions)?

Just to clarify: The scripts themselves are naturally installed in
bindir, the question is what to do with a "shared library of shell
functions".

Thanks for the replies so far. I will try with libdir/package-name and
see what it looks like.

If anyone knows of a precedent for doing it one way or another, I'd be
happy to get to know about it.


Regards,
Andreas

[Andreas Kusalananda Kähäri]

(Forwarded to the list because I initially sent it from the wrong
address)

----- Forwarded message from Andreas Kusalananda Kähäri <***@nbis.se> -----

Date: Thu, 2 Mar 2017 09:23:34 +0100
From: Andreas Kusalananda Kähäri <***@nbis.se>
To: Basin Ilya <***@gmail.com>
Cc: Russ Allbery <***@eyrie.org>, ***@gnu.org
Subject: Re: Proper location to install shell function libraries?

Post by Basin Ilya
I agree. Consider RHEL/CentOS where you can simultanneously install both .i686 and .x86_64 versions of one package. The packages are allowed to have overlapping files, if these files don't differ.
If one puts script libraries to $libdir/<subdir>, CentOS will have duplicate files in /lib/<subdir> and /lib64/<subdir>, but in case of $datadir there will be only one /usr/share/<subpackage>

If you install architecture-dependent shell function library files into
$datadir and then mount that hierarchy on different architectures,
this will fail. Different architectures in this case means OpenBSD,
NetBSD, Solaris and Ubuntu, and the architecture dependance comes from
the location of certain utilities used by the shell library (GNU "grep"
is /usr/local/bin/ggrep on OpenBSD, /usr/pkg/bin/ggrep on NetBSD,
/usr/bin/ggrep on Solaris, while it's /bin/grep on Ubuntu).

Andreas

Post by Basin Ilya

Post by Russ Allbery

$libdir/<subdir>/ (e.g. %libdir/<package>) is the playground a package can
install more or less whatever it wants, comprising executables.
As your "scripts" don't seem to be "programs", $libdir/<subdir> probably
is what you are looking for.

$datadir/<subdir>, no? Script libraries are almost certainly
architecture-independent.

_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

----- End forwarded message -----