Should I override a Ruby program’s use of $PROGRAM_NAME?

Help
1

I’m working on packaging a command-line application written in Ruby. When you run the program with the --help flag, it outputs the Ruby string

Usage: #{$PROGRAM_NAME} [OPTION]... [FILE]...

Unfortunately, when I run the wrapped, Nix-packaged version, the actual output is

Usage: /nix/store/y7bdkpkfx8vm8jqgj8hkbxakqh4vz7n3-video_transcoding-0.25.1/bin/.convert-video-wrapped [OPTION]… [FILE]…

which is pretty horrendous to look at. Should my derivation patch this “usage” line and replace #{$PROGRAM_NAME} with some hard-coded value? I don’t know what the community’s standards are in this area.

1 Like
2

If it’s wrapped with wrapProgram, you can use --argv0 flag:

1 Like
3

Yes, I am using wrapProgram. (It’s makeWrapper, not wrapProgram, that has the --argv0 flag—wrapProgram comes up with the argv0 value for you.) Even if I switch to using makeWrapper manually and provide an --argv0 value, though, the wrapped program’s name still shows up in the output:

Usage: /nix/store/z116p78xsyf4dh2yfwahhxrr6zfgzppk-video_transcoding-0.25.1/bin/cvw [OPTION]… [FILE]…

The wrapper created by wrapProgram calls the underlying program with its full path (of course) but uses exec -a <wrappername> to try to change the argv0 value that the underlying program sees. Unfortunately, it seems like Ruby defeats this somehow and so the wrapped program can only see the full path. (This answer on Stack Overflow does some investigation into why this is.)

All told, it seems like I would need to patch $PROGRAM_NAME to a hard-coded value in the Ruby source if I wanted a nicer display name. I don’t know whether this kind of code change for cosmetic reasons is considered a good idea.

4

You can assign to $PROGRAM_NAME, I don’t know if that’s an option for you, but thought it might help.

5

Thank you both for the responses! I’ve decided to go ahead and leave the program name as-is, which has the nice bonus that I don’t need to patch the Gem’s source at all.