Coreutils 9.0 won't build

Just add another. You can define as many bindings in a single let as you need, eg:

let a = 1; b = 2; in a * b;
1 Like

Nice.

So, to confirm, I should add pkgs. in front of each application?

Personally I do indeed as vcunat suggests.

I guess I am too new to understand how to implement that. Also, his example only references the packages from the let binding statement. What about the example packages I included (feh, ffmpeg)?

Would you mind providing an example of how to implement that lib.attrValues statement into my home.nix?

  1. It is not a statement, its an expression
  2. home.packages = let rofi-bt = ā€¦ in builtins.attrValues {
      inherit (pkgs) feh ffmpeg;
      inherit rofi-bt;
    };
    

Sometimes I use

let
  inherit (pkgs) rofi bluez coreutils gnugrep;
in ...

but in this case it wouldnā€™t avoid some repetition.

1 Like

There seems to be an issue with this approach if the package has a ā€˜.ā€™ in it such as gnome.simple-scan. Any thoughts?

Do I need to do this instead:

inherit (pkgs) feh ffmpeg;
inherit (gnome) simple-scan;
inherit rofi-bt;

Lastly, will there be a problem if I put inherit rofi-bt; first in the above list?

inherit (pkgs.gnome) simple-scan;

would be the way.

(deleted previous post and replaced it with this ā€“ solved the previous one myself)

Thanks for all your help so far. I feel like I am making progress.

How can I implement runHook preCheck and runHook postCheck? I tried the below, but it didnā€™t work:

      rofi-bt = pkgs.writeShellApplication {
        name = "rofi-bluetooth";
        runtimeInputs = [ pkgs.rofi pkgs.bluez pkgs.coreutils pkgs.gnugrep ];
        checkPhase      ''
                runHook preCheck
                runHook postCheck
        '';
        text = builtins.readFile ./rofi-bluetooth.sh;
      };

I get this:

āÆ home-manager switch
error: syntax error, unexpected IND_STRING_OPEN, expecting '.' or '='

       at /home/user/.config/nixpkgs/home.nix:26:20:

           25|         runtimeInputs = [ pkgs.rofi pkgs.bluez pkgs.coreutils pkgs.gnugrep ];
           26|         checkPhase    ''
             |                    ^
           27|           runHook preCheck
(use '--show-trace' to show detailed location information)

Solved the aboveā€¦ Missed the =.

        checkPhase = ''
                runHook preCheck
                runHook postCheck
        '';

BTW, is there a better way to diable the checks that fail when these scripts get built?

OK. I have determined exactly what was causing my original problem, and it has cropped up again.

Inside home.nix is my polybar config. One of the modules I have created is the following:

"module/bluetooth" = {
  type = "custom/script";
  exec = "rofi-bluetooth --status";
  interval = 1;
  click-left = "rofi-bluetooth";
};

which causes an error when polybar is started:

rofi-bluetooth: command not found

So, if I try this instead:

"module/bluetooth" = {
  type = "custom/script";
  exec = "${pkgs.rofi-bluetooth}/bin/rofi-bluetooth --status";
  interval = 1;
  click-left = "${pkgs.rofi-bluetooth}/bin/rofi-bluetooth";
};

thatā€™s when a manual build of coreutils is triggered.

@NobbZ Any ideas on the above?

The last piece of the puzzle is to be able to have one of thte scripts I created rofi-bluetooth to be able to be called from a polybar module. I just canā€™t seem to be able to figure it out.

I have no clue how polybar works, though you might need to adjust the polybar settings to run your script.

You do not necessarily need to add it to your global available then, but just polybar.

Well, the main idea is that polybar is run in the background and picks up itā€™s config from my home.nix. One of the config statements is a command that gets executed to grab the status of bluetooth. The command is:

rofi-bluetooth --status

I am able to successfully run this command from the terminal, however, I canā€™t seem to get it to run when called from within polybar. It complains that rofi-bluetooth cannot be found.

Assuming it was a PATH issue, I tried using

${pkgs.rofi-bluetooth}/bin/rofi-bluetooth --status

instead, but in doing so, it caused the system to want to manually build coreutils.

Any thoughts?

Use the version from the let we wrote for home.packages.

Iā€™m still not convinced that an overlay is necessary, nor that it would be correctly written.

Also, is your configuration publicly available? Debugging that would be much easier than back and forth here.

I am sorry about this. I really appreciate your help. Unfortunately, my config is not publicy available.

I am using the let statement you suggested above. I am not using overlays anymore.

As you are not using flakes, do ~/.config/nixpkgs/overlay or similar named files or folders exist either for the user running HM or for root?

Hmmā€¦ I am not sure I understand you question, but here goes.

I do not have a file or folder called ~/.config/nixpkgs/overlay. I do have a folder called ~/.config/nixpkgs/overlays (which is probably what you meant), but I only used that when I was trying to get this working using overlays. I have completely stopped using overlays now, and am using let statements to define my scripts.

The problem as I see it is that the scripts created within those let statements donā€™t seem to be on the path when polybar is run. When polybar is executed, it canā€™t find rofi-bluetooth although it is on the path for me as a regular user.

Incidentlally, this is how polybar is executed using home-manager:

services.polybar.script
This script will be used to start the polybars. Set all necessary environment variables here and start all bars. It can be assumed that polybar executable is in the PATH. Note, this script must start all bars in the background and then terminate.

Type: strings concatenated with "\n"

Example: "polybar bar &"

Declared by:

<home-manager/modules/services/polybar.nix>

This is what mine looke like:

  services.polybar = {
    enable = true;
    package = pkgs.polybarFull;
    script = "polybar --reload mybar &";
    settings = {
      ...

Maybe I need to somehow modify the path in an environment variable?

User-level nix without flakes will auto load files from that location. Give it a shot and remove/rename that folder.

With nixos you have to stop to believe in PATH for anything than your interactive shell sessions. Use string interpolation to generate absolute pathes to each ā€œrunnableā€.

1 Like

Let me just pause and ask a question at the 50,000 ft level.

My desire is to be able to create some bash shell scripts. The scripts need to be available at the terminal (i.e. in the PATH), but also, some of the scripts are part of my polybar config. Polybar is run at startup from within my home.nix, and some of the scripts are run at that time.

I donā€™t know why this seems so difficult for me to achieve. I am sure that my overall understanding is lacking, but I have asked this question a number of times and have been unable to get this working.

If the let statement with writeShellApplication from home.nix is the way to go, then Iā€™ll pick up my questions from there.