I am working with environment value, $PATH. And I found that $PATH includes /snap/bin directory which does not exist. What does the path work? Can I remove it from $PATH or should I leave it?
Please give me your suggestion. Thank you very much?
It is a new-new Canonical thing to bundle and distribute applications.
See for example this developer link by Canonical.
Personally, I also find it somewhat odd that they went into the top-level via /snap but Oh well.
I may yet come to use it one. So far plain docker serves me well, besides of course building .deb package the old-fashioned way.
As for removing the PATH entry: it only saves you a few bytes, plus nanoseconds in lookups and may break a future deployment involving snaps. Your box, your call. I left mine.
Related
I just unzipped sublime_text_3_build_3143_x64.tar.bz2 and have a nice copy of the sublime_text_3 directory in my downloads folder.
Where is the right place to put this file in Centos? Maybe somewhere in /user/local/?
Also do I create a link to the executable or set a Path?
Just looking for favorite (best?) practices.
As has been pointed out in the linked article in the question comments, /opt is preferred by some, and in fact according to this answer, /opt is where you would locate "unbundled packages". Of course, it also goes on to say that these sorts of packages should also package the binary in a bin subfolder, which Sublime does not, for what that's worth.
If you want to follow best practices, that's probably where you should place the folder. If nothing else, I would assume that any Linux OS that has a package manager for doing upgrades is going to stay well clear of /opt based on what it's used for, which will make sure that something untoward can't happen.
As to whether you would create a symlink or add that folder to the path, I'm not so sure. My own personal philosophy is that the PATH isn't something that needs to have an entry for every application that I install.
My own recommendation would be to create a symlink somewhere that's already in the path and you're good to go. The linked article mentions putting the link in /usr/bin. The Filesystem Hierarchy Standard says of this path:
This is the primary directory of executable commands on the system.
I would take from this that this is an acceptable path to put the symlink in.
In the end, it doesn't matter to Sublime where the folder is placed, since it determines the location of the shipped packages based on where it's binary is located, and the configuration information is always in a known place.
When I run cmake with some projects such as caffe or gflags, it writes some information at the system level. Specifically, on a linux system, it generates some directories such as $HOME/.cmake/Caffe and $HOME/.cmake/gflags
My problem is that this information is hereafter used for any project I compile. As a consequence, the programs referenced in $HOME/.cmake are (partially) found, even if I do not want it (as far as I am concerned, I define external variables to control with external programs cmake is allowed to consider for a given compilation).
y current solution is to delete the directory $HOME/.cmake when needed (i.e before compiling my new program). I consider to add a rm -rf $HOME/.cmake in .bashrc but this not fully satisfactory (nor sophisticated!). Could anyone propose a better solution ?
NB: the expression "system cache" in the question is probably wrong. I would be grateful to get a better term. Thank you for any feedback on this (actually, if I knew the correct expression, I may have already found the solution on the web...)
Edit:
Once you know the "system cache" is actually the User Package Registry the answer is easy. See below...
The directory $HOME/.cmake is the User Package Registry. To avoid find_package() to search in this directory, use option NO_CMAKE_PACKAGE_REGISTRY. See point 6 of its documentation:
https://cmake.org/cmake/help/v3.0/command/find_package.html
I saw that there is a lua plugin for eclipse and there is a docpage on the awesome main page api_doc and all the .lua files in /usr/share/awesome/lib.
So I thought it must be possible to create a Library or Execution Environment so that one has tabcompletion and docview.
So I tried making my own Execution Environment:
wrote the standard .rockspec file
downloaded the documentation made an ofline version of it and put it in docs/ folder
ziped the files and folders in /usr/share/awesome/lib
ziped all up
tried it out ... and it failed.
When I try to view a documentaion for a .lua file I get "Note: This element has no attached documentation."
Questions: Am I totaly wrong in my doing (because I have the feeling I am)? Is there any way to edit the rc.lua with tabcompletion and docview?
Koneki will probably take a while to setup, but it's definitly worth it. Going for the".doclua"(by using version 1.2) would certainly make it, but I doubt that using a script to generate the information you need, would work out on the long run.
Most likely, you'll probably pass a bit of time to define what kind of object you're dealing with every time you come across one. The right to do, would be to actually take the time to see if the object/module/inner type inherit from an another object, so can actually have more completion feature as you keep using autocomplete to go from one object to another by pressing "dot"+ctrl_space.
In an ideal world, one person could probably make it right and share to other, so they can enjoy a full featured autocomplete editor.
Found solution for eclipse.
First off the idea of setting up an Execution environment was the wrong one.
So the whole thing about downloading the doc although.
For more information on that visit eclipse Wiki for LUA Development Tool.
The right thing to do is to add a source folder which contains the /usr/share/awesome/lib directory.
The bad news is that my comment from above was totally right, which means one has to configure each .lib file in /usr/share/awesome/lib to meet the requirements of the Documentation Language described here.
Than editing the rc.lua (which one can add to the project in eclipse) works with tabcompletion and doc view.
Since the Documentation Language used in the lib files is similar to the one used by "LUA Development Tool" one has not to change many things. Maybe there are even scripts for that.
This happens occasionally in some projects I'm involved in that are using MKS as version control tool. A file is checked-out, modified and then checked-in but it was forgotten to be included in the related Change Package.
Is there a way to achieve this after the fact?
Thanks.
Delete revision (yes, the command exists), and then check in again, this time tied to the CP. Make sure you preserve the working file in the meantime.
If you've new revisions on top of it, you're out of luck.
I don't think that what SzG said really exists ( if so, I'd like to know too :) )
Once any operation is done without a CP, that operation can't be associated to a CP.
A solution for the future would be, to make using the CP mandatory in the project setup.
I keep hearing this is a path issue with cygwin. It is prevent emacs from working within my cygwin. When I execute find on the cli (not bash/cygwin) I get the same error not matter what I type. I've read this is a problem with path creation within cygwin and that it should be prepending itself to the path. As you can see it is doing that.
Here is my /etc/profile
PATH=/usr/local/bin:/usr/bin:/bin:$PATH
export PATH
Problem is that as everyone else stated, emacs is using find.exe provided by windows. To change this, you need to change your %userprofile%.emacs file.
As nobody else states (even faq!), this file is not created automatically anymore. Go into Options > Save options the mini-buffer (one line at the bottom of emacs) will tell you where the file is being written to.
Go in there and add this line (You've installed cygwin at c:\cygwin, right?):
(setq find-program "C:\\cygwin\\bin\\find.exe")
You may need to restart Emacs for this to take effect.
Just add this line to you .profile
alias find='/cygdrive/c/cygwin/bin/find.exe'
Oddly-enough, I needed to use
(setq find-program "/bin/find.exe")
instead.
But thanks for the suggestion Drew.
Adding a setq find-program [msys2 or git path] in my init file, as suggested (I tried different forms), didn't work for me. "C:\Windows\System32\find.exe" is first in the path if I type where find in eshell and I didn't find how to remove it, only how to add others, which doesn't solve the problem.
So I share here the more radical, but working (also in Powershell), solution I used: replacing the find.exe in "C:\Windows\System32" with the one from "C:\msys64\usr\bin". I kept the old file in case, but so far so good. You need to change the permissions for this operation (see here how to gain full control, but I suggest only applying this to the file, not the whole folder, and putting things back after ;)).