sunflower-fm on Salix OS LXDE 13.37

[Shador]

You can just create them then.

/usr is usually for applications installed by the distribution which are not extremely important to the system core (those go to / i.e. /bin /sbin /lib ...). /usr/local is usually for stuff by the local administrator. Everything in the home directory is for stuff by the local user.
But /opt seems like the best idea for this kind of prebuilt tarball application. If you install to /opt you need to create a symlink in /usr/loca/bin at least or you need to modify your PATH.

It's just convention anyway: https://en.wikipedia.org/wiki/Filesyste ... y_Standard

[globetrotterdk]

You can just create them then.

/usr is usually for applications installed by the distribution which are not extremely important to the system core (those go to / i.e. /bin /sbin /lib ...). /usr/local is usually for stuff by the local administrator. Everything in the home directory is for stuff by the local user.
But /opt seems like the best idea for this kind of prebuilt tarball application. If you install to /opt you need to create a symlink in /usr/loca/bin at least or you need to modify your PATH.

It's just convention anyway: https://en.wikipedia.org/wiki/Filesyste ... y_Standard

Thanks Shador. So, taking the point of reference that I will move the "Sunflower" directory to /opt do the directory permissions need to be changed? What about this with changing PATH? I assume you are suggesting that changes be made in ~/.profile and not /etc/profile? Is it the default system $PATH that I need to change? Can you post something about the syntax for adding /opt to "the PATH"?

[mimosa]

You shouldn't need to change your $PATH. Just put a symlink to the .py script in /usr/local/bin, which is already in your $PATH, and point the launcher at that.

Except that as Shador says, the files should really belong to root:

Code: Select all

$su
#cp -r /home/globetrotter/Sunflower /opt
#ln -s /opt/Sunflower/Sunflower.py /usr/local/bin/sunflower
#chown -R root /opt/Sunflower     # recursively change ownership to root

The final step is probably unnecessary - I think cp makes the owner root anyway in this case.

EDIT

Code changed to put the folder in /opt where it belongs!

[globetrotterdk]

Code: Select all

$su
#cp -r /home/globetrotter/Sunflower /usr/local/bin
#ln -s /opt/Sunflower/Sunflower.py /usr/local/bin/sunflower
#chown -R root /opt/Sunflower     # recursively change ownership to root

The final step is probably unnecessary - I think cp makes the owner root anyway in this case.

Thanks for the help mimosa. I believe that the symlink syntax should be reversed shouldn't it? It should look like:

Code: Select all

ln -s /usr/local/bin/sunflower /opt/sunflower/Sunflower.py

So when I change the .desktop file that I have created in usr/share/applications the line should read like this:

Code: Select all

Exec=/opt/sunflower/Sunflower.py

When I try that, I get the following error:

Code: Select all

Failed to execute child process "/opt/sunflower/Sunflower.py" (Not a directory)

Lastly, if I was to decide to remove PCManFM and only use sunflower-fm, (or just want to set sunflower-fm as default) what would I need to do?

[mimosa]

I can never remember which way round the arguments of ln are supposed to go

However, from the output you posted, it looks as though you created a link called /opt/sunflower/Sunflower.py to a directory ... possibly you have overwritten the script by doing so.

Also, the whole idea of the symlink is that you launch the app via /usr/local/bin/sunflower. It's just a symlink, but it points to the actual executable file (sunflower.py) and it is in your $PATH. The way you have done it in the .desktop file, you don't need the symlink at all; but other ways of calling sunflower (for instance, from the command line) won't work. Or indeed, it looks like that way doesn't work either. But if it did, there would be no need for the symlink.

Depending on your desktop environment, to make sunflower-fm your default file manager, you'd need to change all the launchers and pointers that currently call PCMan-FM so that they point to sunflower-fm. That's another reason for the symlink - if for some reason you move the actual application somewhere else, you just need to change one symlink rather than all those pointers.

Indeed, that suggests a rather dirty hack - you could uninstall PCMan-FM and create a symlink from /usr/bin/PCMan-FM to /usr/local/bin/sunflower. I don't recommend this though

Have a look at the man file for ln to see what the correct syntax should be - or maybe search online for usage examples. But I think the way I posted is right

[Shador]

Thanks for the help mimosa. I believe that the symlink syntax should be reversed shouldn't it? It should look like:

Code: Select all

ln -s /usr/local/bin/sunflower /opt/sunflower/Sunflower.py

No, I have to always look it up too, but it was right the way mimosa posted it. So first argument where the symlink should point to and second argument where to create the symlink that points at the first argument.

Also, the whole idea of the symlink is that you launch the app via /usr/local/bin/sunflower. It's just a symlink, but it points to the actual executable file (sunflower.py) and it is in your $PATH.

Yes, but it's often very hard to determine the location of one's own binary during execution. But this is needed to get access to other files that are stored relative to the location of the actual executable. Depending on how sophisticated that detection is it may not work and require a wrapper (script) to make it work. For bash I think it was like 10-20! not straighforward lines to get PORTABLE code that handles this. (On a side not a case of very useful and commonly used wrappers.)

Indeed, that suggests a rather dirty hack - you could uninstall PCMan-FM and create a symlink from /usr/bin/PCMan-FM to /usr/local/bin/sunflower. I don't recommend this though

And it's not even sure to work reliably (if at all) and can create many unforeseen problems.

So when I change the .desktop file that I have created in usr/share/applications the line should read like this:

Code: Select all

Exec=/opt/sunflower/Sunflower.py

If you symlink the script as pointed out just "Exec=sunflower" should be enough which is much cleaner.

When I try that, I get the following error:

Code: Select all

Failed to execute child process "/opt/sunflower/Sunflower.py" (Not a directory)

Lastly, if I was to decide to remove PCManFM and only use sunflower-fm, (or just want to set sunflower-fm as default) what would I need to do?

Setup the symlink as pointed out previously then try to execute it by just typing "sunflower" and if that fails try "/opt/sunflower/Sunflower.py". Please also post the respective output for the failing command(s).

[mimosa]

it's not even sure to work reliably (if at all) and can create many unforeseen problems

... quite so! But it could be fun to try, and is easy enough to undo. Also, depending on your DE, it may have some special configuration for what the default FM is, and then the thing would be to change that. But it depends which DE you are using. With any luck, this may be clearly explained in the documentation. Also it might be a setting you can access through the menus rather than by editing config files.

[mimosa]

I just actually tried it here, and it seems just the problem you suspected arises, Shador: the app only works if called from inside its directory. I'm afraid I don't know how to make it integrate with the DE in this case - is a wrapper script the only way?

Code: Select all

vanilla[~]$ sunflower
/usr/local/bin/sunflower: can't open file '/usr/local/bin/application/main.py': [Errno 2] No such file or directory

It also works if called like this:

Code: Select all

vanilla[~]$ /opt/Sunflower/Sunflower.py

Perhaps there's some information on the site. Nobody would write a GUI file manager that can only be run from the console... would they?

[Shador]

Write this into /usr/local/bin/sunflower (don't forget to make it executable +x):

Code: Select all

#!/bin/sh

cd /opt/Sunflower/
./Sunflower.py "$@"

If you know where everything is stored writing such a wrapper is quite simple. It's just difficult if you don't know and need to find out how the executable was called and where it is actually stored in case of symlinks. This applications just seems to use dirname and doesn't resolve symlinks beforehand.

The wrapper posted should generally work well in case an application doesn't handle this properly.

[mimosa]

That's how I imagined it, and I can confirm that it works here.