I'm new to Sublime Text 3, but I really like it so far. I'm spending a lot of time getting to know the program, installing useful packages, etc.
Q: Is there a smart way to save/archive your configurations periodically? I'm thinking down the road about Disaster Recovery, setting up a new machine, etc.
I did find this answer installing multiple packages in sublime text 3, answered by Thomas Lee
Batch installation of packages is smart. I can set up a comma-separated package list and just let ST3 take care of the installation; however, that's only for packages.
Can the same be done for EVERYTHING? (Packages, Preferences, Snippets, et. al?)
Generally speaking, any customizations that you make to Sublime end up as files in your User package, which you can see by selecting Preferences > Browse Packages... from the menu.
Example contents of the User package include (but is not limited to):
Modifications to settings, which are stored in sublime-settings files. This is true for both Sublime settings (Preferences.sublime-settings) as well as the settings that you have customized for any packages that you have installed (for example Package Control.sublime-settings).
Any snippets you have created, which are stored in sublime-snippet files
Any plugins you have created, which are stored in py files.
Your own specific customizations to Sublime resources, either from core Sublime or from other packages. This includes things like sublime-menu, sublime-keymap, sublime-commands, sublime-color-scheme and so on
As such, pretty much every customization that you may have done to Sublime is related to that folder, which means that if you want to save your Sublime setup you want to save the contents of that folder somewhere. This also means that when you set up a new computer you can use that saved copy to get the new machine ready to go.
It's highly recommended that you use Package Control to install packages; based on your question above I assume that you're doing that. The good news for you is this: the Package Control.sublime-settings file (which is stored in your User package) contains a list of all of the packages that you've told Package Control to install.
When you start Sublime, one of the things that Package Control will do is verify that the list of packages that you've told it to install are currently installed, and if they're not, it will install them for you.
This means that to set up a new machine with a Sublime install, you can install Sublime, install Package Control, copy your saved User package into the appropriate location, and start Sublime; Package Control will automatically install all of your packages for you without having to follow the steps outlined in the answer you linked in your question.
In fact there is a page in the Package Control Documentation that describes how to Sync your User Package to do this very thing.
The Packages folder that your User package is stored in, as well as the Installed Packages folder that Package Control installs packages into are stored in the Sublime Data folder; the area where Sublime stores files specific to your user on your computer.
If you're using Sublime on Windows and you've used a Portable installer, this folder is stored inside of the Sublime install location. In all other cases (i.e. "normal" windows installs, or on MacOS or Linux) the Data folder is stored in your home directory and is left alone should you uninstall or reinstall Sublime.
Related
On my website I need to give users an ability to download and easily start my executable (AppImage binary) on Linux.
For Windows version it is just .exe which works after downloading and clicking:
Download file
Click on file in browser downloads panel to start it
For Linux user now needs to do following:
Download file
Open folder containing file from browser downloads panel
Right click on it to add exec permission
Click on "Allow execution of this file" checkbox
Press Ok
Click on file to start it
It is hard to explain this flow for regular user, it makes users leave away.
Is it possible to minimize it to minimal clicks as on Windows?
Any advises appreciated to achieve minimal clicks. I can compile app for any format (its on electron but I can process it before upload)
I thought about using .deb . It will limit app for Debian-based only, but main problem in same time that I did not find ability to run post installation to exec app, and I don't want ask user to enter start menu.
Executable bits are a basic UNIX security measure thus it is not really easy to work around this (for good reason). Thinking about this, for the specific case of downloaded files, Windows also applies some restrictions (special NTFS stream which tells Windows Explorer to warn about the dangers of an executable file from the Internet).
You can of course provide your application as a .tar.something archive and store executable files in there. After extraction, they will normally have the correct execution bits set.
The option with the deb-package can also solve your problem (for some users) but is a little more complicated:
User downloads deb package
User clicks on deb package and has some program installed that provides a GUI for installing packages (like gdebi). Like on Windows there will be some "security check" in form of a dialog box where the user needs to enter a (sudo) password. Afterwards, apt will install the package
If the package is created correctly, it can transport the executable bit correctly such that no explicit permission change is needed afterwards. If for some reason there is need to do something post-installation, Debian packages can provide postinst scripts which run (as root!) at the end of the package's installation.
In any case, as dealing with executable files is a common procedure on Linux, it might not scare so many users away as expected. If you want to make it comfortable for the users, provide the package as they expect/like them. On Windows I would think that to be a .msi package and on Linux I prefer a package corresponding to my distribution (.deb, .rpm).
If you want the users to update their packages regularly (good for security) then it is helpful to provide a "repository" that users can add and install your package from. Of course, "the best" is having a package as part of the distribution, but that is quite some effort and needs to pass a lot of "quality assurance gates" :)
After make of sources I have compiled executable file and data directory with images for it. What should I do at "make install" phase to correctly install these files to the linux system? And how then application can find installed data (in case when binary and data are placed in different directories)?
Are there any standards for this?
There are many ways to install packages on a Linux and Unix system much like any other operating system. The normal method of installing software is through your distributions package manager. Package managers are different based on the distribution you are using but in general they take a package (a file filled with binaries source code or other files required for the piece of software to work) and place it into the corresponding places as defined by the Filesystem Hierarchy Standard. When you do a make install what you are doing is bypassing the package manager and placing the binaries into the hierarchy standard directly making it nearly impossible for the package manager to handle or account for that programs existence. This is not a good thing for anyone as it is hard to keep a system secure or stable with many unknown files placed throughout the system. Please if you want to install something manually please take a look at the filesystem hierarchy stabdard and place the files under the appropriate folder in either /opt and create a symlink in an area covered by your PATH variable or under /usr/local/
I have what might be a simple question and might be....a more complex one. We are preparing to add NSIS to our software, that is, we want people who use our software to be able to create installers using NSIS, but through our software. (We'll be creating functions using NSIS, acknowledging NSIS, etc.) What I am trying to figure out before we get started is how many/what files our customers will be required to have on their hard drive for NSIS to work. So, we just need to know if nsis can be used standalone or if it requires the user to install it into program files, or if it requires a lot of different files in AppData - If we have to bundle a few .dlls, that's not a problem and is expected. Ultimately, if we end up having to bundle NSIS as well, that's fine - We just want to make sure it'll work on other people's computers without telling them to go download it.
MakeNSIS does not read/write from/to the registry or anywhere else and only needs a handful of files for minimal operation.
To build a simple installer you need:
NSIS\MakeNSIS.exe (Just calls Bin\MakeNSIS.exe)
NSIS\Bin\MakeNSIS.exe
NSIS\Stubs\* (If you are only going to use a specific compression mode you only need one, and the uninstaller file if you want uninstall capability)
If you want to use the Modern UI you need its header files, some files from Contrib (Graphics and UI) and system.dll and nsDialogs.dll from the plugin folder.
Everything else is optional but I would recommend that you also bundle:
NSIS\Include
NSIS\Plugins (You can remove stuff you will never need; dialer, splash etc)
NSIS\Contrib (Language files, graphics and UI)
You can find license information here.
You could also just ask the user to install it and enter the path to it in your setup program...
I would just include all of the files. (It's only 5MB or so) NSIS has a zip archive as well as exe installer that includes the necessary files. (Or just zip up the installed directory from exe installer).
From my experience, NSIS does not need to be installed to work. I run a fleet of build servers that build NSIS-based installers, and they each just have the files extracted in a directory. The installer is never run on them. This should mean there are no DLLs to register or things like that.
Just make sure you are following whatever their licensing terms are - I have not reviewed redistribution/bundling of their files in another product, since that is not something I do.
I'm preparing to update my Eclipse to 4.2 version and I'd like to solve one problem that has been annoying me since many many years. Right now my installation looks like this:
eclipse folder is located in /usr/local/share. This is a system-wide directory, yet Eclipse requires write permissions for a user, which goes against unix permissions philosophy.
I have a workspace and all plugins that I install go into .metadata folder within this workspace.
What I'd like to achieve is:
first of all, do not install plugins in the workspace directory. I'd like to see plugins installed either somewhere in my home directory or - if it is necessary for the user to have write permissions to eclipse directory - in eclipse directory itself.
take away users write permissions for eclipse directory. This will of course prevent installing plugins there, but I won't mind installing them somewhere in ~
preferable solution would be to take away write permissions for the user to eclipse directory and be able to install plugins within that directory as root. So when I want to add new plugin, I start Eclipse with root privileges, install the plugin (it goes to eclipse installation directory) and then I can use this plugin as non-privileged user.
Although I'm not a linux user, I'm 99% certain that plugins will never be installed into a workspace; that's just contrary to how workspaces and plugins are separated in Eclipse's architecture. A workspace may have configuration/cache data that is stored with file/folder names resembling plugin names, but the actual plugins are stored elsewhere.
I think if you read the multi-user install guide from the online help, you'll find one of the options outlined there will suit your needs.
Take a look at the shared install documentation for instructions on how to setup a base eclipse that a user doesn't have write access to and allow user-local install of plugins.
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fmulti_user_installs.html
I'm trying to update our installer so a user can simply double-click on a file and have all the dependencies and our software installed easily. This is a suite of applications that will are deployed on a clean Ubuntu 8.04 (Hardy Heron) installation. I have investigated making a .deb file, but listing the dependencies doesn't work, because there isn't any Internet access available. And, any script that would set up a local APT repository would still need to be run from the command line. Is there a way to put a .deb file inside of a .deb file?
I know many companies ship shell scripts that you have to chmod +x, and then execute. This is not acceptable. It is ridiculous that this isn't possible; especially considering the distribution and architecture is fixed.
If you are totally confident that it will be installed on the same system every time, you can find the list of package dependencies yourself, fetch them from the Ubuntu repositories, and package them up with your software. You just have to be clear that your software is for a specific version, probably deal with things like keeping up with maintenance releases.
You can also easily install with a script. As for your complaint about making scripts executable, well, I don't know how you're shipping your product, but since you say it's going somewhere without Internet access, I assume it's going to be copied from some kind of media. If you make the script executable when you put it on that media, you're done.
If you'd like to do this using packages, you can create a CD-ROM which contains a package repository. You can find all kinds of information on this with Google Search. For starters, try this - it's a GUI for doing it. http://aptoncd.sourceforge.net/
A makeself self-extracting executable that starts the install script using sudo will work.
The user can either run it from a terminal (after chmod-ing it) or can double-click it and tell it to "Run" from the prompt.
It's possible to put deb-files into deb-files. The only thing you need to do is to configure the appropriate scripts.
A .deb-file consists of:
1x control.tar.gz: contains a file "control" (describes the package) and optional files like "postinst" (script executed right after extraction). There are other files you might include, and Google Search should deliver information about the available scripts.
1x data.tar.gz: contains some structure of root-filesystem which contains files/folders that need to be (re-)placed. Additionally, you may configure the behaviour in the mentioned scripts.
1x debian-binary: as far as I remember, this is simply a version number in a file. I don't know exactly what it means; just remember that in most of the cases this is 2.0.
So you now may put your .deb files in the data-package. Those are extracted by your script... and installed using:
# dpkg -i yourpackage1.deb yourpackage2.deb