I have the following code that should open the Recode.xlsx inside the subf folder but doesn't
write_xlsx(mtcars, "subf/Recode.xlsx")
shell("subf/Recode.xlsx", wait=FALSE)
The following code works, so if anyone has an idea on why it doesn't work it would help me
write_xlsx(mtcars, "Recode.xlsx")
shell("Recode.xlsx", wait=FALSE)
Here’s what the documentation of the shell function says (emphasis mine):
shell is a more user-friendly wrapper for system. To make use of Windows file associations, use shell.exec.
And here is another bit of relevant information from the shell.exec documentation:
To be interpreted as relative, the path also needs to use backslashes as separators (at least in Windows 10).
So the following is the correct usage:
shell.exec("subf\\Recode.xlsx")
Related
I am trying to set the dictionary option (to allow autocompletion of certain words of my choosing) using wildcards in a filename glob, as follows:
:set dict+=$VIM/dict/dict*.lst
The hope is that, with this line in the initially sourced .vimrc (or, in my case of Windows 10, _vimrc), I can add different dictionary files to my $VIM/dict directory later, and each new invocation of Vim will use those dictionary files, without me needing to modify my .vimrc settings.
However, an error message says that there is no such file. When I give a specific filename (as in :set dict+=$VIM/dict/dict01.lst ), then it works.
The thing is, I could swear that this used to work. I had this setting in my .vimrc files since I started using Vim 7.1, and I don't recall any such error message until recently. Now it shows up on my Linux laptop as well as my Windows 7 and Windows 10 laptops. I can't remember exactly when this started happening.
Yes, I tried using backslashes (as in :set dict+=$VIM\dict\dict*.lst ) in case it was a Windows compatibility issue, but that still doesn't work. (Also this is happening on my Linux laptop, too, and that doesn't use backslashes for filepaths.)
Am I going senile? Or is there some other mysterious force going on?
Assuming for now that it is a change in the latest version of Vim, is there some way to specify "use all the dictionary files that fit this glob"?
-- Edited 2021-02-14 06:17:07
I also checked to see if it was due to having more than one file that fits the wildcard glob. (I thought that if I had more than one file that fit the wildcard, the glob would turn into two filenames, equivalent to saying dict+=$VIM/dict/dict01.lst dict02.lst which would not be syntactically valid.) But it still did not working after removing extra files so that only one file fit my pathname of $VIM/dict/dict*.lst . (I had previously put another Addendum here happily explaining that this was how I solved my problem, but it turned out to be premature.)
You must expand wildcards before setting an option. Multiple file names must be separated by commas. For example,
let &dictionary = tr(expand("$VIM/dict/dict*.lst"), "\n", ",")
If adding a value to a non-empty option, don't forget to add comma too (let is more universal than set, so it's less forgiving):
let &dictionary .= "," . tr(expand(...)...)
Anyone got an idea why
system2("bash", "ls")
would result in (both in R-Gui and RStudio Console)
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
while other shells work w/o issues (see example below) and the "bash" in the RStudio Terminal also works w/o problems. AND if there is a remedy for that?
Working system2 example:
system2("powershell", "dir")
Running R-3.6.3 on Windows 10 here ... with "Git bash" executing as "bash".
PS: just in case someone wonders - I also tried the full path ie /usr/bin/ls -> same result
Ok - this does the trick
system2("bash", input = "ls")
so instead of args = ... as with the powershell command one needs (or more interestingly sometimes 'can') use the input = ... parameter with bash
OR as mentioned in the comments by #oguzismail this will also work
system2("bash", "-c ls")
as well as pointed out by #Christoph
system2("ls")
also works sometimes (ie in some RStudio[?] setups it will not return results in some it will).
But I have come to notice that different combinations of R-versions with different RStudio versions [or more probably Locales] will not always behave consistently of course also depending on the availability of bash commands like ls (more generally /usr/bin) being on the PATH or not.
So choose what suits u best!
I need to achieve the below using Robotframework script:
c:\>runbatch "C:\Program Files (x86)\tool\bin\test.exe" C:\tool\get.ini
where runbatch is a MS DOS Batch and "C:\Program Files (x86)\tool\bin\test.exe" and C:\tool\get.ini are parameters to the batch file. The first argument contains path of a tool that has "(" and ")" in its path.
So in my Robot script I have a variable like below:
${tool_path} "C:\\Program Files (x86)\\tool\\bin\\test.exe"
${tool_ini} "C:\tool"
And invoke like below:
${RC}= Run Process ${CURDIR}/../scripts/runbatch.bat ${tool_path} ${tool_ini}\\get.ini
The execution fails but note when I run it via the same param thru the command line as standalone batch it works fine.
In the batch I added comments to just log the arguments and I found that they are completely distorted, the tool_path value is completely distorted ("\"C:\Program) and second argument becomes (Files ) - how can I fix the issue in robot script such that when a path is passed having braces are not modified?
You need to also escape the backslashes in ${tool_ini} - make its value c:\\tool; that's not the culprit thought, just something else to change.
Remove the double quotes in the arguments' values - Run Process does not need them in the way you are calling it, with a keyword argument per script argument. E.g.:
${tool_path} C:\\Program Files (x86)\\tool\\bin\\test.exe
${tool_ini} C:\\tool
${RC}= Run Process ${CURDIR}/../scripts/runbatch.bat ${tool_path} ${tool_ini}\\get.ini
The way you've put them, they have become a part of the value itself.
Alternatively, keeping the double quotes there, you can call the script with all arguments in the call line:
${tool_path} "C:\\Program Files (x86)\\tool\\bin\\test.exe"
${tool_ini} C:\\tool
${RC}= Run Process ${CURDIR}/../scripts/runbatch.bat ${tool_path} "${tool_ini}\\get.ini"
(the second one doesn't really need quotes, but I've added them for consistency)
By the way, not really an issue, yet - the script path uses slashes (/), which is a bit unorthodox for Windows. Contrary to the popular believe, the OS does support this path delimiter pretty much the same way as it supports backslashes (\), it's just not widely used and looks a bit out of place.
If I do list.files('~') on Linux I get the contents of my home directory.
If I do list.files('%userprofiles%') from Windows, I get an empty character as the return.
How can I use the special directories in this manner on Windows?
This isn't the same as this question because using ~ in Windows gets me %userprofile%/documents which I don't want. As a plan B I can use that and use string manipulation to take out "/documents" but that seems pretty hacky.
I'm not sure if you would consider this "hacky", but you can try something like:
list.files(dirname(path.expand("~")))
From #nongkrong's comments...
Sys.getenv("USERPROFILE") will return the correct directory. Using Sys.getenv() will work for other special directories too. Fortunately it is possible to mix "\\", which Sys.getenv() returns, with "/" which are more convenient to use for full paths.
I'm running lessc as following:
lessc alice/public/local/less/intfarm.less > alice/public/local/css/local/compiled/intfarm.css --source-map=alice/public/local/less/intfarm.map --verbose
the source map is output but it doesn't work. I check the file and at the end I read:
...
,iBAAA;EACA,cAAA;;AA1EZ,IAAI,SA8EA;EACI,gBAAA","file":"../../../../undefined
do I need to set other flags as well?
(shoutout at LESS creators: why not enable this by default and save us hours of work and searching?)
You should not use the > between your source and destiny. In fact your send the output to stdout. The compiler don't know that you are writing the output to intfarm.css and so can not construct the source map link to that file.
Also see: https://github.com/less/less.js/pull/2389
another solution can be using --source-map-map-inline parameter instead of --source-map=... but I think the best solution is the one pointed by Bass Jobsen