I'm trying to convert a unix style MSYS path such as
/c/my/path/to/a/folder
to a Windows path, or something that CMake would understand,
e.g C:/my/path/to/a/folder.
I'd like it to work on a path that is already correct.
Is there any proper way to do it ?
Note : Please do not mention cygwin's cygpath.
Edit: file(TO_CMAKE_PATH mypath result) is not working
There's no built-in CMake functionality for this, but you can write a function/macro to do it:
macro(msys_to_cmake_path MsysPath ResultingPath)
string(REGEX REPLACE "^/([a-zA-Z])/" "\\1:/" ${ResultingPath} "${MsysPath}")
endmacro()
set(mypath "/c/my/path/to/a/folder")
msys_to_cmake_path(${mypath} result)
message("Converted \"${mypath}\" to \"${result}\".")
Having said that, I agree with Antonio's comment in that it seems unusual to need this in the first place.
As an alternative to the accepted answer, you may wish to consider that MSYS itself will perform the conversion at any boundary between MSYS parent and native child process; thus, in an MSYS shell console:
cmd //c echo /c/my/path/to/a/folder
would display the appropriately converted path c:/my/path/to/a/folder. Additionally, this technique offers the possible advantage that it will emit the fully converted native form of a path, such as:
cmd //c echo /home/my/path/to/a/folder
to yield its native equivalent C:/MinGW/msys/1.0/home/my/path/to/a/folder, (assuming your MSYS installation is in the recommended default location, at C:/MinGW/msys/1.0).
With the caveat that running MSYS shell without proper initialization, as performed by msys.bat, may not work, (especially when running on 64-bit Windows), you may be able to run an equivalent command from within a native process, (such as within CMake), as:
C:/MinGW/msys/1.0/bin/sh -c 'cmd //c echo /home/my/path/to/a/folder'
Note that, if you invoke this from a native process which is itself running within an MSYS console, the initialization will have been correctly performed for the console's own shell process, and should thus propagate through the native process; the issues are more likely to arise if you attempt to invoke MSYS processes directly from a cmd.exe process, in a native Windows console, (or other native container).
Also note that, if the path name in question contains spaces, (never a good idea), you may need to enclose it within double quotes:
cmd //c echo "/home/my/path with spaces"
In this case, some experimentation indicates that the double quotes remain within the cmd output. I'm not entirely certain if this is necessary; you should use your discretion in your own particular usage case.
Related
I've got a very simple rust program but its not doing quite what I'd expect. Running on Windows, using a powershell prompt, I can do the following to display the path:
echo "%PATH%"
and I have a simple Rust program with:
Command::new("echo")
.arg("%PATH%")
.spawn()
.expect("ls command failed to start");
The command will launch and run, but it outputs:
%PATH%
instead of the path contents, like I'd expect. Other commands which don't use special characters seem to work as expected, so I suspect its related to handling them but I don't see a way in Rust to make the command any more primitive than it already is.
I've tried various formatting but it either fails to run the command or does the same.
I also tried using $env:path, but this always fails to run from Rust with a cannot find the path specified error.
Are there any suggestions for handling this? I could write the contents to a file and run the file instead, but running these types of commands from other languages directly works fine so I think it should work from Rust as well.
Thanks!
Update:
Managed to get the expected results from by using:
let out = Command::new("cmd")
.arg("/C")
.arg("echo %PATH%")
.spawn()
.expect("ls command failed to start");
}
I think the question got interpreted a bit differently, as getting the path was just an example of a larger issue I was seeing. Updating with the above solved my larger issue as well.
As the comment by French says: Spawning the process does not include the Powershell-environment, which would expand %PATH% to it's actual content before launching the process.
You need to get the content of PATH via std::env yourself or lookup the Powershell documentation on how to launch a subprocess inside a powershell-session.
As others have mentioned, it's not the special characters, it's the fact that those special characters are interpreted by powershell before the "echo" program runs at all.
Using https://doc.rust-lang.org/cargo/reference/environment-variables.html as a reference for how to look up environment variables, try something like this:
use std::env;
fn main() {
let cur_path = env::var("PATH").unwrap();
println!("Environment is: {}", cur_path);
}
You can try this here: https://play.rust-lang.org/
You can then feed cur_path into your "Command::new" if you wish. The trick is that powershell substitutes that argument BEFORE launching echo, which you may not have known, whereas when you execute the echo program directly, you have to do that substitution yourself.
If you are in a Cygwin or MinGW bash shell, environment variables like $PATH are in "UNIX" format - using forward slashes as dir separators and using the colon to separate multiple paths. But if, inside this shell, you run something like cmd.exe /c 'echo %PATH%' the resulting output is in "Windows" format, using backslashes and semicolons respectively.
Is this magical conversion documented somewhere? Or better yet, can somebody point to the code that makes this happen?
(The reason I ask is because it seems the conversion doesn't always happen and I'm trying to understand the exact conditions needed for it to occur.)
The internal conversions between Unix and Windows path format are
performed by the funtions in path.cc
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/path.cc;h=3cb46c9c812e17460d56def2f915b21c7227f3bf;hb=HEAD
When a Cygwin program executes a Windows program the spawn process is
performed by functions in spawn.cc
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/spawn.cc;h=37db52608e24e866e80401668ef13562f0cb67ea;hb=HEAD
If you need more details or ask clarification use the cygwin mailing list.
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 a Haskell script that runs via a shebang line making use of the runhaskell utility. E.g...
#! /usr/bin/env runhaskell
module Main where
main = do { ... }
Now, I'd like to be able to determine the directory in which that script resides from within the script, itself. So, if the script lives in /home/me/my-haskell-app/script.hs, I should be able to run it from anywhere, using a relative or absolute path, and it should know it's located in the /home/me/my-haskell-app/ directory.
I thought the functionality available in the System.Environment module might be able to help, but it fell a little short. getProgName did not seem to provide useful file-path information. I found that the environment variable _ (that's an underscore) would sometimes contain the path to the script, as it was invoked; however, as soon as the script is invoked via some other program or parent script, that environment variable seems to lose its value (and I am needing to invoke my Haskell script from another, parent application).
Also useful-to-know would be whether I can determine the directory in which a pre-compiled Haskell executable lives, using the same technique or otherwise.
As I understand it, this is historically tricky in *nix. There are libraries for some languages to provide this behavior, including FindBin for Haskell:
http://hackage.haskell.org/package/FindBin
I'm not sure what this will report with a script though. Probably the location of the binary that runhaskell compiled just prior to executing it.
Also, for compiled Haskell projects, the Cabal build system provides data-dir and data-files and the corresponding generated Paths_<yourproject>.hs for locating installed files for your project at runtime.
http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.html#paths-module
There is a FindBin package which seems to suit your needs and it also works for compiled programs.
For compiled executables, In GHC 7.6 or later you can use System.Environment.getExecutablePath.
getExecutablePath :: IO FilePathSource
Returns the absolute pathname of the current executable.
Note that for scripts and interactive sessions, this is the path to the
interpreter (e.g. ghci.)
There is executable-path which worked with my runghc script. FindBin didn't work for me as it returned my current directory instead of the script dir.
I could not find a way to determine script path from Haskell (which is a real pity IMHO). However, as a workaround, you can wrap your Haskell script inside a shell script:
#!/bin/sh
SCRIPT_DIR=`dirname $0`
runhaskell <<EOF
main = putStrLn "My script is in \"$SCRIPT_DIR\""
EOF
I need to do a fair bit of scripting in my job as a SQL Server DBA. Sometimes, I need to deploy a fix script to a very restricted environment, where the only option for scripting may be DOS Batch. In one such environment, even VBScript/WSH isn't a possibility, let alone PowerShell. Anyone who has written enough batch files on DOS and Windows knows that it's very limited and a huge PIA when you need to do anything too complicated. This is especially true for folks who have worked with Unix shell scripting, Perl, Tcl, Python, Ruby, etc.
A possible solution to this would be a CMD preprocessor that would add some of the useful functionality from more capable scripting languages. I've tried to find such a utility, but so far I've had no luck.
Which finally leads to my question: is anyone aware of a such a CMD preprocessor? If not, what functionality would you like to see in one?
Addendum:
If you're unfamiliar with the idea of a preprocessor see this Wikipedia entry.
To clarify, I'm thinking of a tool that would add features like:
Functions
Backtick (`) ala Unix shell
...and possibly others. Those are two features I've wished CMD had and can think of a way to implement them with a CMD preprocessor. Functions could be implemented with env vars and GOTO/labels; backticks by piping to a temp file and using set /p =< to read in the result to an env var.
You can already achieve these same ends, but it gets to be very tedious and verbose- which is how I came to the idea of having a preprocessor handle the boilerplate for features like those.
Example
Using the example of backticks, here is an example of unprocessed code from my hypothetical Batch++ and processed vanilla batch script, ready to be run by CMD.exe:
Batch++ Source (test.batpp)
copy `dir /b /s c:\ | find "CADR-README.htm"` \\srv01\users
Run it through the preprocessor
bpp test.batpp > post_test.bat
Resulting CMD/BAT code (post_test.bat)
dir /b /s c:\ | find "CADR-README.htm" > _bt001.tmp
set /p _BT001 =< _bt001.tmp
copy %_BT001% \\srv01\users
set _BT001=
del _bt001.tmp
I am not sure to interpret correctly your question. If you run in a controlled environment that doesn't allow you to run any scripting extension, how are you going to access such a preprocessor?
However, and in regard of the two features you request, you are OK with .BATs. Both features are supported by BAT processing in current Windows versions.
Functions: you have the extended CALL syntax, that supports parameter passing thru argument references %1 .. %9, and enhanced with expansion substitution using %~ syntax. Read HELP CALL.
Backtick: not sure what you want but, in the FOR /F command you may pass a backticked string to be run and its output captured. Read HELP FOR.