I’m personally -1 on this, because I don’t think a high-level Nix function should be exposing low level shell functionality. I won’t block it if somebody else thinks it’s a good idea though.

I'm not a fan of this. I agree that it's unexpected for the entries in the exes property to actually be arbitrary unquoted shell inputs.

If anything, we should be updating this code to use the library function for correctly quoting shell strings (I forget offhand what it is but it's in there) instead of just assuming a single quote is sufficient. Granted, an exe with a single quote in it would be rather surprising, but it would currently break the code.

If there's a compelling reason to want to support wildcards then we should expose that as a separate property.

For gems where the list varies a lot it's nice to be able to pattern-match. Is there any other way to implement this that doesn't rely on forwarding the logic to bash?

Maybe add an exesPrefix argument that would escape the prefix with the globbing added to the end?

${(lib.concatMapStrings (x: "ln -s '${basicEnv}/bin/${x}'* $out/bin/${x};\n") exesPrefix)}

Let me recap:

1. Everybody agrees that the current situation is not ideal due to quoting possibly breaking
2. The current code will also happily create a symlink to an executable that doesn't exist
3. The proposed PR doesn't cut it as we blur the lines between bash and nix by writing bash globs in nix
4. Instead of changing the functionality of exes, introduce a new one.

I'll address points 2 to 4 and resubmit.

I think there is also an issue if the prefix matches multiple results. It might be best to use something like this;

set -o nullglob
${(lib.concatMapStrings (x: "for file in '${basicEnv}/bin/${x}'* ; do ln -s "$file" "$out/bin/$(basename "$file")"; done;\n") exesPrefix)}

ln supports having multiple source files. Really the problem with just using the glob as-is is if it matches none at all.

I'm going to be using find .

How is that any better than the shell for loop version that @zimbatm suggested?

For 2 reasons:

1. We have to worry about whitespaces with a for loop, and
2. The nullglob option is a bash thing where as find is POSIX, so let's use the standard option.

I don't mind either way, as long as it's correct it doesn't matter that much

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

I marked this as stale due to inactivity. → More info

I'm going to go ahead and drop this.

Don't really have a need for it any longer.