I use linux and filter doxygen output as follows:
doxygen 2> >(grep "Arguments.h") 1> /dev/null
which is just to concentrate on failures within Arguments.h.
Now i want to put all that in a minimal makefile for GNU Make 4.3
doc:
doxygen 2> >(grep "Arguments.h") 1> /dev/null
of course later to replace Arguments.h by some other file.
But this does not work: reply is
doxygen 2> >(grep "Arguments.h") 1> /dev/null
/bin/sh: -c: line 0: syntax error near unexpected token `>'
/bin/sh: -c: line 0: `doxygen 2> >(grep "Arguments.h") 1> /dev/null'
make: *** [makefile:2: doc] Error 1
as far as i know make... one has to escape sth, but no idea what...
Any specialists which can help?
This is not related to escaping etc. This is related to which shell is being used.
GNU make (as with all versions of make) always invokes /bin/sh to run recipes, and that is a POSIX standard shell (or some proximity to it). The command you're using is definitely not supported by the POSIX standard, it appears to be using many features available only as enhancements in the bash shell.
If you want to write your recipes using bash features you have to tell make that it should be using bash as the shell, not /bin/sh. You can add this to your makefile:
SHELL = /bin/bash
Related
In a makefile, how would I make sure that certain tools like gcov, lcov, g++ are available before executing any other targets?
I want to gracefully fail with
gcov/lcov/g++ not available
.
You could try something like:
TOOLS := gcov lcov g++
$(foreach TOOL,$(TOOLS),\
$(if $(shell command -v $(TOOL)),,\
$(error Cannot locate $(TOOL) on PATH)))
This assumes you're using a POSIX shell obviously.
I am trying to build FreeBSD from source to see how it works. I googled how to do it, and most of the websites explaining how to build the world tell me to run this command inside the directory of the source code:
sudo make -j1 buildworld KERNCONF=MODEDKERNEL -DNO_CLEAN
For some reason, I keep getting this error...
make: invalid option -- 'D'
make: invalid option -- 'N'
Anyone know how to fix this? The Makefile can be found here
We don't need to see the makefile, because this error is being printed by make due to an invalid command line argument which means it's never even opening the makefile before it fails.
The reason is that -D, etc. are not valid command line options to GNU make. If you run man make (or look online for the GNU make manual) you'll see that -D is not listed as a valid option.
My suspicion is that when the websites you are reading are suggesting that you run make, they mean you should run FreeBSD make, which does support a -D option: https://www.freebsd.org/cgi/man.cgi?make(1)
You are trying to run this using GNU make, which does not have that option.
I am a beginner at Lisp, having only used DrRacket for some dabbling in Racket/Scheme. I have had much trouble figuring out how to run a .lisp file with Clozure CL for Windows. I tried running a .lisp file in SBCL on Ubuntu (running on virtualbox) without success as well.
I should mention that I've looked into the related questions about running files but I wasn't able to see any direct solution. Some are using .bat files, some are "creating applications" with Clozure CL's image (or something along those lines).
For SBCL in Ubuntu, I've tried:
sbcl lisptest.lisp \ The python/forth way.
(load "lisptest.lisp")
(load lisptest.lisp)
(--load lisptest.lisp)
:cd C:\Temp
(:cd C:\Temp)
and more.
I also tried to run it from notepad++:
cmd /k C:\Temp\ccl-1.11-windows\ccl\wx86cl64.exe "$(FULL_CURRENT_PATH)"
which is how I usually execute python files, but this method hasn't been successful.
**I will definitely start learning to use Emacs and Slime (Emacs is the obvious choice for lisp). But for the sake of knowledge, I would appreciate some tips on the alternative, basic-text-editor way of getting something trivial like "hello world" to print without my typing it explicity into the REPL and instead interpreting (or compiling) a text file with the instruction.
Thanks for your help.
Typically programs have help - did you look at that?
SBCL, Ubuntu, from the shell:
A Common Lisp file:
$ cat test.lisp
(format t "Hello World~%~%")
SBCL shows help:
$ sbcl --help
Usage: sbcl [runtime-options] [toplevel-options] [user-options]
Common runtime options:
--help Print this message and exit.
--version Print version information and exit.
--core <filename> Use the specified core file instead of the default.
--dynamic-space-size <MiB> Size of reserved dynamic space in megabytes.
--control-stack-size <MiB> Size of reserved control stack in megabytes.
Common toplevel options:
--sysinit <filename> System-wide init-file to use instead of default.
--userinit <filename> Per-user init-file to use instead of default.
--no-sysinit Inhibit processing of any system-wide init-file.
--no-userinit Inhibit processing of any per-user init-file.
--disable-debugger Invoke sb-ext:disable-debugger.
--noprint Run a Read-Eval Loop without printing results.
--script [<filename>] Skip #! line, disable debugger, avoid verbosity.
--quit Exit with code 0 after option processing.
--non-interactive Sets both --quit and --disable-debugger.
Common toplevel options that are processed in order:
--eval <form> Form to eval when processing this option.
--load <filename> File to load when processing this option.
User options are not processed by SBCL. All runtime options must
appear before toplevel options, and all toplevel options must
appear before user options.
For more information please refer to the SBCL User Manual, which
should be installed along with SBCL, and is also available from the
website <http://www.sbcl.org/>.
Using the script option from above:
$ sbcl --script test.lisp
Hello World
The same for Clozure CL
$ ccl --help
usage: ccl <options>
where <options> are one or more of:
-h, --help : this text
-V, --version : print (LISP-IMPLEMENTATION-VERSION) and exit
-K, --terminal-encoding : specify character encoding to use for *TERMINAL-IO*
-n, --no-init : suppress loading of init file
-e, --eval : evaluate <form> (may need to quote <form> in shell)
-l, --load : load <file>
-T, --set-lisp-heap-gc-threshold : set lisp-heap-gc-threshold to <n>
-Q, --quiet : if --batch, also suppress printing of heralds, prompts
-R, --heap-reserve <n>: reserve <n> (default: 1610612736)
bytes for heap expansion
-S, --stack-size <n>: set size of initial thread's control stack to <n>
-Z, --thread-stack-size <n>: set default size of first (listener) thread's stacks based on <n>
-b, --batch: exit when EOF on *STANDARD-INPUT*
--no-sigtrap : obscure option for running under GDB
--debug : try to ensure that kernel debugger uses a TTY for I/O
-I, --image-name <image-name>
and <image-name> defaults to ccl.image
Any arguments following the pseudoargument "--" are
not processed and are available to the application as
the value of CCL:*UNPROCESSED-COMMAND-LINE-ARGUMENTS* .
Using the load option from above
$ ccl --load test.lisp --eval '(quit)'
Hello World
 
Try
C:/path/to/ccl -l lisptest.lisp
This should work the same as
(load "lisptest.lisp")
If you can let us know specifically how that fails, we can be of more help.
I'm using the docopt implementation for R. My script has a command line option where the short form is -g. When I run my script, it seems this argument is first interpreted by R and then by my script. Therefore I get a wrist slap about not specifying a value for the GUI. Can I prevent R from trying to work with these command line args?
Example of a script:
#!/usr/bin/Rscript
suppressPackageStartupMessages(library(docopt))
"docopt practice script
Usage: foo.R [-g <goodies>]
Options:
-g <goodies>, --goodies=<goodies> Goodies
" -> doc
opts <- docopt(doc)
cat(sprintf("goodies = %s\n", opts$goodies))
Here's what happens when I run it:
Jennifers-MacBook-Pro-3:scripts jenny$ ./foo.R -g donuts
WARNING: --gui or -g without value ignored
goodies = donuts
If you change the short form of the option from -g to -j, the WARNING goes away … but I have a good reason for using the letter g!
As pointed out by #krlmlr, this issue has to do with Rscript (in your hash bang). One workaround would be to use the functionality provided by the excellent littler in place of Rscript. For example, using #!/usr/bin/Rscript in foo.R, I get the issue:
[nathan#nrussell R]$ ./foo.R -g donuts
WARNING: unknown gui 'donuts', using X11
goodies = donuts
Replacing this with #!/usr/local/bin/r in a new script foo2.R, I get a clean output:
[nathan#nrussell R]$ ./foo2.R -g donuts
goodies = donuts
It looks like you're on an OS X machine, so if you do choose to install littler, just be sure to note the authors' warning:
On OS X, you may want to build it via configure --program-prefix="l"
to renamed it to lr as that particular OS thinks R and r are the same
The R and Rscript commands know --args. Compare the output of the following:
R -e "TRUE" --args --silent
R -e "TRUE" --silent
This works due to an early exit if --args is detected. However, the --gui warning is triggered in a separate loop before this.
This means that
Rscript -e "commandArgs()" --args --gui
will work but give the spurious warning, and
Rscript -e "commandArgs()" --gui
gives an error right away. It looks like only --gui and -g are affected.
As a quick-and-dirty hack, one could insert something like
if(!strcmp(*avv, "--args")) {
break;
}
at the beginning of the GUI-check loop. Until this is changed in R, I suspect there's no choice but to avoid the -g switch or live with the (otherwise harmless) warning.
I want to call ShellCheck, a Haskell program for linting shell scripts, from a Makefile.
When I install ShellCheck via cabal install, it is installed as ~/.cabal/bin/shellcheck. So, I have configured Bash accordingly:
$ cat ~/.bashrc
export PATH="$PATH:~/.cabal/bin"
$ source ~/.bashrc
$ shellcheck -V
ShellCheck - shell script analysis tool
version: 0.3.4
license: GNU Affero General Public License, version 3
website: http://www.shellcheck.net
This enables me to run shellcheck from any directory in Bash. However, when I try to call it from a Makefile, make cannot find shellcheck.
$ cat Makefile
shlint:
-shlint lib/
shellcheck:
-shellcheck lib/**
lint: shlint shellcheck
$ make shellcheck
shellcheck lib/**
/bin/sh: 1: shellcheck: not found
make: [shellcheck] Error 127 (ignored)
I think that make is not receiving the same PATH as my normal Bash shell. How can I fix this?
Try using $HOME, not ~:
export PATH="$PATH:$HOME/.cabal/bin"
The ~-means-home-directory feature is not supported in pathnames everywhere in all shells. When make runs a recipe it doesn't use the user's shell (that would be a disaster!) it uses /bin/sh always.
On some systems (particularly Debian/Ubuntu-based GNU/Linux distributions) the default /bin/sh is not bash, but rather dash. Dash doesn't support ~ being expanded in the PATH variable.
In general, you should reserve ~ for use on the command line as a shorthand. But in scripting, etc. you should always prefer to write out $HOME.
ETA:
Also, the double-star syntax lib/** is a non-standard feature of shells like bash and zsh and will not do anything special in make recipes. It is identical to writing lib/*.
You can force make to use a different shell than /bin/sh by adding:
SHELL := /bin/bash
to your makefile, for example, but this makes it less portable (if that's an issue).