I have not found it in:
~/.config/Trolltech
~/.qt
~/.config/Nokia
where I should search for it?
It will depend on your system where exactly to find it. You could try running locate qtrc. Note that the locations this is going to find aren't necessarily the ones where you should make changes -- on my system, I only have a system-wide qtrc in /etc. For local changes, you should add a new one in your home directory. Again the particular location within your home directory will depend on your installation (in particular whether you're using Qt3 or Qt4).
Related
Very new to Rust and am looking for clarification about rust file paths that are outside the project directory. I would expect reading a .txt file from say the desktop to look something roughly like this:
fs::read_to_string("./Desktop/test.txt");
However, this does not seem to work. Is this an issue with the file path listed or does Rust only allow access to files in the project directory? If this is the default case how does one allow access to files elsewhere in the system outside the current working directory?
Say the project is in Documents and we want to access some text file on the Desktop.
Found the answer, seems the path that I am looking for is like this :
fs::read_to_string("/Desktop/test.txt");
Seems the "." was looking in the current directory.
When you open a path that starts with ./, it is relative to the current working directory.
Assuming that the program does not change the working directory itself, that would be whatever directory the user was in when they started the executable.
Note that it is not necessarily the project directory: when you are developing your program, you will probably run it via cargo run, but when it is ready you would most likely copy the target executable into a directory that is in the path. The working directory can be completely different to the directory in which the executable is placed.
Your program can find out the current working directory by calling std::env::current_dir
If you want a path that does not depend on the working directory, you can use an absolute path, ie. starting with /.
Rust is no different to any other programming language in this respect. In particular, files are not opened in respect to the project dir.
As specified, the path will be relative to the working directory of the process. If the working directory isn't your home directory, then you need to be more specific about where the file is.
Note that the working directory can change depending on how you run the program. The link above has more information on this topic.
You can obtain your user's desktop directory using desktop_dir from the dirs crate, which will make the working directory irrelevant in this particular case. It will also correctly determine the user's desktop directory on many different operating systems.
fs::read_to_string({
let mut path = dirs::desktop_dir().expect("no desktop directory");
path.push("test.txt");
path
})
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.
I made a program in QT c++ that creates some files and i want them to be saved in a specific directory, i created a directory and i moved all the program there so i can use that same directory to save them, but when i write the path to save the files i have to write:
/home/"the name of my computer"/my_program/file.txt
and i want to use this same program in different computers. I also tried just writing:
my_program/file.txt
but it doesn't work.
Your relative path approach was already good, but a relative path is treated as relative to the working directory of the process and that depends on how the program is started.
E.g. if you start it from a shell, then the shell's current working directory will be the program's, if you start it from a launcher menu, it is often the user's home directory, but could be the location of the binary, etc.
So it is better to create a path based on well known base paths. such as the user's home directory, see QDir::home() or the a common location depending on type of data, see QStandardPaths
Did you try home directory path with "~/", many applications save their settings in ~/.applicationName directory
Is there a standard way of determining file locations under Linux? Even better, are there any POSIX API's which allow the retrieval of standard file locations?
For example, how can I determine a user's home directory? Or, how can I determine the proper location for system configuration files?
I know that typically these locations would be "/home/username" or "/etc/". Should I just hardcode the paths as such?
The path to the current user's home directory is in the environment variable HOME. (I know systems where home dirs are spread over several partitions (say, /vol/vol[number]/[first letter]/[user name]) and not located in /home/.)
For other users, there's getpwent (and getpwent_r), which pull the home directory from the passwd entry.
For the other directories, there is the File System Hierarchy Standard, which most Linux distros adhere to and some other OSen as well.
I don't think there's an API for this. Thus, if a system does things differently, you're on your own -- good luck! ;-)
The current user's home directory can be found in the HOME environment variable. For other users, you can use the getpwnam or getpwuid functions (or the _r variants) to look up another specified user's home directory, among other things.
I know that you didn't ask this, however if you're looking to find the location of an executable, you can use which
I'm currently installing R software on a shared space across several servers. After installation I found that when I login on different servers, R is not guaranteed to run due to the missing of some library files on different machines.
Here is what I'm trying to do: since the installation of R is machine-dependent, I'd like to put all missing library files like libtermcap.so.2, libg2c.so.1, etc, to a single directory on the shared space, so that when I run ./configure, it will also search for this directory. Since this directory is shared, the installation could become machine-independent, so I won't need to add missing files on each server.
Is there an option to achieve this when I run ./configure? Thanks.
Assuming you have copied the library files to /shared/lib/ and the header files to /shared/include/, you can run
./configure LDFLAGS=-L/shared/lib CPPFLAGS=-I/shared/include ...other options...
Note, however, that you are bound to run into trouble at run time, when you have to convince your installation to use the shared libraries from the right directory, especially in case someone decides to upgrade the default version on the respective host. That whole business is platform and installation dependent. I think if your hosts are not at least mostly identical, you ought to install your software (R) locally in a way suitable to the respective system.
Peter's answer is correct (+1), and please take special note of his suggestion to install locally. Using the local package management system and auto updating on each box is (in the long run) a much easier solution than trying to get compatible binaries/libraries on a shared drive. To simplify using Peter's solution, note that you can place the appropriate arguments in /shared/share/config.site. For example:
$ cat > /shared/share/config.site << EOF
: ${LDFLAGS=-L/shared/lib}
: ${CPPFLAGS=-I/share/include}
EOF
Whenever you run configure with --prefix=/shared, the config.site file will be read and defaults will be set.