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.
Related
my scenario is: I'm using vim to open some .cpp files, for example
vim 1.cpp src/2.cpp root/src/3.cpp
Sometimes, I wish to rebuild 3.cpp so I have to use another window to
"rm root/src/3.o"
and inside vim, type
":make"
This works fine, NP. But I am looking for a .vimrc function/command that:
When I switch to buffer, e.g. "root/src/3.cpp" and press this command, vim will detect the directory of "root/src" and the file name without suffix "3", and automatically execute a command of "rm root/src/3.o".
In this case, I can casually switch to any buffer and re-trigger the build of this very file.
Note I don't wish to map gmake tool command like "make clean" because we use several different make utilities like scons, cmake, etc.
So how to write this function/command in .vimrc? Thanks.
:call system('rm '.expand('%:p:r')) as #Kent said, or even simply :!rm %:p:r.
But I'm quite surprised you need to do that. Tools in charge of compilation chains usually understand dependencies (which ever the tool is), and you shouldn't need to remove the object file that often to need a mapping to do it for you.
PS: it's perfectly possible (but I need to update the doc) to support CMake, or out-of-source compilation from vim. But indeed, with out-of-sources compilation, you wouldn't need to delete those files manually, a :make clean if :make already works.
you can get root/src/3 from root/src/3.cpp buffer by:
expand('%:p:r')
Then you are free to concatenate the .o to end, and build the command.
We work with Make files and want to create a precommit check in HG to check Makefile syntax. Originally, our check was just going to be
make -n FOO.mk
However, we realized that if a Makefile were syntactically correct but required some environment variable to be set, the test could fail.
Any ideas? Our default is to resort to writing our own python scripts to check for a limited subset of common Makefile mistakes.
We are using GNUmake.
$ make --dry-run > /dev/null
$ echo $?
0
The output is of no value to me so I always redirect to /dev/null (often stderr too) and rely on exit code. The man page https://linux.die.net/man/1/make explains:
-n, --just-print, --dry-run, --recon
Print the commands that would be executed, but do not execute them.
A syntax error would result in the sample output:
$ make --dry-run > /dev/null
Makefile:11: *** unterminated variable reference. Stop.
It is not a good idea to have makefiles depend on environment variables. Precisely because of the issue you mentioned.
Variables from the Environment:
... use of variables from the environment is not recommended. It is not wise for makefiles to depend for their functioning on environment variables set up outside their control, since this would cause different users to get different results from the same makefile. This is against the whole purpose of most makefiles.
References to an environment variable in the recipe need a $$ prefix so it is not that hard to find references to the pattern '[$][$][{] or the pattern [$][$][A-Z] which will find the direct references. A pretty simple perl filter (sed script) finds them all.
To find the indirect ones I would try the recipe with only PATH set and HOME set to /dev/null, and SHELL set to /bin/false. Make's macro SHELL is not the environment $SHELL, so you can get the recipes to run, you'll have to set SHELL=/bin/sh in the recipe file to run the command from the recipe. That should shake out enough data to help you find the depends.
What you do about the results is another issue.
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.
Whenever I start a shell in vim using :sh, it doesn't source my ~/.bashrc file. How can I get it to do this automatically?
See :help 'shell'. You can set this string to include -l or --login, which will source your .bashrc file. So, you might have a line like this in your .vimrc:
set shell=bash\ --login
Note that this will alter everything that invokes the shell, including :!. This shouldn't be much of a problem, but you should be aware of it.
The value of this command can also be changed by setting the $SHELL environment variable.
If it doesn't source your .bashrc file, it may still source your .bash_profile file. I usually make one of them a symlink to the other. If your .bashrc performs some particularly odd one-time operations, you may have to edit it to only perform those operations with a login shell, but I've never had problems with it.
~/.vimrc
cmap sh<CR> !bash --login<CR>
If you quickly enter "sh<Enter>" in command-line, you can start bash with sourcing ~/.bashrc. So dirty.
At a unix command line, what's the difference between executing a program by simply typing it's name, vs. executing a program by typing a . (dot) followed by the program name? e.g.:
runme
vs.
. runme
. name sources the file called name into the current shell. So if a file contains this
A=hello
Then if you sources that, afterwards you can refer to a variable called A which will contain hello. But if you execute the file (given proper execution rights and #!/interpreterline), then such things won't work, since the variable and other things that script sets will only affects its subshell it is run in.
Sourcing a binary file will not make any sense: Shell wouldn't know how to interpret the binary stuff (remember it inserts the things appearing in that file into the current shell - much like the good old #include <file> mechanism in C). Example:
head -c 10 /dev/urandom > foo.sh; . foo.sh # don't do this at home!
bash: �ǻD$�/�: file or directory not found
Executing a binary file, however, does make a lot of sense, of course. So normally you want to just name the file you want to execute, and in special cases, like the A=hello case above, you want to source a file.
Using "source" or "." causes the commands to run in the current process. Running the script as an executable gives it its own process.
This matters most if you are trying to set environment variable in current shell (which you can't do in a separate process) or want to abort the script without aborting your shell (which you can only do in a separate process).
The first executes the command. The second is shorthand for including a shell script inside another.
This syntax is used to "load" and parse a script. It's most useful when you have a script that has common functionality to a bunch of other scripts, and you can just "dot include" it. See http://tldp.org/LDP/abs/html/internal.html for details (scroll down to the "dot" command).
Running "runme" will create a new process which will go on its merry little way and not affect your shell.
Running ". runme" will allow the script "runme" to change your environment variables, change directories, and all sorts of other things that you might want it to do for you. It can only do this because it's being interpreted by the shell process that's already running for you. As a consequence, if you're running bash as your login shell, you can only use the "." notation with a bash script, not (for example) a binary on C shell script.