what does "+" mean in makefile ?
i found "+$(call if_changed,link-vmlinux)" in kernel makefile.
it means invoke make call function. But what's the "+" usage.
The + symbol means to execute the command under make -n
See the wiki
a plus sign (+), the command is executed even if Make is invoked in a
"do not execute" mode
Related
I am writing a bash completion program in Golang. In fact, the program is its own completion program as it looks for the COMP_LINE environment variable and if it is present, it outputs the completion options, and if not, just proceeds to run the main program.
The completion is then installed with the following:
complete -C /path/to/my-program my-program
This works well. For most of my completions, I want a space to be added after the word has been completed, however for a few flags I do not want this to occur.
When completion is defined, you can set a -o nospace option to omit the trailing space when completing a word. However then all completions that need a space have to have one added explicitly to the completion word list.
Is there any way that my program can modify the complete opts dynamically based on what completion it is returning? Is this exposed as an environment variable that a completion command could set?
I would like to avoid having to append a space to all other completions just to avoid one in the edge case for the one flag I don't want that to happen on.
My Perl framework (Perinci::CmdLine) also does the same: the scripts are their own completion, activated using complete -C SCRIPTNAME SCRIPTNAME (when the script is in PATH). Completing using an external command has its pro's and con's compared to using shell function. To solve the problem you encountered, I output a dummy answer with an extra space. Since there are more than one answer, bash no longer automatically adds a space. So instead of just returning (in JSON notation):
["-o"]
you return:
["-o","-o "]
I also use this trick when doing path completion. To allow user completing a path by "drilling down", when there is a single directory match I output:
["dirname/","dirname/ "]
so the user can Tab again to drill down inside path instead of getting a space after "dirname/ " and having to backspace and Tab again.
I've built a little command interpreter (in C++) which can be invoked either directly, or in a script via shebang (#!). It can take arguments on the command line (which appear as argc/argv in my code).
Trouble is, when invoked via shebang, the script itself gets passed to my program as argument 1. That's problematic; I don't want my command interpreter trying to process the script that it was invoked from. But I can't see any easy way to tell when this is the case.
EDIT: As an example, if I have a script called "test" which starts with #!/usr/local/bin/miniscript, and then invoke it as ./test --help -c -foo, I get 5 arguments in my C code: /usr/local/bin/miniscript, ./test, --help, -c, and -foo. If I invoke it directly, then I get four arguments: /usr/local/bin/miniscript, --help, -c, and -foo
How can I tell when my program was invoked via a shebang, or otherwise know to skip the argument that represents the script it was invoked by?
My question was based on a wrong assumption. I believed that two things were happening when a program was invoked via shebang:
Path to that program was passed as the first argument.
Contents of that program were piped to stdin.
So I was essentially worried about processing the content twice. But only item 1 is true; item 2 does not happen (as pointed out by helpful commenters on my question). So if the C code accepts the name of a file to process as a first argument, and ignores any initial line starting with a shebang, then all is right with the world.
I'm having this issue when running a batch file with Tivoli Workload Scheduler.
There's a third party program, let's says its name is program.exe
The batch file contains the following command to invoke program.exe
program.exe param1 param2 param3
The problem is the batch file terminates when there are warning popups from program.exe; but we're totally ok with the warning popups. We want it to run regardless of how many warnings it encounters.
I've looked into this and found out that using 'start' could solve the problem.
'call' behaves the same way as direct invoking.
So when we directly invoke the program does it default to ?
call program.exe
or is there any significant difference between direct invoke and call ?
is there any significant difference between direct invoke and call ?
No difference: you would call to call another cmd batch script.
It also ensures you return to the current script once the call is done.
You can also use it to call an function within your current script.
For the program it's not a difference, but you got different results for the parameters, as the parameters will be evaluated two times by the parser.
program Program^&Documents "One caret ^ "
call program.exe Program^&Documents "One caret ^ "
The first line works as expected, but the second results into
program.exe Program
&Documents "One caret ^^ "
And it fails completly because the & can't be avaluated in a CALL.
And carets are doubled by a call.
Why does the first excerpt succeed and the second fail?
system 'emacs', '--batch', '--quick', '--eval="(require \'package)"'
system 'emacs --batch --quick --eval="(require \'package)"'
(If it matters, I'm executing the code on Mac OS X Mountain Lion with Ruby version 1.8.7 and Emacs version 22.1.1.)
First of all, those two system calls are different in ways that you may not expect. A quick example will probably explain the difference better than a bunch of words and hand waving. Start with a simple shell script:
#!/bin/sh
echo $1
I'll call that pancakes.sh because I like pancakes more than foo. Then we can step into irb and see what's going on:
>> system('./pancakes.sh --where-is="house?"')
--where-is=house?
>> system('./pancakes.sh', '--where-is="house?"')
--where-is="house?"
Do you see the significant difference? The single argument form of system hands the whole string to /bin/sh for processing and /bin/sh will deal with the double quotes in its own way so the program being called will never see them. The multi-argument form of system doesn't invoke /bin/sh to process the command line so the arguments are passed as-is with double quotes intact.
Back to your system calls. The first one will send this exact argument to emacs (note that Ruby will take care of converting \' to just '):
--eval="(require 'package)"
and emacs will try to evaluate "(require 'package)"; that looks more like a string than an elisp snippet to me and evaluating a string literal doesn't do much of anything. Your second will send this to emacs:
--eval=(require 'package)
and emacs will complain that it
Cannot open load file: package
Note that my elisp knowledge is buried under about 20 years of rust and forgetfulness so some of the emacs details may be a bit off.
Is there a way to have make echo commands that are manually suppressed with # in the makefile? I can't find this in the help or man page, it just says "--quiet" to do the opposite.
The most obvious idea is to change the shell that runs the commands, e.g. modify your makefile and add to the top SHELL = sh -xv.
Another solution is to change how you call make to make SHELL='sh -xv'
Lastly if your Makefile is generated by cmake then call make with make VERBOSE=1
I run into this question from time to time using cmake because it hides the command. You can use "make VERBOSE=true" to get them to print out.