When running a native compilation of gVim under Win7 I have the following in my vimrc:
if has ("win32")
let $TMP="C:/tmp"
setlocal equalprg=tidy\ --output-xhtml\ y\ -utf8\ --wrap-attributes\ 1\ --vertical-space\ 1\ --indent\ auto\ --wrap\ 0\ --show-body-only\ auto\ --preserve-entities\ 1\ -q\ -f\ shellpipe=2>
endif
This should create a temp file. However, after running the command, I see:
shell returned 1
E485: Can't read file C:\tmp\VIoC935.tmp
The common recommendation for native windows E485 errors is to set the tmp variable, which I have, as you can see from my vimrc snippet. If I remove the let statement, I get a similar result:
shell returned 1
E485: Can't read file C:\Users\ksk\AppData\Local\Temp\VIfFA01.tmp
In both cases; both directories exist and gVim can write a file to those locations, i.e.,
:w C:\Users\ksk\AppData\Local\Temp\VIfFA01.tmp
in the current buffer will write this file without error.
Interestingly, while writing this, I found that if I create a new buffer, and delete the original buffer, the equalprg function runs without error (with and without the "let" statement in vimrc)
This doesn't apply to the original question, but I ran into the same symptoms because of the setting of my SHELL variable within gvim. I was launching gvim from a Cygwin window, and it picked up the SHELL setting from within cygwin: /bin/bash. I had to do a ":set SHELL=C:/cygwin/bin/bash" from within gvim, and then the temporary file problem went away. So check the setting of your SHELL variable within gVim (via ":set shell") when trying to troubleshoot this kind of problem.
Interestingly, while writing this, I found that if I create a new buffer, and delete the original buffer, the equalprg function runs without error (with and without the "let" statement in vimrc)
That's probably because you use setlocal in your vimrc
E485: Can't read file C:\tmp\VIoC935.tmp
I know the reason, but I don't know how to fix it without changing indentation options. The issue is caused by the '>' symbol of your indent command, it should work after removing the last part of it or even only the '>' symbol. It's so because '>' has a special meaning in shell commands. In *nix one can probably just escape it, but this doesn't work for me in Windows.
P.S. I know this is not a full answer, but maybe it will help you solve the issue.
Update. Small discussion in the comments discovered that the correct way of escaping is to enclose the last argument in double quotes (the variant 2) below). So the working command is:
setlocal equalprg=tidy\ --output-xhtml\ y\ -utf8\ --wrap-attributes\ 1\ --vertical-space\ 1\ --indent\ auto\ --wrap\ 0\ --show-body-only\ auto\ --preserve-entities\ 1\ -q\ -f\ "shellpipe=2>"
Related
I'm trying to get this program to start but I keep getting an error.
I've already tried to make the blockquotes [==[]==] around the string and "" around the program path but it still doesn't work.
local test = string.format([==["C:\Program Files (x86)\Audacity\audacity.exe" "F:\Aufnahme %s.%s.%s\ZOOM0001.WAV"]==], tag, monat, jahr)
print(test)
io.popen(test)
error when running the lua file
If I copy the command from the print(test) and use that in cmd.exe it works.
Thanks for the help :)
On Windows, you must enclose your command line (program + arguments) in additional outer-level quotes.
local test = string.format([==["C:\Program Files (x86)\Audacity\audacity.exe" "F:\Aufnahme %s.%s.%s\ZOOM0001.WAV"]==], tag, monat, jahr)
test = '"'..test..'"'
print(test)
io.popen(test)
When you are typing the command from keyboard in CMD.EXE window, then these additional quotes are added automatically by the code that is processing your keyboard input.
When you're using C function system or Lua functions os.execute, io.popen then you must add additional quotes manually.
This is how CMD.EXE works (and its design is full of not-very-logical decisions).
I would like to run a Bash shell script (.sh) using the Windows Subsystem for Linux as part of a Build Event in Visual Studio, in a C++ project.
But there are lots of errors when I do this, and I can't seem to find the right combination of quotation marks and apostrophes and backslashes to either make Bash run in the first place, or to properly pass the path to the script.
How do I make Visual Studio run my Bash shell script as a build event?
(Feel free to skip to the bottom of this answer if you don't care about how to solve the problem and just want a command you can copy and paste!)
Overview
I run a number of Bash shell scripts as part of Build events in Visual Studio, and I used to use Cygwin to run them. Now that the Windows Subsystem for Linux is available, I spent some time switching my builds over to use WSL, and it wasn't as easy as I'd hoped, but it can work, with a little time and energy.
There are several issues you'll run into if you're going to do this:
The path to bash.exe may not be what you think it is, because under the hood, Visual Studio uses a 32-bit build process, so if you're on a 64-bit machine, you can't simply run the 64-bit bash.exe without getting the dreaded 'C:\Windows\System32\bash.exe' is not recognized error.
The path to your solution or project is a Windows path that uses backslashes (\), and those don't play nice in Unix, which prefers forward slashes (/) as a path delimiter.
The root drive of the solution, typically something like C:\, is meaningless gibberish in Unix; to reach the root drive in WSL, you'll need to use a mounted drive under /mnt.
The casing of the drive letter is different between Windows and WSL: In Windows, it's uppercase C:\, and in WSL, it's lowercase /mnt/c.
And to make it a little harder, we don't want to hard-code any of the paths: It should all Just Work, no matter where the solution is found.
The good news is that they're all solvable issues! Let's tackle them one at a time.
Fixing the Issues
1. The proper path to Bash
Per the answer given here, you'll need to use a magic path to reach Bash when running it from a Visual Studio build. The correct path is not C:\Windows\System32\bash.exe, but is actually
%windir%\sysnative\bash.exe
The magic sysnative folder avoids the invisible filesystem redirection performed by the WOW64 layer, and points to the native bash.exe file.
2. Fixing the backslashes
The next problem you're likely to run into is the backslashes. Ideally, you'd like to run a project script like $(ProjectDir)myscript.sh, but that expands to something like C:\Code\MySolution\MyProject\myscript.sh. At a minimum, you'd like that to be at least C:/Code/MySolution/MyProject/myscript.sh, which isn't exactly right, but which is a lot closer to correct.
So sed to the rescue! sed is a Unix tool that mutates text in files: It searches for text using regular expressions, and, among other things, can replace that text with a modified version. Here, we're going to pipe the path we have into sed, and then use some regex magic to swap the path separators, like this (with lines wrapped here for readability):
%windir%\sysnative\bash.exe -c "echo '$(ProjectDir)myscript.sh'
| sed -e 's/\\\\/\//g;'"
If you include this as your build event, you'll see that it now doesn't run the script, but it at least prints something like C:/Code/MySolution/MyProject/myscript.sh to the output console, which is a step in the right direction.
And yes, that's a lot of backslashes and quotes and apostrophes to get the escaping right, because Nmake.exe and bash and sed are all going to consume some of those special symbols while processing their respective command-lines.
3. Fixing the C:\ root path
We want to mutate the sed script so that it turns the C:\ into /mnt/C. A little more regex substitution magic can do that. (And we have to turn on the -r flag in sed so that we can easily use capture groups.)
%windir%\sysnative\bash.exe -c "echo '$(ProjectDir)myscript.sh'
| sed -re 's/\\\\/\//g; s/([A-Z]):/\/mnt\/\1/i;'"
If you run this, you'll now see the output path as something like /mnt/C/Code/MySolution/MyProject/myscript.sh, which is almost but not quite correct.
4. Fixing the case-change in the root path
WSL mounts your disks in lowercase, and Windows mounts them in uppercase. Consistency! How do we fix this? Yet more sed magic!
The \L command can be used to tell sed to transform succeeding characters to lowercase (and there's an equivalent \U for uppercase). The \E command will switch output back to "normal" mode, where characters are left untouched.
Adding these in finally results in the correct path being output:
%windir%\sysnative\bash.exe -c "echo '$(ProjectDir)myscript.sh'
| sed -re 's/\\\\/\//g; s/([A-Z]):/\/mnt\/\L\1\E/i;'"
5. Running it
This whole time, Bash has just been printing out the path to the script. How do we run it instead, now that it's the correct path?
The answer is to add `backticks`! Backticks cause Bash to execute the command contained within them, and to then use that command's output as the arguments to the next command. In this case, we're not going to output anything: We just want to run the output of sed as a command.
So including the backticks, here's the result:
%windir%\sysnative\bash.exe -c "`echo '$(ProjectDir)myscript.sh'
| sed -re 's/\\\\/\//g; s/([A-Z]):/\/mnt\/\L\1\E/i;'`"
The Complete Solution
Here's what the whole solution looks like, for running a script named myscript.sh as a Build Event, in the current Project directory of the current Solution:
%windir%\sysnative\bash.exe -c "`echo '$(ProjectDir)myscript.sh' | sed -re 's/\\\\/\//g; s/([A-Z]):/\/mnt\/\L\1\E/i;'`"
Here's a screen-shot showing the same thing in Visual Studio 2017, for a real C++ project:
It's not easy, but it's not impossible.
If you have Git for Windows installed, try this. I found it simpler than installing WSL. The basic idea is to create an intermediate batch script to call your bash script, using Git bash's in-built bash or sh command from the batch script.
With Git for Windows, you'll have a Git\bin folder e.g. at:
C:\Program Files\Git\bin
Inside that directory you should see the bash.exe and sh.exe programs. So if you add that directory to your Windows Path environment variable then you'll be able to use sh and bash from the Windows command line. These commands will allow you to run your bash scripts "inline" within a CMD console window. That is, they won't spawn a new bash window; meaning the console output will be visible in your VS build.
From there, just create a .bat file which calls your .sh file using either the sh command or the bash command. Not sure the difference; we just use the sh command. So if your bash script is pre.sh, then your batch file would be just a single line calling the bash script:
sh %~dp0\pre.sh
if errorlevel 1 (
exit /b %errorlevel%
)
The %~dp0 assumes the batch and bash scripts are in the same directory. You then point your VS build event to the .bat file. The check for error level is necessary so that any failures from the bash script are forwarded up to the batch script. See: How do I get the application exit code from a Windows command line?.
To hook this in as a build event in VS2019 then, just follow the standard instructions for hooking in a .bat file: https://learn.microsoft.com/en-us/visualstudio/ide/specifying-custom-build-events-in-visual-studio?view=vs-2019.
Update: Beware Visual Studio's (VS's) Path Variable Behaviour
One thing we found quite frustrating with this solution was the tendency of VS to not load in the path variable correctly. It seems to prefer the user variable over the system variable. But even after we deleted the user variable, sometimes the path didn't seem to be getting picked up by VS, and we kept getting "sh is not recognised..." messages on our build console. Whenever that happened, restarting VS seemed to do the trick. Not very satisfying, but it gets us by.
Update: This is not a Full Unix Solution
Git for Windows does have a lot of Unix commands available, but not all of them. So in general, this won't work. For the general case, WSL is more robust. However, if it's just pretty lightweight Unix you need, this will suffice, and will likely be an easier approach for Windows users who would rather avoid the steeper setup cost of installing the full WSL.
Original idea to use Git bash came from here: https://superuser.com/questions/1218943/windows-command-prompt-capture-output-of-bash-script-in-one-step
Instead of backticks, you can wrap command with $( and )
I have created a Windows 7 shortcut in an attempt to give someone who is not comfortable with R the ability to run a simple program. I have tried to follow the advice of other postings, but must be missing something. This is what I have in my shortcut right now.
Target: "C:\Program Files\R\R-3.0.2\bin\x64\Rscript.exe" --vanilla -e "C:\Users\Moo\Desktop\CharCalendar.r"
Start in: "C:\Program Files\R\R-3.0.2\bin\x64"
I get error messages (that flash up very briefly on a black DOS window) that say things like Error unexpected input in "C:\"
I have tried with and without quotes in the target, I have tried using source() in the target (also with and without quotes).
The script runs without error when I submit it in the R console.
You probably want
"C:\Program Files\R\R-3.0.2\bin\x64\Rscript.exe" --vanilla C:\Users\Moo\Desktop\CharCalendar.r
as your target. No -e; that specifies an expression to run, not a script file.
I must admit, I hardly ever made my own shortcut in Windows. However, you coul seemly write a bat-file which runs the R-script and PAUSES, so you can read the output:
#echo off
"C:\Program Files\R\R-3.0.2\bin\x64\Rscript.exe" "C:\Users\Moo\Desktop\CharCalendar.r"
PAUSE
You may also want to add additional options and arguments after Rscript.exe. If you want to pass it to Rgui.exe, it will be a trickier. Read the following stackoverflow-topic for hints:
Passing script as parameter to RGui
Replace Rscript.exe -e with Rterm.exe -f, which indicates that you are passing a file as argument, -e is for passing expressions e.g. Rscript.exe -e "a<-1:10; mean(a);" Rterm provides a few more options for control compared to Rscript, see Rterm.exe --help.
echo: write error: Bad file descriptor
Throughout my code (through several bash scripts) I encounter this error. It happens when I'm trying to write or append to a (one) file.
LOGRUN_SOM_MUT_ANA=/Volumes/.../logRUN_SOMATIC_MUT_ANA
I use the absolute path for this variable and I use the same file for each script that is called. The file has a bunch of lines just like this. I use the import '.' on each script to get it.
echo "debug level set for $DEBUG_LEVEL" >> ${LOGRUN_SOM_MUT_ANA}
Worth noting:
It typically happens AFTER the FIRST time I write to it.
I read about files 'closing' themselves and yielding this error
I am using the above line in one script, and then calling another script.
I'd be happy to clarify anything.
For others encountering the same stupid error under cygwin in a script that works under a real Linux: no idea why, but it can happen:
1) after a syntax error in the script
2) because cygwin bash wants you to replace ./myScript.sh with . ./myScript.sh (where dot is the bash-style include directive, aka source)
I figured it out, the thumb drive I'm using is encrypted. It outputs to /tmp/ so it's a permission thing. That's the problem!
I am trying to use doxygen to generate documentation for some matlab classes I have written. I am using the doxygen-matlab package, which includes a perl script to kludge matlab .m files into c++ style commented files, so that doxygen can read them.
In my doxyfile, I have set (according to the instructions)
FILTER_PATTERNS = *m=C:/doxygenMatlab/m2cpp.pl
However, when the code runs, rather than running the script on the input files, it appears to just open the script using whatever the default windows setting for .pl is.
IE, if I associate .pl with notepad, the script is opened by notepad once for each input file doxygen is trying to parse. If I associate .pl with perl.exe, the script runs and throws the no argument error
Argument must contain filename -1 at C:\doxygenMatlab\m2cpp.pl line 4.
The doxygen documentation says
Doxygen will invoke the filter program by executing (via popen()) the command <filter> <input-file>
So I am wondering if there is some problem with popen() and windows that I could fix.
Could you try the workarounds I posted on the Matlab File Exchange regarding the doxygen package ?
Set the following variables in the Doxyfile :
INPUT_FILTER=perl m2cpp.pl
FILE_PATTERNS=*.m
If it doesn't work you should try to install ActivePerl : with this version of perl, everything is working fine.
I tried to reproduce the error using the Windows command prompt ("cmd") and noticed the following:
If you call "perl m2cpp.pl" you get error -1 because you did not specify a m-file to be translated into a cpp-file.
If you call "perl m2cpp.pl mfile" and the path of mfile contains spaces, you get error 1.
After I moved the mfile into a location which does not contain spaces, I got the desired output.
Now back to Doxygen. I tried what you suggested, Fabrice, without any luck. I read the doxygen help and found out that the INPUT_FILTER variable is only read and used if FILTER_PATTERNS is empty.
Therefore, I now use INPUT_FILTER = "C:\Programme\MATLAB\R2009a\sys\perl\win32\bin\perl U:\doxygen_matlab\m2cpp.pl" and an empty FILTER_PATTERNS variable. With this configuration, you can even leave the PERL_PATH variable empty. Moreover, there seems to be no issues with file names that contain spaces.
Unfortunately, all files are parsed with the above configuration, not only m-files. However, setting FILTER_PATTERNS to something like *.m=C:\Programme\MATLAB\R2009a\sys\perl\win32\bin\perl U:\doxygen_matlab\m2cpp.pl does not work because doxygen automatically adds the name of the filtered mfile and interprets the command as perl "m2cpp.pl mfile". Of course, the file "m2cpp.pl mfile" does not exist, because these are two files.
Maybe you can find a solution to this problem. In the meantime, I suggest the workaround above and that you keep your C-files away from the folder that contains the m-files.
write a simple batch file, e.g. mfilter.bat, which takes one argument from command line:
C:\Programme\MATLAB\R2009a\sys\perl\win32\bin\perl U:\doxygen_matlab\m2cpp.pl %1
Change setting in Doxyfile:
FILTER_PATTERNS = *.m=mfile.bat
This did it for me (on a Windows platform)
I think I solved this problem : it came from a bad association between .pl and the program to execute (maybe due to a bad installation of the perl shipped whith Matlab ?).
To correct this, you should change the association for the .pl files : in a Windows command prompt ("cmd"), just type de 2 following lines :
assoc .pl=PerlScript
ftype PerlScript=C:\Program Files\MATLAB\R20xx\sys\perl\win32\bin\perl.exe %1 %*
(the old installation forgot the %* at the end, the arguments were not passed to the m2cpp.pl script).
And then everything should be fine with the FILTER_PATTERNS set the usual way, for example FILTER_PATTERN=*m=C:\DoxygenMatlbab\m2cpp.pl
Could you tell me if this fixed your problem ?
According to the Doxygen forums, there is a difference in behavior between using INPUT_FILTER and FILTER_PATTERNS.
I found that if I do some extra (escaped) quoting, I can get FILTER_PATTERNS to work. For example, instead of:
FILTER_PATTERNS = "*.m=sed -e 's|%%|//!|'"
Try:
FILTER_PATTERNS = "*.m=\"sed -e 's|%%|//!|'\""
(All of my experimentation was done with doxygen version 1.8.6)