Here is a screenshot of what I can see inside my Cygwin directory:
I want to find out what each of these folders mean and represent. Also, what do the files inside these do. I only know of .bashrc file so far that can be used to customize how cygwin works but not the rest.
What resource can I use to find the details of this?
Cygwin uses the same folder structure of *nix systems:
bin (Binaries): Executable programs for all users.
cygdrive: Points to your local windows drives (e.g. /cygdrive/c points to C:\)
dev (Devices): The files in this folder are not content from the disk. They actually represent devices (disks, usb, audio,
cam, terminal output/input, etc). When you interact with these "files", you are interacting with devices.
etc (Editable Text Configuration): Machine-specific configuration files.
home: Home directories for system users specific configuration files, documents, personal stuff, etc.
lib (Libraries): Shared libraries (including libraries used by binaries from /bin and /sbin).
sbin (System Binaries): Binaries to configure and manipulate the operating system.
tmp (Temporary): Space reserved for short-lived files and folders.
usr (Unix System Resources): Shared and read-only resources and programs (not operating system level).
var: Variable data produced by the system that is not exclusive to a particular user. Most notably log files.
Cygwin will create a unix-like system inside your windows environment, as if it was in a box. So notice that the configuration files, logs, system binaries and others are related to this sandboxed unix-like environment, and not to your Windows Operating System.
Additional resources about the folders:
https://linux-training.be/funhtml/ch11.html
You may also google for things related to "linux directory structure" or "linux filesystem hierarchy"
Related
I'm developing a cross-platform desktop application for Mac, Linux and Windows. The application will create a plain-text log file to help with debugging, amongst other things. What are people's recommendations for a sensible place to store the log on each of the platforms?
Here is my guess so far, based on web searches:
Mac: ~/Library/Logs/MY-APP-NAME/system.log
Linux: ~/.MY-APP-NAME/logs/system.log
Windows: %APPDATA%\MY-APP-NAME\logs\system.log
For Linux, the XDG Base Directory Specification is followed by some applications. Log files are not specifically called out as such. You can put them either into a subdirectory of the data directory ($XDG_DATA_HOME or $HOME/.local/share), where they will not be deleted automatically, or you could use a subdirectory of the cache directory ($XDG_CACHE or $HOME/.cache). In the latter case, the files could be automatically expired after some time.
This is a more general and noob question. I am developing a small application in Linux (Ubuntu, to be more precise) and at this point I have an executable, a shared library (.so), a configuration file (.conf) with some settings to be read by the application at the beginning, a data folder with images and other resources to be used during the application life-time (resources that can be also modified, deleted) and of course, I would need some file for logs and messages (right now I am using syslog).
So, my question is, where should each one of these be stored when the application is installed on a client's computer? What is the standard way of organizing all the application's files in Linux? On Windows everything would be found usually in the C:\Program Files\(App Folder) but it looks like on Linux things are more (or less) organized. Can you give me some advices on this matter?
Program data were historically stored in dot-prefixed folders in user's home directory. Modern Linux distributions tends to use ~/.config/program_name folder.
For all files that will not be modified after distibution follow Linux standard:
Ex: project dir: ABC
sub directories:
logs - keep log files
conf - keep configuration files here
bin - executable binaries here
traps - any trap mesg
then depend on what application we develop
Along with you can set level for starting your application from boot level if required.
I'm Fairly new to Linux , And Software Development I was suggested that the shared library should be placed separately from the executable location in Linux , But in Windows I could see all the Files including the dll's and the exe are available in the same folder .What kind of problem's it might cause in linux if the exe and the shared library are in the same folder
When executable and library in same folder you can't say library is shared, right? And you'll probably have dozens of same libraries in system - what a waste of space. In Windows there's no organized way of storing libraries in system line /usr/bin or /lib/bin. It's not ok to put them in system32, and there's no other directories in PATH - no choice to make.
I have Qt application which should work on multiple platforms. One of those platforms is Linux. I am completely new in Linux world.
My application need to create and manage set of data files. After reading some links about linux directory structure I decided to store data files in /var/myapp directory and in its subdirectories.
Here is the problem: if my application runs without superuser privileges then it has no rights to create /var/myapp directory. Even if i will create directory manually (with sudo) my application will not have rights to write files there.
Is it possible to temporary elevate application's permissions from Qt code to create /var/myapp directory and write files there?
Or possibly there is another place in Linux directory structure which is by default available for storing application's data files?
Only root can create directories in /var. If your application needs a subdirectory under /var, you need to create it during installation (which typically runs with root permissions), and chmod it appropriately: either create a group for users that may run your application, put /var/myapp in that group, and chmod it to 770; or just chmod the directory to 777 to allow everyone to access it. If you want to prevent writing by regular users, use 755 or 750 instead. (For data files, don't set the execute bit though: the appropriate permissions here are 666/660/644/640). Instead of octal triplets, you may prefer the more elaborate mnemoic syntax to chmod, e.g. chmod ug+x filename adds (+) the execute bit (x) to filename for the owning user (u) and group (g).
However, /var is not necessarily the best choice: /var is typically used for volatile data (temporary files etc.), as well as things that are expected to change frequently (mail, log files, etc.). Other data should go into either:
/usr/share/{appname} for system-wide data files and resources
/etc/{appname} for system-wide configuration files
~/.{appname} (old convention) or ~/.config/{appname} for per-user configuration files
/var/tmp/{appname} for temporary files
Also, you want to make the /usr prefix configurable; most distributions reserve /usr for package-managed files, except /usr/local, which mirrors /usr for out-of-distro installs (so in that case, your system-wide resources go into /usr/local/share instead of /usr/share).
You could distribute it without installation scripts, but you'd have to tell them to run it once as root... or have the app run itself as root using gksudo/kdesudo if its system wide data files do not exist.
The custom though is to make a package (.deb, .rpm, or even a .tar.gz that the user will extract himself) including all necessary files.
But linux (and OS X for that matter) are multi user systems. Are you sure your files belong in /var or /usr? If they're created at runtime as you say, don't they depend on user input? In which case you need to put them in some directory inside the user's home directory (getenv("HOME")).
I have written an open source (GPL) application for Linux and OSX and now wish to distribute it. Is it normal to distribute the source code along with the binaries by default, or just provide a link to where it can be obtained?
If I include the source files, where is the normal location for writing them on the users system for Linux and OSX (I thought /usr/local/src but on my Ubuntu machine, supposedly chock-full of open source apps, this directory is empty).
It is usual to distribute the sources and binaries separately. Binaries would normally be distributed in distro-specific package formats whilst sources would be a simple .tar.gz containing a project folder. The user could unpack it to /usr/local/src if they wanted but it should build anywhere. It's not up to your program to drop its sources in any particular location.
I thought /usr/local/src but on my Ubuntu machine, supposedly chock-full of open source apps, this directory is empty
It will be empty if you are only using the Ubuntu repos. The OS is in charge of /usr and will drop any sources you install into /usr/src. But /usr/local is left for you to play with; that's where you install stuff that the distro doesn't provide.
About /usr/local/src
/usr/local and any subdirectories are always going to be empty on your machine unless YOU have specifically put something in there. It's a section of the filesystem that is reserved for user-installed software for that specific machine. Ubuntu (or any distribution) is not ever supposed to touch it.
Your distro will have separate places for its own source code, if any. Most Ubuntu installations won't need source code anyway (though you can download it if you want to), but if they do it'll go somewhere like /usr/src. But if you want to place your own source code somewhere and don't want your distro to mess with it, then just:
If it's just for developing/compiling in your own user account, you can just put it somewhere in your home directory.
If it's a piece of software you'll installing on the system, /usr/local/src is the suggested spot and your distro won't mess with it there.
FHS is the standard which says where in the filesystems things go, and includes distinctions such as the ones I've discussed above.
Your software should be able to be compiled no matter which directory it's in, because as you can see, it can depend.
It's worth looking at a few projects on Sourceforge (http://www.sf.net). As menioned by #bobince it's normal to distribute binaries and source separately. It's certainly kind to users not to require compilation so they can download and run.