as an replacement for ksh under cygwin, pdksh might be the only choice. but look like there have a bug for cygwin : pdksh(5.2.14-3) to support backslash path (\).
it will swallow the \ :
$ cd .\access
pdksh: cd: /cygdrive/e/.access - No such file or directory
After search on the internet, the same problem solved for other platform. but no idea how to solve it for cygwin.
Pdksh, like all Cygwin programs, does support backslashes as directory separators. But you have to quote them properly. Running shell scripts under Cygwin really teaches you to quote things properly, in particular to always put variable substitutions in double quotes, and not use echo carelessly (printf "%s" "$x" is portable and reliable: unlike echo, there's no risk that it might do backslash expansion).
Note that pdksh's compatibility with even ksh88 is far from perfect, so some scripts may fail for other reasons (such as relying on the status code of writer | reader being that of reader, which is the case in true ksh but not in pdksh). Cygwin includes zsh, which after you run emulate ksh is mostly compatible with ksh88 (though still not perfect).
There are non-Cygwin ports of ksh for Windows, including InterixSFUSUA and ATT's own port.
You have to use forward slashes, or double all the backslashes, or single-quote every string that might be a pathname. Sorry, there's no way around this. This is a general problem with trying to use Unix shells, for which \ is an escape character, on Windows.
From the Cygwin User's Guide:
Note
The usage of Win32 paths, though possible, is deprecated, since it circumvents important internal path handling mechanisms. See the section called “Using native Win32 paths” and the section called “Using the Win32 file API in Cygwin applications” for more information.
There is a utility called cygpath that is designed to be used in shell scripts that converts each way between Win32 and POSIX paths.
Here's a workaround for the problem. Start using bash and make the following modifications in config files.
Open ~/.bashrc
Add the following code at the end
wcd()
{
cd $(echo "$#" | sed 's/\\/\\\\/g')
}
Save it
Reload bash terminal.
Type
wcd ".\access"
along with the quotes and voila, you have your own windows compatible cd command.
Related
I am using Ubuntu via WSL 2.0 on Windows 10 and would like to run Texlive from the Windows command line. To do so I prepended the Texlive folder to the path in /etc/environment (I also tried a number of other locations eg. $HOME/.bashrc):
C:\Users\scott\Documents>wsl echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/system32:...
C:\Users\scott\Documents>wsl
scott#SCOTT-PC:/mnt/c/Users/scott/Documents$ echo $PATH
/usr/local/texlive/2020/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/system32:...
Why is there a difference between these two paths? Is it possible to change the first PATH variable?
To be honest, when I first looked at this question, I thought it would be an easy answer. Oh how wrong I was. There are a lot of nuances to how this works.
Let's start with the fairly "easy" part, though. The main difference between the first method and the second:
wsl by itself launches into a login (and interactive) shell
the shell launched with wsl echo $PATH is neither a login shell nor an interactive shell
So the first will source both login scripts (e.g. ~/.profile) and interactive startup scripts (e.g. ~/.bashrc). The second form does not get to source either of these.
You can see this a different way (and get to the solution) with the following commands:
wsl -e bash -c 'echo $PATH'
wsl -e bash -li -c 'echo $PATH'
The -li forces bash to run as a login and interactive shell, thus sourcing all of the applicable startup scripts. And, as #bovquier points out in the comments, a single quote is needed here to prevent PowerShell from interpolating the $ before it gets to Bash. That, or escape it.
You should be able to run TeX Live the same way, just replacing the "echo $PATH" with the startup command you need for TeX Live.
A second option would be to create a script that both adds the path and runs the command, and just launch that script through wsl /path/to/script.sh
That said, I honestly don't think that your current login/interactive PATH is coming from /etc/environment. In my testing, at least, /etc/environment has no use in WSL, and that's to be expected. /etc/environment is only sourced by PAM modules, and with no login check performed by WSL, there's no reason to invoke PAM in either the wsl nor the wsl echo $PATH commands.
I'd expect that you still have the PATH setting in ~/.bashrc or somewhere similar), and that's where the shell is picking it up from at the moment.
While this isn't necessarily critical to understanding the answer, you might also wonder, if /etc/environment isn't used for setting the default (non-login, non-interactive) path in WSL, what is? The answer seems to be that it is hard-coded into the init that starts up WSL. That init is also what appends the Windows path (assuming you don't have that feature disabled in /etc/wsl.conf).
I am running the script from Cygwin and I get the following error
bash bin/install-wp-tests.sh wordpress_test root 'my_pass' localhost latest
Result:
sed: -e expression #1, char 36: unknown option to s'
This is the line where the error occurs and the execution ends
sed $ioption "s:dirname( __FILE__ ) . '/src/':'$WP_CORE_DIR/':" "$WP_TESTS_DIR"/wp-tests-config.php
Why does this error occur?
regards
Why does this error occur?
First of all Integrating WP Unit Testing in Windows outlines a couple of reasons already.
If you ask why because you're looking for a solution, there is this on the page:
Lastly, sometimes the bash script fails to build WordPress because of how it uses tmp folders. If it fails, then you can manually install WordPress to a writeable directory, and then manually create wp-tests-config.php.
Here is a bit of background:
Most likely there is a colon (":") in the directory name or in $WP_CORE_DIR (and as it is not encoded for the sed-pattern) sed sees it at the end of the s:<search>:<replace>:<option>... search expression and stumbles over the unintended option which then is unknown - and tells you.
On *nix systems a colon is normally not part of a pathname. which means, that you've run into an incompatibility with that shell script with your system. It is not portable with cygwin.
You can either try to make the script portable with cygwin, e.g. by quoting the colons for <search> and <replace> (see sed(1) for sed expression syntax).
Or you can read the sed expression (again see sed(1)) and apply the changes to the test wordpress-configuration-file manually your own (this is the suggestion from the manual, so probably the first way to go with).
In windows 7 at run prompt, this command succeeds in launching the .exe with the the optional input file "test2.dat"
c:/Program Files (x86)/IEUBKwin1_1 Build11/IEUBKwin32.exe k:/Project/EPA.Pb.IEUBK/batch.io/input/test2.dat
I want to do the same thing from within R.
In R, this command succeeds in launching the same .exe
shell.exec("c:/Program Files (x86)/IEUBKwin1_1 Build11/IEUBKwin32.exe")
But I've been unable to find a solution within R that will launch the .exe with the optional input file. I've looked at shell(), shell.exec() and system() but I could not find the right incantation that will pass the optional input file to the .exe.
Any thoughts?
Typing into the normal cmd.exe-promt a command including spaces as in C:\Program Files (x86)\... does not work:
The Command "C:\Program" could not be found.
Typing in the same command with double quotes does work. E.g.:
"C:\Program Files (x86)\7-Zip\7z" -a ...
To get it to work in R, you can use single quotes (') to mark a R string and double quotes (") for the command itself. Actually, you have the possibility of three different quotes to use (backtick is the third one `, see here for more information). Or you use escapes as mentioned in the answer of #Frank.
system('"C:/Program Files (x86)/IEUBKwin1_1 Build11/IEUBKwin32.exe" k:/Project/EPA.Pb.IEUBK/batch.io/input/test2.dat')
In addition ?system mentions not just to use shell in windows but also system2 as alternative:
...This means that it cannot be assumed that redirection or piping will work in system (redirection sometimes does, but we have seen cases where it stopped working after a Windows security patch), and system2 (or shell) must be used on Windows.
But for me system works totally fine not using piping or redirection.
shell.exec() is used for opening files associated in your OS.
in your case, the shell command should be preferred but you need to take care of spaces in your filenames and mask quotaion marks.
Please try:
shell("\"c:/Program Files (x86)/IEUBKwin1_1 Build11/IEUBKwin32.exe\" k:/Project/EPA.Pb.IEUBK/batch.io/input/test2.dat")
I am running svn2git on Windows and would like to exclude a number of branches from the migration process. How is this achieved?
svn2git generates a regexp from the exclude tags that it feeds to it's --ignore-paths argument.
Unfortunately, this regexp contains DOS reserved characters - like [ ] | etc - which are not escaped.
I first tried to use the generated regexp to make a properly escaped regexp to make my own --ignore-paths argument but the reserved charcters/escape system of DOS is a real nightmare.
Solution -> use a Linux distribution or setup cygwin on your windows system :
Install cygwin, with ruby packages
gem install svn2git
cd /usr/local/bin
ln -s /home/<user>/.gem/ruby/gems/svn2git-2.3.2/bin/svn2git
cd /cygdrive/c/<your target repo>
Now you can run svn2git with as many --exclude arguments as needed !
As cdup suggests, if you can get it to run in e.g. the Git bash window that comes with Git for Windows, you'll likely avoid many issues.
However, if you want, can modify svn2git source code directly on your machine to fix this issue. The issue occurs because svn2git uses single ticks ' rather than double quotes " around arguments that are passed to git svn. The fix described below also applies to other areas of svn2git in the context of a Windows command prompt.
Anyway, open migration.rb under <ruby install path>\lib\ruby\gems\<version>\gems\svn2git-<version>\lib\svn2git and look for this line:
cmd += "--ignore-paths='#{regex}' "
Replace it with this (note that ' has been replaced by an escaped double quote \"):
cmd += "--ignore-paths=\"#{regex}\" "
Save changes and rerun svn2git. Your exclude pattern should now work.
I just encourage a weird problem with zsh today.
My environment is Mac OS X Yosemite, zsh 5.0.5 (x86_64-apple-darwin14.0)
In .zshrc, I have manually set the PATH variable to something like
export PATH="$PATH:~/.composer/vendor/bin"
Try echo $PATH in terminal, the result is as expected (contained ~/.composer/vendor/bin). Then try executing a binary from ~/.composer/vendor/bin, It'll always return me "zsh: command not found" error.
Try switching to bash, echo $PATH is also as expected, have the same result as zsh shell.
Try executing a binary from ~/.composer/vendor/bin, no problem found. Seem the PATH var is acting well on the bash shell.
What's wrong with my zsh shell?
Thanks
Try using $HOME instead of ~. In many situations, shells do not expand ~ when you expect them to and it is usually better to use $HOME. ~ is really only intended to be a short cut for interactive use. (The only case I can recall where ~ was preferred was in a .gitalias, where ~ was expanded and variables were not.)
Type rehash to pick-up $PATH changes.
From the zsh user guide:
The way commands are stored has other consequences. In particular, zsh
won't look for a new command if it already knows where to find one. If
I put a new ls command in /usr/local/bin in the above example, zsh
would continue to use /bin/ls (assuming it had already been found). To
fix this, there is the command rehash, which actually empties the
command hash table, so that finding commands starts again from
scratch. Users of csh may remember having to type rehash quite a lot
with new commands: it's not so bad in zsh, because if no command was
already hashed, or the existing one disappeared, zsh will
automatically scan the path again; furthermore, zsh performs a rehash
of its own accord if $path is altered. So adding a new duplicate
command somewhere towards the head of $path is the main reason for
needing rehash.
EDIT However #WilliamPursell could be onto something with his comment:
note that "composer" != ".composer"