On 8/15/22 15:59, Siard wrote:

Per Jessen:

...

Siard wrote:

...

/usr/local/bin is owned by root with permissions 755, so as a user I cannot put a script in there.

I can change the ownership, but every time after a reboot it is owned by root again, with permissions 755.

Does anyone know where this is set, and/or how I can make /usr/local/bin permanently make writable for a user?

It isn't meant to be. /usr/local is for local stuff, i.e. not vendor or system.

For your own user script, put it in ~/bin

As an example, I can download Everdo-1.7.8.AppImage from https://everdo.net. What would be the most logical place to put this AppImage, and the right way to start it?

If I install something in /usr/local and need read/write, I just change ownership. I don't know what distro you are using, but I have never had my permissions changed back to root. (if you are using live CD/DVD -- then sure, that explains it -- /usr/local won't be persistent anyway in that case) No clue what an AppImage is -- checking, Arch installs to /opt (which is another good choice for it) You can duplicate that with the following snips from the PKGBUILD: source=("https://d11l8siwmn8w36.cloudfront.net/$pkgver/$pkgname-$pkgver.pacman") package() { # Install the application files in /opt install -d "${pkgdir}/opt" cp -R "${srcdir}/opt/Everdo" "${pkgdir}/opt/" # Install the .desktop file install -D -m644 "${srcdir}/usr/share/applications/${pkgname}.desktop" "${pkgdir}/usr/share/applications/${pkgname}.desktop" # Install the icons for icon_size in 32 64 128 256 512 1024; do icons_dir="/usr/share/icons/hicolor/${icon_size}x${icon_size}/apps" install -d "${pkgdir}/${icons_dir}" install -m644 "${srcdir}${icons_dir}/${pkgname}.png" \ "${pkgdir}${icons_dir}/${pkgname}.png" done -- David C. Rankin, J.D.,P.E.

On 8/16/22 07:05, Siard wrote:

Why, AppImages can just be made executable and then executed.

For example, I always had a package like Everdo-1.7.8.AppImage in /usr/local and a file named 'everdo' in /usr/local/bin containing this simple script:

#! /bin/sh /usr/local/Everdo-1.7.8.AppImage

so I can start the program with the command 'everdo'.

Okay, I got it. I stay miles away from any flatpack, docker or other containerized nonsense. The size and version duplication is just not my taste. A simply "hello world!" Qt application can take of 100M of dependencies and if you change a minor version you compile against, you can need another 100M of dependencies for "hello world2!". If /usr/local/bin permission are reset -- find out what in sysconfig or apparmor is doing it and get rid of that setting. That would drive me nuts. (yes there is a good argument to restrict ownership of /usr/local/bin for new users -- but, there is no reason you don't have full control over that too) -- David C. Rankin, J.D.,P.E.

On 2022-08-17 09:15, David C. Rankin wrote:

On 8/16/22 07:05, Siard wrote:

...

If /usr/local/bin permission are reset -- find out what in sysconfig or apparmor is doing it and get rid of that setting. That would drive me nuts. (yes there is a good argument to restrict ownership of /usr/local/bin for new users -- but, there is no reason you don't have full control over that too)

This is, usually, a security feature. There are many permissions that if you change them to your liking, "something" changes them back. Has existed for ages. For the same ages, a mechanism has existed to change those permissions to your liking. Start with: ls /etc/permissions* -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)

On Tue, 16 Aug 2022 08:06 +0200, jdd@dodin.org wrote:

Le 15/08/2022 à 22:59, Siard a écrit :

...

As an example, I can download Everdo-1.7.8.AppImage from https://everdo.net. What would be the most logical place to put this AppImage, and the right way to start it?

depends how many users you have. Me, being the only user of my computer, simply keep them in ~/Download. If it's a product I use a lot, I add a folder for it (ie: kdenlive or digikam), with several appimage in it, in case the new one have a problem

and I add a link from my plasma desktop

I'm also the only user of my computer. Just wondering what the official location would be, after Per Jessen noted that /usr/local is not meant for this. I guess a local program should be put into /opt, with a link or script in ~/bin pointing to it.

On 2022-08-16 14:25, Siard wrote:

On Tue, 16 Aug 2022 08:06 +0200, jdd@dodin.org wrote:

...

Le 15/08/2022 à 22:59, Siard a écrit :

...

As an example, I can download Everdo-1.7.8.AppImage from https://everdo.net. What would be the most logical place to put this AppImage, and the right way to start it?

depends how many users you have. Me, being the only user of my computer, simply keep them in ~/Download. If it's a product I use a lot, I add a folder for it (ie: kdenlive or digikam), with several appimage in it, in case the new one have a problem

and I add a link from my plasma desktop

I'm also the only user of my computer. Just wondering what the official location would be, after Per Jessen noted that /usr/local is not meant for this. I guess a local program should be put into /opt, with a link or script in ~/bin pointing to it.

Er... no. If it is root who is installing something for everybody, he would install the rpm normally, or if not an rpm, would drop the program somewhere under /opt, and maybe create a link under /bin (not ~/bin). A locally built program would go under /usr/local/. If it is you who is installing something, you would always install under ~/bin, because it is a program for your own use, not anybody else, and because you do not have access to install it anywhere else. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)

On Tuesday 16 August 2022, J Leslie Turriff wrote:

On 2022-08-15 13:21:47 Per Jessen wrote:

...

|Siard wrote: |> /usr/local/bin is owned by root with permissions 755, so as a user I |> cannot put a script in there. |> |> I can change the ownership, but every time after a reboot it is owned |> by root again, with permissions 755. |> |> Does anyone know where this is set, and/or how I can make |> /usr/local/bin permanently make writable for a user? | |It isn't meant to be. /usr/local is for local stuff, i.e. not vendor or |system.

Indeed. I have a separate partition mounted at /usr/local, where I keep stuff that I want to preserve across installation events. I have set the permissions the same way as /tmp has, so that I can put stuff there without having to change to root.

I used to do that for the same reason. In more recent years I've kept all the preservable stuff in the one filesystem so local is now a bind mount our of home: LABEL=home /home ext4 noatime,user_xattr 1 2 /home/local /usr/local none bind,user_xattr,noatime 0 0 This simplifies space management, backups, and migration. I generally leave things in local as owned by root, they are mainly local scripts for backups and other maintenance. I add sub-folders to /usr/local owned by me for software I look after, for example all my developments tools are under /usr/local/toolset/ which is owned by me. I also create specific product folders, also own by me, for example, I install SweetHome3D direct from tar.gz into /usr/local/SweetHome3D. Michael

On Mon, 15 Aug 2022 16:34 -0400, James Knott wrote:

On 2022-08-15 13:41, Siard wrote:

...

/usr/local/bin is owned by root with permissions 755, so as a user I cannot put a script in there.

I can change the ownership, but every time after a reboot it is owned by root again, with permissions 755.

Does anyone know where this is set, and/or how I can make /usr/local/bin permanently make writable for a user?

Why don't you put your scripts in ~/bin?  That's your location for scripts.

After many years with another distro, I started to give OpenSUSE a try. All those years I had my downloaded programs in /usr/local or /opt, and scripts and links to those programs in /usr/local/bin. The fact that they should be put into /bin instead, is completely new to me.

bent fender wrote:

On Mon, 15 Aug 2022 22:57:44 +0200 Siard wrote:

...

The fact that they should be put into ~/bin instead, is completely new to me.

If you do that, then why have /usr/local/bin at all?

For stuff that is local, but meant to be accessible for all users. -- Per Jessen, Zürich (23.5°C)

On 2022-08-16 14:10, Siard wrote:

Per Jessen wrote:

...

bent fender wrote:

...

Siard wrote:

...

The fact that they should be put into ~/bin instead, is completely new to me.

If you do that, then why have /usr/local/bin at all?

For stuff that is local, but meant to be accessible for all users.

Since I am the only user of my PC, I guess it does not matter much then.

You could "add" permissions so that your user can write files there. setfacl(1), acl(5), getfacl(1) -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)

Op maandag 15 augustus 2022 22:57:44 CEST schreef Siard:

The fact that they should be put into /bin instead, is completely new to me. The mentioned "~/bin" is not "/bin"

-- Gertjan Lettink a.k.a. Knurpht openSUSE Board openSUSE Forums Team

Siard writes:

After many years with another distro, I started to give OpenSUSE a try. All those years I had my downloaded programs in /usr/local or /opt, and scripts and links to those programs in /usr/local/bin.

The /usr/local hierarchy is used for third party local programs that is installed by the administrator and is not supposedly writable by any other user other then root: ,---- | The /usr/local hierarchy is for use by the system administrator when installing | software locally. It needs to be safe from being overwritten when the system | software is updated. It may be used for programs and data that are shareable | amongst a group of hosts, but not found in /usr.[1] `---- I use this hierarchy extensively since I compile my own system-wide versions of Emacs, ffmpeg and mpv, etc. Of course this can be override by "/etc/permissions.local". The /opt hierarchy is used for programs (mainly commercial) that needs its specific version of libraries.

The fact that they should be put into /bin instead, is completely new to me.

He didn't say /bin, but ~/bin which is location in your home directory. Charles Footnotes: [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html