I'm trying to change the nvim shell to Powershell 7, i've tried adding set shell=powershell and it works, the problem is that doing that way comes with a massive slowdown on every action what i perform in nvim (saving, using nvim-tree, even starting up nvim). Reading a bit online found someone who solved this issue by manually adding the shell path instead of the set shell=powershell mentioned before, behind the idea that the powershell being used was the 32-bit one instead of the 64.
So, i've tried to do the same and added this.
set shell=C:/Program\ Files/PowerShell/7/pwsh.exe
But that didn't work, every time i've tried to open the terminal with :term i got
E475: Invalid value for argument cmd: 'C:/Program' is not executable
Any ideas?
Thanks in advance!
Related
I am creating an installation using InstallShield 2018 in windows 10. I need to execute a script file (.sh) in Ubuntu from a function in Installscript. I tried the following but it did not work:
szCmdPath = "C:\\Users\\Admin\\AppData\\Local\\Microsoft\\WindowsApps\\Ubuntu.exe";
szCmdLine = ". /mnt/d/test.sh";
LaunchAppAndWait( szCmdPath, szCmdLine, WAIT);
However I can execute the exact same file in Ubuntu Terminal and it works great. I did turn on Window sub system for Linux and install Ubuntu on windows. Why is this happening? Why can I run cmd.exe from installscript but not Ubuntu?
Thank you in advance.
EDIT 1: if I pass an empty string as parameter, Ubuntu is start and waits for my input commands. But when I pass the path to my script file, nothing happened except a flash of the terminal console before my installation goes on running.
From my reading, wsl and ubuntu differ slightly. It looks like wsl is a bit magical and occasionally similar to bash -c or ubuntu -c, whereas you can consider Ubuntu.exe as somewhat equivalent to /bin/bash.
If you try to run /bin/bash . /mnt/d/test.sh from a bash prompt, things don't go well. So the correct approach will depend on the contents of your script and what you need to happen. I think one of the following options are the most likely:
remove . from your command; instead run ...\Ubuntu.exe /mnt/d/test.sh
add -c to your command; instead run ...\Ubuntu.exe -c . /mnt/d/test.sh
Note that %LOCALAPPDATA%\Microsoft\WindowsApps\Ubuntu.exe is a special file (zero bytes), so it's also plausible that it needs some special handling. For instance, maybe it requires a 64-bit caller. If that's the case, you may need to wrap it in a call through a 64-bit cmd prompt. My quick tests don't show this as likely, however, so I think it will work without this extra indirection.
I just switched to a windows machine and I'm trying to get fish configured correctly. I installed it through the default route, as a shell selected through cygwin setup. It seems to be working fine, but when I directly access fish.exe or run fish.exe through IntelliJ, it outputs a ? before very prompt:
I googled and found this on fish documentation FAQ:
I'm seeing weird output before each prompt when using screen. What's wrong?
Quick answer:
Run the following command in fish:
echo 'function fish_title;end' > ~/.config/fish/config.fish
Problem solved!
The long answer:
Fish is trying to set the titlebar message of your terminal. While
screen itself supports this feature, your terminal does not.
Unfortunately, when the underlying terminal doesn't support setting
the titlebar, screen simply passes through the escape codes and text
to the underlying terminal instead of ignoring them. It is impossible
detect and resolve this problem from inside fish since fish has no way
of knowing what the underlying terminal type is. For now, the only way
to fix this is to unset the titlebar message, as suggested above.
Note that fish has a default titlebar message, which will be used if
the fish_title function is undefined. So simply unsetting the
fish_title function will not work
So it appears that intelliJ and cmd (fish.exe runs in cmd.exe if you access it directly) do not support setting the title bar, so they just output the character to the terminal instead. However, their suggested solution does not work. I've tried various options like echoing an empty string or a space, but nothing gets rid of that darn question mark.
Has anyone else run into this and found a solution?
Notes:
It doesn't have this behavior when using fish through mintty.exe,
most likely since that terminal supports setting the title, but I really prefer
to use the terminal inside intelliJ instead of having it in a
separate window.
It didn't have this problem when I used fish through IntelliJ on Ubuntu or MacOSX, it appears to be isolated to Windows
I have been given a personal profile on a linux project server running bash 3.2.15. Every time I run a command it echoes the text of the command to screen. This isn't a serious issue, but it bugs the crap out of me. I can't find any specific command in .profile or .bashrc that sets this up, and everything I find through google is how to enable it. Not how to disable it. Anybody got any ideas?
It sounds like debugging has been enabled (using set -x). You can disable it using set +x.
I'm using msysgit 1.7.7.1 on Windows. I get an error when using git diff. What is causing this? Is there no diff tool included in msysgit? What should I do?
WARNING: terminal is not fully functional
If you are having issues in cmd.exe, for instance, see the warning here:
Then simply set your environment variables and include TERM=msys. After that, each time you open a cmd.exe, your variable will be set correctly.
NOW YOU MUST RESTART YOUR SHELL (CMD.EXE). Just run a new one. And from there, you should have no more issues. Again:
For Git Bash, this can be fixed by adding the following line to ~/.bashrc:
export TERM=cygwin
-or-
export TERM=msys
The first seems to be the original by git for windows, the second a popular known form to "heal" as well.
The problem can be caused if some other program (like for example Strawberry Perl) sets the TERM system environment variables.
http://code.google.com/p/msysgit/issues/detail?id=184
Above answers was not fully worked for me, so I did:
Add
export TERM=msys
to "[githome]/etc/profile" at the top but it made changes only for git bash. Then I added
#set TERM=msys
to "[githome]/cmd/git.cmd" after #setlocal (I installed only git run from command line). May be this decision not truly good but it works for me and there are not any terminal warnings. (I use git version 1.7.10.msysgit.1).
The answer can be found here, in which the author of the solution claims that:
the environment variable TERM was set to dumb
that was instead of
TERM=cygwin
You can change that to
TERM=msys
to solve the problem at hand.
I work in powershell and I have the git executable directly in my path.
None of the suggested answers worked, but I found a solution that works for me.
I added a line in my powershell profile:
$env:TERM="msys"
Which fixed the problem for me.
A quick & dirty solution in my case turned out to be to use the --no-pager option.
By default, some git commands (like log) will use a pager like less if they expect the output to be long. Pagers require things like scrolling text up and down with the arrow keys, which sometimes doesn't work if the assumptions about what kind of terminal you're on are wrong (this is what the "not fully functional" means).
If you know ahead of time that your output will be short, or you just want it to dump output to the terminal and leave the scrolling up to your terminal program, you can override this and not use a pager at all, e.g.:
git --no-pager log
In case someone gets this launching bash from Git Extensions, check the setting for Path to linux tools.... Mine was set to C:\cygwin. Changing it to C:\Program Files (x86)\Git\bin\ fixed it for me. I didn't have to set the TERM variable to launch bash this way.
I am using a bash script to run a number of application (some repeatedly) on a Windows machine through cygwin. The script contains commands to launch those applications, line by line. Most of these applications run for many minutes and many times I have observed that the i+1 th application is not being started even after i th application is completed. In such cases, if I press enter in the cygwin console on which the bash script is running, the next application starts running. Is it because of any issue with bash on cygwin? Or is it an issue with the Windows OS itself? Have any of you observed such an issue with bash + cygwin + Windows?
Thanks.
I think I have seen this before.
Instead of
somecommand
try
somecommand </dev/null
If that doesn't work, try
cmd /c somecommand
Or experiment with other redirections, e.g.
somecommand >/dev/null
Sounds like you may have a problem with your shell script encoding; DOS (and Windows) uses CR+LF line endings, whereas Linux uses LF endings. Try saving the file as LF.
What might also be going on:
When I was running Cygwin on a school laptop, I encountered a dramatic slowing of shell scripts vs. when they were running in a native Linux environment. This was especially apparent when running a configure script from GNU Autotools.
Check your path for slow drives. (From the Cygwin FAQ):
Why is Cygwin suddenly so slow?
If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.
You might also want to check whether you have an antivirus program running. Antivirus programs tend to scan every single executable file as it is executed; this can cause problems for even simple shell scripts that run hundreds or even thousands of individual programs before they run their course.
This mailing list post outlines what is needed to pseudo-mount the main /usr/bin directory as cygexec. I'm not sure what that does, but I found it helped.
If you're running a configure script, try the -C option.
Hope this helps!
Occasionally, I'll get this behaviour because I have accidentally deleted the 'she-bang' at the top of the script, that is, deleted the #!/bin/bash on the first line of the script.
It's even more likely for this to happen when a parent shell script calls a child script that has the she-bang missing!
Hope this helps.
A bit of a long shot, but I have seen some similar behaviour previously.
In Windows 2000, if any program running in a command prompt window had some of it's text highlighted by the cursor, it would pause the command running, and you had to press enter or clear the highlighting to get the command prompt to continue executing.
As I said, bit of a long shot, but accidental mouse clicks could be your issue...
Install cygwin with unix style line breaks and forget weird problems like that.
Try saving your script as "the-properly-line-broken-style" for your cygwin. That is, use the style you specified under installation.
Here is some relevant information:
https://stackoverflow.com/a/7048200/657703