I have been using ConEmu for some time to run 'bash for windows', but all of the sudden it stopped working. When I launch a bash tab it now says:
ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console...
I think this means that it launched something, but the shell closed quickly. I haven't changed anything that I can recall with the system, it just started doing that.
Windows version: 10 (build 15063)
ConEmu version: 180626 preview
No windows updates were done recently.
If I launch 'Bash on Ubuntu on Windows' from the start bar, it works fine (but I prefer using conemu as a terminal). Also, I can launch a cmd tab in conemu, then type bash and the bash shell will start. Unfortunately, launching bash in this way results in a lack of mouse support, and strange arrow key behavior.
I am at a bit of a loss. It worked perfectly previously... then it just stopped. Any help on how to debug or fix this would be appreciated.
If anybody finds this with a similar problem, my solution was to make a new task in ConEmu, with the command:
%windir%\system32\bash -l -i -cur_console:p5
The key is the -cur_console:p5, which sets the pty type as:
p[N] - pty modes, N - bitmask: 1 - XTermKeys, 2 - BrPaste, 4 - AppCursorKeys; default is 5 (1+4)
For some reason, setting p5 is necessary for me, despite it being listed as the default. Still not sure what changed, but at least it is working now.
I have the same problem but (for what it's worth) found that when it happens (varying between intermittent and incessant) restarting my machine fixes the issue every time.
Related
I am using versions:
ESXI 6.5.0 Update 3 (Build 14990892)
Power CLI VMware PowerCLI 11.0.0 build 10380590.
I have a VM that I am importing (ISO) into an ESXI and trying to set Autostart on the VM to "enabled" programmatically via some scripts, but it is not working. I am using the powercli command:
Set-VMHostStartPolicy (Get-VMHost | Get-VMHostStartPolicy) -Enabled:$true
I've also tried some variants of this command but none seem to work. I see the "event" get logged as "Reconfigure Autostart" under the "Recent Tasks" menu on the ESXI Web GUI as soon as I input the command, so its definitely configurating something, but when I double-check the state of the VM to see if Autostart is enabled, it still lists "Enable" as an option, implying Autostart is NOT enabled. Here's a screenshot:
Can anyone help me please? I just want to have this VM start automatically incase there is a power outage or server crash; But only in these cases, I want it to import powered OFF for the first time (as you can see in screen shot the EPS VM is imported but in a powered down state, which is what I want)
I think what you're doing is setting the host's default policy... You would think that would work. I'm using this code on ESXi 7.0 Update 1 to set the guest's policy:
$vmstartpolicy = Get-VM "$vm_name" | Get-VMStartPolicy
Set-VMStartPolicy -StartPolicy $vmstartpolicy -StartAction PowerOn
It has the same issue that it doesn't show in the web UI, (which somebody will complain about, and I'll have to fix) but it does auto-start the VM after a reboot, so at least it's a start (pun not intended).
Edit: After playing around a bit, I managed to find a solution that updates the UI.
plink -batch -ssh $user#$IP -l "$user" -pw "$password" vim-cmd hostsvc/autostartmanager/update_autostartentry "`$(vim-cmd vmsvc/getallvms | grep `"$vm_name`" | awk '{print `$1}')" "PowerOn" 0 1 "systemDefault" "systemDefault" "systemDefault"
Using plink to ssh into the host and run this vim-cmd, it updates the UI properly. Take note of the back-ticks (`) to escape the dollar signs (except the one with the $vm_name variable) and quotes in the sub command, so that powershell doesn't try to interpret them before sending them through the ssh tunnel. All the sub command does is get the all the VMs, use grep to filter down to the output line with the vm_name you specify, and use awk to print only the 1st column (the vm id required for the outer vim-cmd).
I'm having some problems getting the XFCE Power Manager to lock using physlock. When I set the Lock Screen on Lid Close action, upon opening my laptop lid I'm presented with an alternate lock screen, and after entering my password I get the error None of the screen lock tools ran successfully, the screen will not be locked.
However when I manually run xflock4 from a terminal emulator, physlock is correctly used.
The relevant xfconf LockCommand setting is thus:
➜ ~ xfconf-query -c xfce4-session -p /general/LockCommand -v
physlock
And my power manager settings are this:
physlock was correctly working in the past using these settings, but as this stopped working some months ago, I'm afraid I won't be much help in narrowing down what triggered the initial change.
I use Ubuntu 18.04 on a WSL system and usually log on a Linux server through ssh to get some work done. When I activate 'screen' and use the tab key to autocomplete commands, my cursor goes to the end of line, and the formatting of my entire terminal breaks from then on.
When using vim in that condition on a screen terminal, if I go to the end of file and press down on more time, it erases the last line from the terminal.
It seems a kind of misinterpretation of some terminal signal. When using Putty or any other ssh client under the same circumstances, everything works fine, so I am pretty sure it is a problem with WSL environment, specifically.
Any ideas about what is the main issue and how to solve it?
I just came across this same exact issue and it appears to be a possible bug with Windows Console and certain $TERM values.
I have this problem when $TERM is set to screen-256color. The problem went away after setting $TERM to xterm-256color in .screenrc
$ cat ~/.screenrc
term xterm-256color
I use tmux (tmux 1.8) from Ubuntu 14.04.
I wanted to configure it a bit via ~/.tmux.conf. But whatever I set inside this file my tmux session looks the same. Then I tried a fresh new /etc/tmux.conf but I still get the same display.
It seems that my config is hardcoded and that I cannot change it.
If I remove these two files (~/.tmux.conf and /etc/tmux.conf) my tmux session is still the same. Tmux runs but I can not configure it. But it should be so simple...
Does anybody have already seen this? And how I could solve that? Do I need to compile a fresh new release of tmux?
Today, I have more details :
on one machine it works as expected. It's OK. But I did not changed anything! Strange...
But on another machine (also running Ubuntu same release and up2date like the first machine) it does not work.
The file /etc/tmux.conf does not exist on none of these 2 machines. I put this little config file (~/.tmux.conf) :
# start Window Numbering at 2
set -g base-index 2
When I launch tmux on this second machine, window numbering starts at 0. On the first machine with the same config file, it behaves correctly : it starts at 2.
I'm going crazy!
After you make changes to ~/.tmux.conf make sure tmux sources them with the tmux source-file ~/.tmux.conf shell command.
Try removing all sessions before running tmux. I have noticed that if you have sessions still running, tmux will still load the previous .tmux.config file.
Executing tmux kill-server can stop the server and then try to run the server again using tmux command.
Please note that after killing the server you will lose all open sessions / tabs.
I have a simple bat file which does the following:
#echo off
mkdir folder1
mkdir folder2
echo.>file1
move file1 folder1\file1
When I run this on Windows 8 it will often hang the shell and explorer.
Interestingly, turning on/off the echo does seem to effect the chance of running into the bug (echo off hits the bug more often it seems) but I can get the bug either way. Suggests a race condition of some kind.
Anyone have an idea why this hangs on Windows 8? It doesn't on Windows 7.
I've also tried this using powershell. It happens less often (had to do it about a hunderd times before I hit the problem) but still occurs.
Turns out the problem was a combo of antivirus and search indexer. Both touch all the files in the FS as soon as they're created. I also suspect that the test machine being a VM has something to do with it (it is likely a little underpowered).
tldr; turning off windows.search from services fixed things.