I have written a series of functions to allow easier 'arg-parse'-type commandline argument parsing and check in R. I have run into the issue briefly mentioned here but still don't entirely understand whats going on. It seems that when trying to use "-g" as a flag,
$ Rscript test_args.R -g foo
where test_args.R is simply:
#minimal program for reproducing "-g" arg behaviour
args<-commandArgs(T)
print(args)
I get the error and output:
WARNING: unknown gui 'foo', using X11
[ 1 ] "-g" "foo"
it interprets that as something to change the GUI prior to actually running the script test_args.R (although the printed message shows that the "-g" does actually make it to the actual R program). This isn't mentioned in the Rscript man page, or anywhere else I can find.
Is there any way around this, and if not, is there a list of any other potential off-limits argument flags?
Thanks in advance!
EDIT:
based of of this post, I tried adding either the hash-bang #!/usr/bin/Rscript, but would ideally like to avoid users having to install littler to use the #!/usr/local/bin/r option if possible...
Related
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 have a program written in C that fails. When I run it in zsh, the program fails, but it's error output is not displayed in command line (note that the second ➜ was red, indicating a failed execution):
hpsc-hw2-USER on master
➜ ./sort -a 405500
hpsc-hw2-USER on master
➜
However, when I run it in bash, the error shows up:
[USER#COMPUTER hpsc-hw2-USER]$ ./sort -a 405500
Segmentation fault (core dumped)
Any idea why? I'm running oh-my-zsh with the spaceship theme if that helps.
but it's error output is not displayed in command line
That's not something that your program writes to the screen. It's the shell that's writing it. So the shell is not 'hiding' it.
I'm not using zsh myself, but since a red arrow indicates that the program was abnormally terminated, I guess you can look at the code for the red arrow and create a custom message. Here is a question about the error codes that might help you: What error code does a process that segfaults return?
I remember that I once made a custom bash prompt that showed the last exit code. Maybe I used this, but I'm not sure: Bash Prompt with Last Exit Code
Here is the documentation for how to customize the prompt for spaceship theme: https://denysdovhan.com/spaceship-prompt/docs/Options.html#exit-code-exit_code
I assume that you need to add exit_code to the SPACESHIP_PROMPT_ORDER section in your .zshrc file.
Any idea why?
You probably have to ask the developers. An equally valid question is: "Why does bash print 'segmentation fault'?" It's just a design choice. Bash does not print the memory address where the segfault occurred. Why is that?
Seems like the developers of oh-my-zsh thought it was enough with a red arrow.
Any ideas how to make zsh output the error message?
The result of the last command is stored in the shell variable ?, so you can print it with something like print $? or echo $?. Like most shells, zsh is incredibly configurable, so you can write a script that e.g. includes the result of the last command in your prompt. Here's a blog post in which the author configures zsh to display non-zero results in the right prompt: Show Exit Code of Last Command in Zsh.
Or why it doesn't do it to begin with?
Shell commands don't normally crash, and if they encounter errors they typically provide more useful output than just the return code on their own. The return code is most useful for scripts, so that you can write a script that handle error conditions.
I'm doing some bioinformatics analysis in Rstudio, but something strange happens when using system(). I'm also using Windows Subsystem for Linux, so I can run a UNIX executable in my Windows cmd like so:
bash -c "./parasail-master/build/parasail_aligner -a sw_trace_striped_sat -f SSWtemplate.fa -q SSWtest.fa -O EMBOSS -d >OUT.txt"
Don't worry about the specifics: what's important is that I use bash -c to indicate I want to use the UNIX bash, and I'm running the executable parasail_aligner. It all works out, and I get the nice output file "OUT.txt".
Now, since I'm doing my analysis in Rstudio, I want to execute this directly from an R script, like so:
system('bash -c "./parasail-master/build/parasail_aligner -a sw_trace_striped_sat -f SSWtemplate.fa -q SSWtest.fa -O EMBOSS -d >OUTER.txt"')
So: just give it as an argument to system()? But this gives the following error:
input file, query file, and stdin detected; max inputs is 2
This is obviously an error specifically generated by parasail_aligner. The funny thing is: I don't get this error at all from cmd directly, but I do get it when running the command in R using system(). Does anyone have any idea why something like this can happen at all? I would expect system() to just give its argument to cmd, but clearly it doesn't do this... Running the command in a command terminal opened in Rstudio also works fine, it is specifically system() that seems to mess up.
I'm terribly sorry if this question is vague, but I can't give you a simple example which you could use to replicate the error. I've been using system() for a while now and I've never had this kind of problem. I am on Windows and I've found some people online that say you should use shell() instead of system(), but doing so just gives me the same error.
Maybe it has something to do with this "stdin" thing the error mentions and how R/RStudio handles this, I don't know. But parasail seems to think I give it an extra input "stdin": it is true I give an Input File and a Query File (see error message), but I don't know what this "stdin" is.
If anyone has any ideas about what could be behind this strange behaviour of system(), I'm all ears. I understand that helping me is difficult since I can't give a simple example in which the problem occurs, but I hope someone might know what could be the problem anyway
UPDATE (answer?): so, I managed to resolve the issue, like so:
system('bash -c "./parasail-master/build/parasail_aligner -a sw_trace_striped_sat < SSWtemplate.fa -f SSWtest.fa -O EMBOSS -d >OUTER.txt"')
I did some searching about stdin, and (forgive me if what I say sounds amateur, I'm not really familiar with UNIX or command line) found out its "symbol" is <. So you can see in the code above, I changed the way I give in my inputs "SSWtemplate" and "SSWtest", giving one of them using "<", and this solves the problem.
I have no idea why this happens. Especially since it only happens when calling the command from inside RStudio, and not when doing so from cmd. If anyone can clarify this further (i.e. why and how functions like system() and shell() seem to mess with stdin), it would be a big help. Otherwise, I'll just answer this to my own question and leave it at that.
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 just started using Zsh lately for some of the integrated support in the shell prompt for my Git status etc.
When I type in:
ruby -v
to confirm the version of ruby I'm running, Zsh asks if I want to change the command to _ruby. Well after saying no at the prompt and the command completing as expected I continue to get the question at the prompt after confirming my command is correct.
I'm assuming there is a completion file or something of the sort.
Thanks
Update:
The shell is no longer trying to complete _ruby, it stopped responding after closing the shell a few times some how.
I tried to clean the file up several times but there is a "opts" variable that is 50 or more lines long and the lines are all ran together, some lines more than 150 characters. Maybe I could email an attachment to you if you still want to see it.
I sincerely apologize for the messy post.
This is command autocorrection, activated by the correct option. It has nothing to do with completion. You're seeing _ruby because zsh thinks there is no ruby command and it offers _ruby as the nearest existing match.
If you've just installed ruby, it's possible that zsh has memorized the list of available command earlier, and it won't always try to see if the command has appeared in between. In that case, run hash -rf. Future zsh sessions won't have this problem since the ruby command already existed when they started.
Sometimes, when you change your PATH, zsh forgets some hashed commands. The option hash_listall helps against this. As above, if you can force zsh to refresh its command cache with hash -rf.
You could make an alias:
alias ruby='nocorrect ruby'
It's what I did when zsh kept asking me if I meant .meteor when I typed meteor because auto-correct is still useful from time to time.
I find the autocorrect feature can get annoying at times. So I do in my ~/.zshrc,
DISABLE_CORRECTION="true"
I had the same problem even when the command is not installed.
I can solve it using the CORRECT_IGNORE variable in my .zshrc
# OPTs to enable
setopt HASH_LIST_ALL
setopt CORRECT
# Zsh variable to determine what to ignore,
# in this case everything starting with _ or .
CORRECT_IGNORE="[_|.]*"
I hope it helps to you or anyone with this issue
Sometime ago after an update, I got command auto-correction enabled which I don't want. If the same happened to you and you want to revert it, in the ~/.zshrc file you'll have make it:
# Uncomment the following line to enable command auto-correction.
ENABLE_CORRECTION="false"
or comment it as per bellow:
# Uncomment the following line to enable command auto-correction.
# ENABLE_CORRECTION="true"
Just a note, on my zsh (version 5.7.1 on macOS), the DISABLE_CORRECTION didn't work.
I saw in my .zshrc file the following two lines, which I then commented out
setopt CORRECT
setopt CORRECT_ALL
That did it for me.