Is there a way to set up a project in Eclipse so that if my code has a reference to the system root directory then it will point to my workspace instead? (I am not seeing anything in the Run Configurations that would help me with this.) Something like the equivalent of making a sym link / that points to my workspace directory.
I'm working on a perl project that has absolute references to the hosting Linux file system in what would be the production environment. Those directories don't exist in my development Eclipse environment. My workspace is located in an NFS space mounted on a cluster of servers that run Eclipse I access in my laptop via client software.
So root can be any server's local space within the cluster and I don't have any access to anything above the workspace, and so I can't create the directory structures I need. I would rather not hard-code alternate directory paths to accommodate differences between the sandbox and production environments and having to comment them out when deploying to the prod environment.
I'm not finding a straightforward answer online. Maybe I'm not articulating the question correctly and help with that would also be appreciated if that is the case.
No. Good practice is to have paths like that configurable at runtime, usually via an environment variable or command line argument, specifically to accommodate changes between development, sandbox, and production environments.
Related
I have a web app in my local environment that needs to upload some files to a path like /images/app/customer. That path does exist on the production server but obviously doesn't on my machine.
Is there a way to "simulate" the existence of that directory on my environment?
I'll answer my own question after one year of experiments. It turned out that the best and clean way is to create the directory in a sandboxed environment like Docker or any other virtual machine out there.
I'll try to keep this question short, but it is in 2 parts, please:
Where should config files for nodejs/npm CLI tools be saved?
What should they be called?
Let's say I write a node.js CLI tool that, for example, grabs today's weather and displays it in terminal. I call it weather-getter. Note, the main goal is not to be called programmatically, but typed into terminal like BASH. It is intended to be run by typing its simple name after installing globally, or via a directory in the user's local /bin. (Sudo is not required for its install.)
This project would be installed normally via npm. It can receive a zipcode via an argument like:
gavin#localhost:~$ weather-getter -z "12345"
OK the program works fine like this. My next step would be to allow the user to save a config file somewhere, and pull from that config file for defaults. Similar to a .vimrc file. This config might look like this:
{
"zipcode": "12345",
"language": "en",
"unit": "fahrenheit"
}
I suppose it should begin with a dot. I also suppose it should be located in the npm module install, and not in ~/. Or should I consider using ~/ or /etc/ or ~/.config or ~/.local like many other programs? Should node programs try to use a common directory, such as ~/.config/node/ or ~/.config/npm/? And if the file is in there, should it begin without the dot?
Note: My question is not about reading/writing a file with node.js, just recommendations on the config location and naming convention. Thank you!
Since this is a generic CLI application (which only so happens to be implemented in Node.js) installed into the system path, you should follow the best practices or rules established for the target operating system.
Unix/Linux/OS X, similar
In order of priority, these would be (but are not limited to):
~ (User's home folder) - many programs store user-level config in their home directory, usually in a dot-prefixed file, followed by the application's name (or similar) - i.e. ~/.weather-getter
/usr/local/etc, /etc - system-level configuration files. These should generally apply to all users in the system and thus should take less precedence than settings in home folder. The difference between these two etc paths is usually that the former is used for user-installed programs, whereas the latter is for system-level programs (this is especially true for Mac users using Homebrew). This distinction is, however, not always respected and therefore both locations should be checked for config files (preferrably with the /etc directory having lesser priority).
Your application's root - these should be the default settings for your application, a fallback when no user or system config has been found.
Other locations may be considered if needed.
Windows
This is usually somewhere within %APPDATA% directory if your app allows GUI or at least CLI configuration management, or the Windows registry (using winreg, for example). I have personally little experience with Windows development/CLI so I welcome any further comments or answers on this topic. I believe using the user's homefolder would also be acceptable as long as the file can be marked as hidden (so it does not clutter the view).
Some general considerations
Many CLI applications install their default configurations into one of the mentioned locations so the user has a good starting point when configuring your app
The way your configuration options are treated when multiple configuration files are present (are they merged in some order? Is only one used? Which one takes precedence?) is completely up to you, but you should make it clear in your documentation, perhaps even mention it in the configuration files themselves
If your application requires multiple configuration files it is preferred that they are grouped in their own folder
Update about dotfiles
The reason why some files or folders are prefixed with a dot is to hide them from users' normal view (i.e. when browsing their home directory via a GUI). It is therefore common practice to use dot-prefixed file/folder names when storing configuration files in directories where users normally operate, but not do so when storing config files in system-level folders.
The ospath package has a function data() which returns a sensible location for such files for each of the major platforms.
I have created a synchronized project in Eclipse so that I can develop on my Windows workstation without the overhead caused by running eclipse on our company's build server. However, the problem I'm having is that the indexer is using my Cygwin includes for things such as the stdlib which aren't the ones I wanted to include. Is there a way to include remote includes from the linux build server for things like the std lib? The only idea I have right now would be to create a mapped cifs mount to my windows machine that has access to the header files, however I don't know if that would work.
Look at "Remote Include Paths" (bottom of page). Let us know on the ptp-users mailing-list if it doesn't work.
Is there a standard location on Linux (Ubuntu) to place external config files that a web application (Grails) uses?
UPDATE: Apparently, there is some confusion to my question. The way Grails handles config files is fine. I just want to know if there is a standard location on linux to place configuration files. Similar to how there is a standard for log files (/var/log). If it matters, I'm talking about a production system.
Linux configuration files typically reside in /etc. For example, apache configuration files live in /etc/httpd. Configuration file not associated with standard system packages often live in /usr/local/etc.
So I'd suggest /usr/local/etc/my-grails-app-name/. Beware that this means you can't run two different configurations of the same app on the same server.
I don't believe there is a standard location. You usually define the location for your external config files via the grails.config.locations property in config.groovy.
EDIT
After reading your comment, I suppose the standard locations would be:
Somewhere on the classpath
OR
In the .grails folder in your home directory.
As these are the defaults in config.groovy file.
grails.config.locations = [ "classpath:${appName}-config.properties",
"classpath:${appName}-config.groovy",
"file:${userHome}/.grails/${appName}-config.properties",
"file:${userHome}/.grails/${appName}-config.groovy"]
There's a plugin Standardized external configuration for your app which you might find useful if the grails.config.locations parameter is insufficient.
I have a web dev. client using a shared host that doesn't allow shell access, and thus no access to SVN, Git, etc. I've tried to convince him to move to one of the many cheap options that allow it, but he won't do it. If I use version control on my staging server, are there any tools that will allow me to replicate the changes to production via ftp? Locally I have both mac & windows, the staging server is linux, so something that works on any of those platforms....
Using your Linux staging server you could keep a separate checked out copy that you use specifically for that host and then use a utility to mirror that directory with the host server.
LFTP is useful for this kind of thing. Its available for most Linux distributions and includes a 'mirror' function:
Mirror specified source directory to
local target directory. If target
directory ends with a slash, the source base name is appended to
target
directory name. Source and/or target can be URLs pointing to
directories.
Some kind of ftp mirror software is what you need. Not tested it but a quick search gave me this Java application. You could run that over your up-to-date checked out repository.
Good thing for keeping SVN repo and FTP copy in sync is svn2web. May I suggest creating separate branch for production copy and do merges to that branch for uploading to production server.
You probably need to write a batch file that is able to
Export the SVN repository
Upload the exported files to your Linux server via FTP
Short of finding / implementing some FUSE based CoW file system that supports immutable versions .. I'd just find another (more developer friendly) host. As far as I know, no FTP server supports this natively, nor can I think of any elegant means of putting it in place with script hackery.
I could be wrong.
This question (and answer) really helped me just now as I implemented version control via gitolite on a separate server and lftp.
Here’s what I did:
Set up gitolite on my ubuntu staging server
created base repo (i.e. foo.git) on staging server
cloned foo.git into working directory on staging server
cloned foo.git into working directory on local development machine
Developed locally
Pushed changes to foo.git repo on staging server
On staging server, logged into working directory, and pulled in changes from foo.git
lftp-ed into shared host (like you mention above)
Once in shared host, ran:
mirror -R --only-newer --delete --parallel=10 /source/directory/ /target/directory
Notes on the mirror command options:
-R - this pushes the source/directory to the target/directory. (mirror pulls in from target to source without this, think reverse)
—only-newer - without this option, even if you only changed one file, the mirror command will send all the files in the source directory over to the target directory. with this option only the changed (newer) files are transferred over the wire.
—delete - deletes files that are no longer in the source directory but still in the target directory. one of my pushes involved deleting expired assets. without this option, the same files would have stayed put on my shared host after executing the mirror command.
—parallel=10 - transfers 10 files at once (instead of 1 by default). this made the process much faster
While this is what worked for me, I’m sure there are ways to improve on this. I was grateful for this question and thought i’d share my experience.
Rsync will do this over an FTP connection. You probably already have it installed if you’re on a Unix-like system.