config.example fix command path

[LukasLeppich]

Expected behavior

The config.example should work if i change $SCRIPT_DIR to the location of this repository.

Actual behavior

Error message: /bin/sh: /home/{username}/.config/i3blocks/volume: Is a directory
...

i3blocks config relevant to blocklet(s)

config.example from this repository.
Relevant line:
command=$SCRIPT_DIR/$BLOCK_NAME

Output of blocklet(s) when run from command line

/bin/sh: /home/{username}/.config/i3blocks/volume: Is a directory
<3>[volume] Command '/home/{username}/.config/i3blocks/$BLOCK_NAME' not executable
...

Works for me:

If i change the line to command=/home/{username}/.config/i3blocks/$BLOCK_NAME/$BLOCK_NAME it works.

The original line executes /.config/i3blocks/volume which is an directory. If i change it to $BLOCK_NAME/$BLOCK_NAME it executes the script /.config/i3blocks/volume/volume.

[skidnik]

From CONTRIBUTING.md:

A blocklet MUST be confined to a single directory and the name of the directory MUST be relevant to the blocklet's purpose or core feature.

The command file's name, SHOULD match the name of the containing directory.

This does not guarantee that the blocklet directory name matches the blocklet executable name. Thus locking both subdirectory and executable name to the same variable is wrong.

In addition, the the right place to store blocklets in use is under 'libexec' directory, e.g. /usr/libexec/i3blocks or ${HOME}/.local/libexec/i3blocks. They have unique names, so nothing prevents you from storing them under the same directory.

End users on the other hand can do whatever is to their desire, but that, as in you case, requires manual intervention.

[therealmaxmoon]

I had the same issue, that only the date and time was seen with the config.example. And this is the only command in the config which is typed in directly in the file. That means something is wrong with the path and name of the executables.
Changing the command line to
command=$SCRIPT_DIR/$BLOCK_NAME/$BLOCK_NAME
helped. But it isn't guaranteed that the directory name is the same like the name of the plugin (which was already mentioned). But it is still a bug, right? Or is this only affecting 2 people?

@skidnik why exactly /usr/libexe? Why not ~/i3blocks/i3blocks-contrib-executables or any other directory in $HOME?
And is there a way to copy all the executable faster than looking for them by hand?

[skidnik]

@therealmaxmoon

why exactly /usr/libexe?

Because it's a well-known convention (Arch does not have libexec, so just lib), it's where distro packagers have been putting blocklets when they were included in the release.

And is there a way to copy all the executable faster than looking for them by hand?

for tobuild in $(find . -type f -name 'Makefile`);
do
    pushd $(dirname $tobuild)
    make
    popd
done
find . -type f -executable -exec cp -v {} ${HOME}/.local/libexec/i3blocks/ \;

NOTE: This has not been tested.

When executed in the i3blocks-contrib repo root, the above should build all the binary blocklets and then copy all executables to the blocklet directory. Blocklets have unique name, that's a requirement here, so it should be safe to put them in the same directory.

update: There is now a Makefile in the repository root that can do the same.

[ghost]

Took me a while as well to realize that config.example is lying to me and not only SCRIPT_DIR has to be changed. I ended up using hardcoded paths before I found this issue. This is the first time I use an official config example that requires a hidden modification to work out of the box. Please, be a bit more humane and drop that COULD/SHOULD/MOOD/FOOD stupidity (referring to #307 (comment)), require normal script_name/script_name naming convention and merge #307. Don't deliberately complicate something that doesn't require complexity.

[skidnik]

Don't deliberately complicate something that doesn't require complexity.

No one creates the complexity here. This repo contains source code, the executables (aka blocklets) should be compiled if needed and installed into a single directory as the manual recommends. The fact that you or a packager did not do this complicated things for you.

[sshaikh]

For my understanding, is the issue here that the i3blocks-contrib repo itself doesn't lend itself to be used with the example config given with it? And that all required scripts should live in a "flat" location?

[skidnik]

@sshaikh , there is no issue here, the example config in this repository is in accordance with the installation guide from this repository. The issue is either with wrong packaging, or with the lack of instructions on how to properly use those packages, or with poeple not reading the manual.

The issue is with people trying to use the source code from this repository directly, while the blocklets should be installed into the system like any other software.

I'm puzzled about why this is still open.

[sshaikh]

My phrasing was unfortunate. I was trying to understand what the issue for the others were. Indeed my first attempt was to clone the repo and use it directly, and this (non-)issue helped me understand why that was problematic and what the solution is.

For those on arch, the following in your PKGBUILD should do the job (inspired by #255 (comment), so thank you):

package () {
  cd "${srcdir}"/i3blocks-contrib
  mkdir -p "${pkgdir}"/usr/lib/i3blocks

  for tobuild in $(find . -mindepth 2 -type f -name 'Makefile');
  do
    pushd $(dirname $tobuild)
    make
    popd
  done

  find . -type f -executable -not -path './.git/*' -exec cp {} "${pkgdir}"/usr/lib/i3blocks/ \;
}

[carreter]

See the above mention for the likely source of the confusion - the original i3blocks README is somewhat misleading.