making a new file in /usr/local/bin

[bserce123]

I go to /usr/local/bin and do a dir. Nothing there, so I try to open a new file there. Refused. I try altering permissions. Refused.
I have a now-working .py script in another directory. How can I move it to /usr/local/bin, please?

[W. H. Heydt]

I don't recommend doing it, but the problem isn't permissions. It's ownership. Move your file by using "sudo mv <filename> /usr/local/bin".

However, a far, far better solution would be to create a 'bin' directory in your home directory--e.g. /home/pi/bin--and put your executable file there. After relogging, your own ~/bin directory will be in your path and you can execute it from anywhere. Here's an example on one of my Pis...

Code: Select all

pi@pidrive:~ $ echo $PATH
/home/pi/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
pi@pidrive:~ $ ls bin
k2  k80  kx  kxs  kxs2  play  qx  runclock  startkdfc  xxx

[bserce123]

I don't recommend doing it, but the problem isn't permissions. It's ownership. Move your file by using "sudo mv <filename> /usr/local/bin".

However, a far, far better solution would be to create a 'bin' directory in your home directory--e.g. /home/pi/bin--and put your executable file there. After relogging, your own ~/bin directory will be in your path and you can execute it from anywhere. Here's an example on one of my Pis...

Code: Select all

pi@pidrive:~ $ echo $PATH
/home/pi/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
pi@pidrive:~ $ ls bin
k2  k80  kx  kxs  kxs2  play  qx  runclock  startkdfc  xxx

Thank you .I used your directions to move my script tp /usr/local/bin and it shows that directory as being on the $PATH already, and the script's permissions there to be owned by pi but none of the options under 'Open' allow me to launch the app, though I can still do it if I bring up terminal and enter python3 v3.py (the script's filename). I haven't tried your 'opening' a /home/pi/bin yet because previous advice said to use /usr/local/bin (which IS on the path already), mainly because I'm lost in a welter of what seems to be conflicting needs. If you or anyone can bear with me and put me right, I'd be grateful.

[bserce123]

SOLVED

I hope I have not wasted your time but by changing the shebang thing to #! /usr/bin/python3 the script now executes without the need to invoke python. The bit about moving the script was, however, invaluable, so many thanks again.

[jahboater]

Just FYI , see the install command "man install" which is a common way of copying files to such directories.

[achrn]

a far, far better solution would be to create a 'bin' directory in your home directory--e.g. /home/pi/bin--and put your executable file there.

Why?

Why is a user-specific bin directory better? I'm struggling to see any benefit - other users won't be able to execute a file put there, and if there are no other users then what's the problem with using the system directory? A user-specific bin directory is not, to my mind, equivalent to the /usr/local/bin directory, and a file that should be in the latter will not behave equivalently in the user specific bin directory. I don't see it as 'better' at all, let alone 'far far better'. What are your reasons for considering it better?

[Martin Frezman]

a far, far better solution would be to create a 'bin' directory in your home directory--e.g. /home/pi/bin--and put your executable file there.

Why?

Why is a user-specific bin directory better? I'm struggling to see any benefit - other users won't be able to execute a file put there, and if there are no other users then what's the problem with using the system directory? A user-specific bin directory is not, to my mind, equivalent to the /usr/local/bin directory, and a file that should be in the latter will not behave equivalently in the user specific bin directory. I don't see it as 'better' at all, let alone 'far far better'. What are your reasons for considering it better?

I agree. But, FWIW, I do usually go the ~/bin route myself.

Re: the above text. As is often the norm on these forums, the poster way exaggerates for dramatic effect (i.e., overdoes it on the superlatives, much like our current President Superlative). It is not that big of a deal, and it is not "far far" better.

As you note, on a single user system (which 99.999% of all Raspbian Pi systems are), it doesn't matter. The primary advantage of the ~/bin method is that you can do it all without invoking superuser privs. The primary advantage of the /usr/local/bin method is that it is available to all users, not just the 'pi' user. Of course, on a single user system (which 99.999% of all Raspbian Pi systems are), this is a moot point.

In a way, /usr/local/bin is kind of a relic of the past - from when Unix/Linux was a primarily a timesharing system with multiple users. It has evolved over the years to being similar to Windows - a console based, single user system.

Note, incidentally, that it is not really true to say that other users (if there are any) can't execute the program if it is in ~pi/bin. They just have to have ~pi/bin in their PATH (or, of course, use a full path to execute it). And the point is that it is not facetious to say that other users (if there were any) would put ~pi/bin in their PATH - given that it is has been shown many times on this forum that if you do create other user(s), you pretty much have to make them a clone of user 'pi' (all the same groups and a bunch of other things) or stuff just doesn't work (for the new/other user(s)). So, this 'cloning' could well include putting pi's bin directory on their PATH.

[achrn]

Note, incidentally, that it is not really true to say that other users (if there are any) can't execute the program if it is in ~pi/bin. They just have to have ~pi/bin in their PATH (or, of course, use a full path to execute it).

Indeed, but if you're going to put a non-standard entry into the PATH, you don't need to put the file anywhere special - the OP could have left their file wherever it was and just edited PATH - so that's not a solution to the question I perceived being raised. I think that's an inferior solution anyway - you'd end up with a very long PATH if you updated it for every random place you'd created a script.

Can you elaborate on 'bunch of other things'? I never use a pi user (actually, my pis don't have a user 'pi', because I obliterate it from the SDcard before it first boots). I create my desired user to have the same groups as pi starts out, but I'm not aware of other stuff not working as it should. The only exception is my octopi install, I did find renaming the pi user to cause too many headaches there, but a new clean raspbian doesn't give me problems without a pi user.

[Martin Frezman]

I don't doubt that you can handle and fix the problems as they come up.

But most users can't/won't.

[PeterO]

Note, incidentally, that it is not really true to say that other users (if there are any) can't execute the program if it is in ~pi/bin. They just have to have ~pi/bin in their PATH (or, of course, use a full path to execute it).

If you had ever managed a properly set up multi-user Linux/Unix system you would know that that is not true.

PeterO

[W. H. Heydt]

a far, far better solution would be to create a 'bin' directory in your home directory--e.g. /home/pi/bin--and put your executable file there.

Why?

Why is a user-specific bin directory better? I'm struggling to see any benefit - other users won't be able to execute a file put there, and if there are no other users then what's the problem with using the system directory? A user-specific bin directory is not, to my mind, equivalent to the /usr/local/bin directory, and a file that should be in the latter will not behave equivalently in the user specific bin directory. I don't see it as 'better' at all, let alone 'far far better'. What are your reasons for considering it better?

The executable in question belongs to user 'pi'. Therefore, it belongs in a directory owned by 'pi'. If it is to be a generally used program, then it would belong in a system owned directory and should have the executable file ownership changed to 'root'.

Bear in mind that at any time, an upgrade to the system could rebuild any system owned directory and you would have to re-install anything you had put there. An upgrade shouldn't touch account owned directories, such as ~/bin.

It is quite possible that my opinions on this are driven by having used and worked on unix systems that had multiple *active* user accounts and I tend to think in terms of larger systems than Pis. I would maintain, though, that it is good practice to treat Pis that way as a matter of habit and not get into a habit that might cause problems should one eventually find oneself working with larger, production, systems.

[achrn]

I don't doubt that you can handle and fix the problems as they come up.
But most users can't/won't.

That's not what I'm saying.

What I'm saying is that in my experience there are no problems that come up. No problems have come up for me. What are the things that don't work if you create other users?

[Martin Frezman]

I don't doubt that you can handle and fix the problems as they come up.

[achrn]

The executable in question belongs to user 'pi'. Therefore, it belongs in a directory owned by 'pi'. If it is to be a generally used program, then it would belong in a system owned directory and should have the executable file ownership changed to 'root'.

Bear in mind that at any time, an upgrade to the system could rebuild any system owned directory and you would have to re-install anything you had put there. An upgrade shouldn't touch account owned directories, such as ~/bin.

It is quite possible that my opinions on this are driven by having used and worked on unix systems that had multiple *active* user accounts and I tend to think in terms of larger systems than Pis. I would maintain, though, that it is good practice to treat Pis that way as a matter of habit and not get into a habit that might cause problems should one eventually find oneself working with larger, production, systems.

The largest multi-user UNIX system I have administered had only about 100 active user accounts, so maybe yours really is bigger than mine, but I'm still not understanding why you know that putting the executable into the user directory is a 'far far better' solution.

You seem to be making an assumption that the script in question is relevant only to the user 'pi', and if that was the case (ie, we are talking about a script of relevance to only one user) then I agree it should be in the user's directory - I would never have put an executable that one (and only one) of those 100 users wanted to run into anywhere in /usr, but there's no evidence here that that is the scenario in question. Had you said (and if you mean) "If it's a script that is meaningful to only one user, it should be in that user's directory, and not a system directory", I'd agree with that, but we are far from establishing that as the situation in question.

An upgrade to the system should not obliterate /usr/local, at least not on anything I would regard as being a properly managed system. That's rather the point of /usr/local - that it's machine-specific stuff that differs from the more general defaults.