I'm trying to check the version of Make via command prompt and when I run make --version, the command just returns
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
?±?e?I?t???[?\?t?g?E?F?A?A?・. ???p??‘o?E?A?￠?A?I?\?[?X?d
?2???-???3?￠.
???A?≪?a“A’e?I?U“I?O?I“K?‡?≪?I”#‰??E?O?i?c?，, ?3?U?O?A?・.
This program built for i386-pc-mingw32
make: write error
What could be causing this?
Related
Example
I have a gmake 4.0 from a MinGW installation, that shows no helping error messages.
For example I have this makefile:
# test.mk
all: somefile.c
Since I have no file named somefile.c present, it fails, but without any helpful message:
$ gmake -f test.mk
gmake: ***. Stop.
When I add the --debug flag I get some hints:
$ gmake -f test.mk --debug
GNU Make 4.0
Built for x86_64-w64-mingw32
Copyright (C) 1988-2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating goal targets....
File 'all' does not exist.
File 'somefile.c' does not exist.
Must remake target 'somefile.c'.
gmake: ***. Stop.
Expectation
For an older gmake 3.80 from another tool set, I get a helping message:
$ gmake-old -f test.mk
gmake-old: *** No rule to make target `somefile.c', needed by `all'. Stop.
Environment
I am running these command within a git-bash under Windows. I am getting a similar message, when calling gmake within windows cmd.
Question
Are there options for gmake or environment variables that I might set in order to get gmake 4.0 to provide helping messages like No rule to make target 'somefile.c', needed by 'all'?
I am running an .Rmd script in R 4.2.0.
This script executes several system() commands.
However, some of these commands return 127 in the console window in Rstudio 2022.02.3 Build 492 (I think that this output refers to the error 127), while other commands are simply not executed (mkdir or /din/mv for instance).
I am running R and Rstudio under Windows 10 Pro.
I read the suggestion that in Windows the system() command works better in this style for instance:
system("cmd.exe", input = "cd ..")
But also this simple command does not work. The output is like that:
(c) Microsoft Corporation. All rights reserved.
C:\User\me\Documents>cd ..
C:\User\me>[1] 0
However, if I type:
system("cmd.exe", input = "cd ..")
The directory is not changed:
(c) Microsoft Corporation. All rights reserved.
C:\User\me\Documents>pwd
C:/User/me/Documents
As a consequence the .Rmd script cannot create subdirectories and save new files generated from the data elaboration.
I hope someone can find the solution.
Thanks.
I found a difference of behaviour between GNU Make 4.1 and 3.81 and wonder whether my code is not POSIX compliant which 4 is enforcing more strictly, or whether something else is going on.
I distilled the failure case to this Makefile
.POSIX:
all: test-b
test-a:
cat a.txt b.txt c.txt >results.txt
test-b:
cat {a,b,c}.txt >results.txt
Assuming those files have been created with cat {a,b,c}.txt, target test-a always works, yet test-b works on Make 3.81 but fails on 4.1.
The output for 3.81:
$ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0
$ make
cat {a,b,c}.txt >results.txt
$ echo $?
0
The output for 4.1:
$ make --version
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ make
cat {a,b,c}.txt >results.txt
cat: {a,b,c}.txt: No such file or directory
Makefile:9: recipe for target 'test-b' failed
make: *** [test-b] Error 1
$ echo $?
2
It's possible the cat command is actually failing in 3.81 and it just isn't pointing it out, as later versions of GNU Make mention passing the -e flag to the shell when invoking target commands to make it more POSIX compliant, but I can't see how that command could be failing.
I assume the wildcards are handled solely by the shell, so I can't see how invoking the shell via a make target command should be any different.
Which is these behaviours are correct? If wildcards like that don't work in Makefiles, which other wildcards can I assume to work?
test-b still fails in 4.1 even if .POSIX: is removed from the file.
Recipes are sent to the shell. They are not interpreted by make. So your question is really, are curly-brace expansions supported by the shell?
That depends on which shell make uses. They are not supported by POSIX standard sh. They are supported by bash (and many other shells).
Make always invokes /bin/sh, regardless of what shell you personally use, unless you specifically set the make SHELL variable to something else. On some systems, /bin/sh is a symlink to /bin/bash so they are the same thing (bash runs in a "POSIX emulation" mode when invoked as /bin/sh but most bash features are still available). Other systems use different shells, such as dash, as /bin/sh which do not have extra bash features.
So, you can either (a) not have a portable makefile and assume /bin/sh is the same as /bin/bash, (b) set SHELL := /bin/bash in your makefile to force it to use bash always (but fail on systems that don't have bash installed), or (c) write your makefile recipes to use only POSIX sh features so it works regardless of which shell is used for /bin/sh.
I am pretty excited to have found Jeff and Dirk's application littler to run R functions from terminal. ¡kudos!
Since then, I have been able to pass my functions to my development team and have them running in other servers.
My question is about it's deployment. Before passing it to others, I try it out in my computer and prepare it with RStudio... (also kudos).
I was wondering if there's a command to run in the script on which I can tell if the function is run from the command or if it's been executed with R.
Thanks.
I don’t know whether there’s a littler specific answer. But in general it is impossible (or very hard) in R to determine how the code is run, which was one of the motivations for my work on modules.
The only thing R knows is whether the code is being run in an interactive shell (via interactive()).
With modules, you can test whether module_name() is set, analogous to Python’s __name__:
if (is.null(module_name()) && ! interactive()) {
# Stand-alone, execute main entry point
}
if (! is.null(module_name())) {
# Code is being loaded as a module.
}
I’ve written a small wrapper based on this which I’m using to write my command line applications. For instance, a very simple cat-like application would look as follows:
#!/usr/bin/env Rscript
sys = modules::import('sys')
sys$run({
if (length(sys$args) == 0) {
message('Usage: ', script_name(), ' filename')
sys$exit(1)
}
input = sys$args[1]
cat(readLines(input))
})
I am not sure I understand your question. Do you mean something like
edd#max:~$ which r
/usr/local/bin/r
edd#max:~$
You can compare the result of which against the empty string as nothing comes back when you ask for a non-existing program.
edd#max:~$ which s # we know we don't have this
edd#max:~$
You can then use the result of which r to check for, say, the version:
edd#max:~$ `which r` --version
r ('littler') version 0.2.2
git revision 8df31e5 as of Thu Jan 29 17:43:21 2015 -0800
built at 19:48:17 on Jan 29 2015
using GNU R Version 3.1.2 (2014-10-31)
Copyright (C) 2006 - 2014 Jeffrey Horner and Dirk Eddelbuettel
r is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under the terms of the
GNU General Public License. For more information about
these matters, see http://www.gnu.org/copyleft/gpl.html.
edd#max:~$
Edit: As you seem confused about interactive() true or false, consider r --help:
edd#max:~$ r --help
Usage: r [options] [-|file]
Launch GNU R to execute the R commands supplied in the specified file, or
from stdin if '-' is used. Suitable for so-called shebang '#!/'-line scripts.
Options:
-h, --help Give this help list
--usage Give a short usage message
-V, --version Show the version number
-v, --vanilla Pass the '--vanilla' option to R
-t, --rtemp Use per-session temporary directory as R does
-i, --interactive Let interactive() return 'true' rather than 'false'
-q, --quick Skip autoload / delayed assign of default libraries
-p, --verbose Print the value of expressions to the console
-l, --packages list Load the R packages from the comma-separated 'list'
-d, --datastdin Prepend command to load 'X' as csv from stdin
-e, --eval expr Let R evaluate 'expr'
edd#max:~$
and
edd#max:~$ r -e'print(interactive())'
[1] FALSE
edd#max:~$ r -i -e'print(interactive())'
[1] TRUE
edd#max:~$
but that is setting it as opposed to querying it.
I want to attach a process with ltrace command to trace one specific library calls. But when i used the below basic options, ltrace command throws error as below
bash-3.2$ **ltrace -l /path/libxml2.so.2.6.32 -p 26120**
failed to init breakpoints 26120
Cannot attach to pid 26120: Success
When I tried the same option with an executable ltrace is tracing the calls to that specific library (libxml2.so.2.6.32).
My server information:
2.6.18-348.6.1.el5 #1 SMP Fri Apr 26 09:21:26 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
ltrace vertion:
bash-3.2$ ltrace -V
ltrace version 0.5.
Copyright (C) 1997-2006 Juan Cespedes .
This is free software; see the GNU General Public Licence
version 2 or later for copying conditions. There is NO warranty.
I googled this error message but didn't get any useful information. From the error message I understood , the ltrace program is unable to set the breakpoint on libxml2 library. But I really don't understand why it is failing when ltrace is able to trace a sample program.
Has anyone faced this problem? Any help would be greatly appreciated.
Many Thanks,
Sakthivel
That's an ancient version of ltrace, with many known bugs. Please use latest version (0.7.3) from http://www.ltrace.org