I've seen both mentioned in articles, blogs, and SO answers, but unclear which I should use in my projects?
The answer is in the help command
# jvm options and output control
JAVA_OPTS environment variable, if unset uses "$default_java_opts"
.jvmopts if this file exists in the current directory, its contents
are appended to JAVA_OPTS
SBT_OPTS environment variable, if unset uses "$default_sbt_opts"
.sbtopts if this file exists in the current directory, its contents
are prepended to the runner args
/etc/sbt/sbtopts if this file exists, it is prepended to the runner args
-Dkey=val pass -Dkey=val directly to the java runtime
-J-X pass option -X directly to the java runtime
(-J is stripped)
-S-X add -X to sbt's scalacOptions (-S is stripped)
In the case of duplicated or conflicting options, the order above
shows precedence: JAVA_OPTS lowest, command line options highest.
Since option lower on list have higher precedence we can assume that .sbtopts have precedence over SBT_OPTS. It make sense as you could set up SBT_OPTS in your .bashrc and there should be a way of automatically overriding it per project that .sbtopts provides.
Related
Instead of always giving the --indent n flag on the command line, I would like to specify this in a config file (or library or module file – I'm not sure what the correct terminology is).
I tried putting various things in ~/.jq, such as indent: 4 or --indent 4, but they always gave me a compile error when I invoked jq. I looked at the manual but couldn't see any information on how to do this, nor find anything in the issues on GitHub.
Is it possible?
The ~/.jq file contains jq code such as function definitions. It's not a config file in the classical sense.
Most shells support aliases and you could set one yourself, e.g. in ~/.profile or ~/.bashrc/~/.bash_aliases with:
alias jq='jq --indent 4'
When invoked in an interactive shell, the alias will be resolved to the command including the option. Note however that aliases are ignored in shell scripts (i.e. non-interactive mode) by default.
I want to run Zsh without loading any of my .zshrc, Oh-my-zsh, and so on, just like if I had a fresh install without anything customized. (Like emacs -q.)
Are there any flags for this? Otherwise, can I set up some kind of "profile" for it?
Quoting from zsh manpages:
Commands are first read from /etc/zshenv; this cannot be overridden. Subsequent behaviour is modified by the RCS and GLOBAL_RCS options; the former affects all startup files, while the second only affects global startup files (those shown here with an path starting with a /). If one of the options is unset at any point, any subsequent startup file(s) of the corresponding type will not be read. It is also possible for a file in $ZDOTDIR to re-enable GLOBAL_RCS. Both RCS and GLOBAL_RCS are set by default.
[1] http://zsh.sourceforge.net/Doc/Release/Files.html
I guess you just want to disable your config files, so you should unset RCS option. This can be done either by running zsh -o NO_RCS or zsh -f / zsh --no-rcs.
My zsh has some completion features I don't understand and can't find where to change. I have two issues where I suspect they have a similar "fix" for my problem. I initialize the zsh completion system with
autoload -Uz compinit
compinit
to get advanced completion features, but I also get the following problems that I don't have without compinit.
First: I happen to have a directory called mydir in my home directory and unfortunately, there is also a user called mydir. When I want to change into my directory and then use tab completion, i.e.
cd mydir/<TAB>
I get the content directories of ~myusername/mydir/ along with all directories available for ~mydir/. I already tried to put
zstyle ':completion:*' users myusername
in my .zlogin file, but it does only change the completion of the username itself and not subsequent directories. Is there some similar switch to turn off completion of other users' home directories? Alternatively, it would already be good if the current directory completion would appear first in the completion menu.
Second: I wrote a script called setup-file-with-a-long-name.sh that resides in my home directory. When I want to execute it via
source setup-file-with-a-long-name.sh
I start with the first few characters, I press <TAB> and I get a list of lots of executable files that are probably somewhere on my $PATH installed by the system, but I don't care about all those files, I just want my file (which is the only match in the current directory) to be displayed either first in the menu and accessible via <TAB> <TAB> or better yet, be accepted after the first <TAB>. (If I select any of them, they don't work anyway because source needs the absolute path, not the filename. Therefore this is a behavior I don't understand and can't see how this is useful as a default for anybody.)
Possible workarounds:
1. Write ~/ explicitly - this is what I want to avoid, because I have to ssh into a new shell pretty often and want to start navigating without thinking about whether I am in $HOME or not.
2. Don't use compinit - well, I like the context-aware completion in principle, I just want to adapt it to my needs.
The following works in bash,
man source -
source filename [arguments]
Read and execute commands from filename in the current shell environment and return the exit status of the last command executed from filename. If filename does not contain a slash, file
names in PATH are used to find the directory containing filename. The file searched for in PATH need not be executable. When bash is not in posix mode, the current directory is searched if
no file is found in PATH. If the sourcepath option to the shopt builtin command is turned off, the PATH is not searched.
to disable the flag instructions are a little above the description of sourcepath
shopt [-pqsu] [-o] [optname ...]
Toggle the values of variables controlling optional shell behavior. With no options, or with the -p option, a list of all settable options is displayed, with an indication of
whether or not each is set. The -p option causes output to be displayed in a form that may be reused as input. Other options have the following meanings:
-s Enable (set) each optname.
-u Disable (unset) each optname.
-q Suppresses normal output (quiet mode); the return status indicates whether the optname is set or unset. If multiple optname arguments are given with -q, the return
status is zero if all optnames are enabled; non-zero otherwise.
-o Restricts the values of optname to be those defined for the -o option to the set builtin.
...
sourcepath
If set, the source (.) builtin uses the value of PATH to find the directory containing the file supplied as an argument. This option is enabled by default.
so executing the following should remove path from your tab completion...
shopt -u sourcepath
I've tried to change global variable DSQUERY in Solaris with this command:
setenv DSQUERY "SYBSERVER"
but it wasn't persisted. When I entered again in the machine the value was set to the older one.
How can I persist this change?
You have to put this line in your profile file. This file is read when you start a shell, and allows you to set-up some specific settings.
The filename depends on the shell you use and how you connect (with a direct connexion or with a su for example).
It seems you use csh, so you will have to change $HOME/.cshrc and.or $HOME/.login files.
Add your SetEnv command to .cshrc and .login file will do the job.
You have to do it in the user profile files, depending on the shell being used (.login, .cshrc, .bashrc, etc) so that when you log in again, it's executed automatically. There are global versions of those files under /etc for some shells, in case you want that to be applied to all users.
Rgds,
Daniel
I want to write a unix/linux program, that will use a configuration file.
My problem is, where should I put the location of the file?
I could "hardcode" the location (like /etc) into the program itself.
However, I would like it, if the user without privileges could install it (through make) somewhere else, like ~.
Should the makefile edit the source code? Or is it usually done in a different way?
Create some defaults:
/etc/appname
~/.appname
Then if you want to allow these to be overridden have your application inspect an environment variable. e.g.
$app_userconfig
$app_config
Which would contain an override path/filename.
Lastly add a command line option that allows a config to be specified at runtime, e.g.
-c | --config {filename}
It is common to use a series of places to get the location:
Supplied by the user as a command line argument (i.e. ./program -C path/to/config/file.cfg).
From an environment variable (char *path_to_config = getenv("PROGRAMCONFIG");).
Possibly look for a user specific or local version (stat("./program.cfg") or build up a strig to specify either "$HOME/.program/config.cfg" or "$HOME/.program.cfg" and stat that).
Hardcoded as a backup (stat("/etc/program/config.cfg",...)).
keeping a global config file under /etc/prgname is a standard. Also allowing a .local config file for individual users that will override the global settings would allow each user to personalize the program to their preference.
As skaffman says, the canonical locations for things like config files are specified in FHS. There appears to be a convention that a program will read a config file from the directory from which it is run as an alternative to the one in the hard-coded location. You may wish to consider adding a command-line switch that allows a user to specify an alternative config file location, as well.
The makefile shouldn't modify the source directly, but it can pass a folder path/name to the compiler through the -D option. One way to handle it would be to #define something like DEFAULT_PATH to be the default installation path. If the user wants to define a path, the makefile would add -DUSER_PATH=whatever to the compiler options. You would write your code to use USER_PATH if it exists, and DEFAULT_PATH otherwise.