Ticket #3740 (closed defect: wontfix)

Opened 3 years ago

Last modified 3 years ago

mc-wrapper.sh script is not installed in target bin directory

Reported by: sorin Owned by:
Priority: major Milestone:
Component: mc-core Version: master
Keywords: Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

While I am not sure if that's by design but here is the use case: as an user I want to be able to install and use mc and benefit from the ability to keep the current folder. This would usually be achieved by adding an alias mc=mc-wrapper.sh. This works well as long mc-wrapper.sh is in the PATH too.

Now, the problem is that on MacOS the standard installation method is using brew which installs each package in its own unique (version based) target location and in the end it does symlink executables inside /usr/local/bin. Symlinks for mc, mcedit and mcview are created successfully without having to do anything. They also work very well.

Here is an example:

 ls -l /usr/local/bin/mc*
lrwxr-xr-x  1 ssbarnea  staff  42  7 Dec 09:16 /usr/local/bin/mc -> ../Cellar/midnight-commander/4.8.18/bin/mc
lrwxr-xr-x  1 ssbarnea  staff  46  7 Dec 09:16 /usr/local/bin/mcdiff -> ../Cellar/midnight-commander/4.8.18/bin/mcdiff
lrwxr-xr-x  1 ssbarnea  staff  46  7 Dec 09:16 /usr/local/bin/mcedit -> ../Cellar/midnight-commander/4.8.18/bin/mcedit
lrwxr-xr-x  1 ssbarnea  staff  46  7 Dec 09:16 /usr/local/bin/mcview -> ../Cellar/midnight-commander/4.8.18/bin/mcview

As you can see this does not cover mcwrapper.sh which now is located inside /usr/local/Cellar/midnight-commander/4.8.18/libexec/mc/mc-wrapper.sh

Yep, I could manually create a symlink to this location but this means that the next upgrade will break it.

I am looking for a better alternative that would not break on upgrades, maybe even an option to install and activate the wrappers by default, if possible. If this would be possible it would be a great addition not only for MacOS but for all platforms.

Change History

comment:1 Changed 3 years ago by zaytsev-work

  • Status changed from new to closed
  • Resolution set to wontfix

The wrappers don't belong to BINDIR, they are scripts that are supposed to be sourced, and as such should live in LIBEXECDIR according to FHS and most distro packaging guidelines.

Please bring this up with Homebrew to see what they can suggest to provide you with a stable reference. If they decide to put wrappers in BINDIR just to provide stable reference, it's their (platform/distro-specific) choice, but I hope they'll figure some other less horrible solution.

comment:2 follow-up: ↓ 3 Changed 3 years ago by sorin

I guess that there are some serious reasons why the mc wrappers are optional and requiring users to source them instead of being the default way to start mc. I am quite curious to find out why the wrappers remained an optional/extra part of mc.

I am going to work with homebrew guys on finding a solution for this so we can provide a good user experience. I supposed that we both agree that both having to recreate the aliases after each mc upgrade is also a horrible experience.

comment:3 in reply to: ↑ 2 Changed 3 years ago by andrew_b

Replying to sorin:

I guess that there are some serious reasons why the mc wrappers are optional and requiring users to source them instead of being the default way to start mc. I am quite curious to find out why the wrappers remained an optional/extra part of mc.

In short, you just can't change the current directory of parent process from child one.

comment:4 Changed 3 years ago by zaytsev-work

I am going to work with homebrew guys on finding a solution for this so we can provide a good user experience.

Let us know how it goes...

I supposed that we both agree that both having to recreate the aliases after each mc upgrade is also a horrible experience.

Yes.

comment:5 Changed 3 years ago by andrew_b

  • Milestone Future Releases deleted
Note: See TracTickets for help on using tickets.